Tips to Transforming Your Technical World

Tips to Transforming Your Technical World

In a prior post, Getting Ready for Your Technical Transformation, I defined technical transformation and why it is so important.  Now, I’d like to dive a bit deeper into some tips on going about it…

To begin to transform your technical ‘world’, you need to first make sure your organization’s environments are aligned. As a start, the technical experts in your organization should decide what environments are necessary to deliver the value to the customers; sometimes it could mean as few as 3-4, and sometimes 10-12 may be more like it.  The idea here is to build only the environments which are required and leave the others behind; the more environments your organization has, the more attention and costs that will need to be given to them.  When you have more environments, you vastly increase your costs in areas such as physical hardware, bandwidth, cloud storage, software platforms, which also calls for an increase in cost to administer and configure these environments.  It is wise to plan out the environments carefully!

From what I have seen, and know from my experience as a developer, organizations can usually get by with 4-7 environments, such as “Development”, “Testing”, “User Acceptance Testing”, “Staging”, and “Production”.  A couple of these may be combined or broken out in some organizations, depending on who is doing the acceptance, if there is training to be done, or if there is any beta-type testing needed, but remember that the more you have, the more work they require!

The point is to have the environments, regardless of how many you have, be aligned with the delivery, meaning “Development” would be used for team member to write code, write test scripts, etc., while “Testing” would be used to run stable code, execute test scripts, etc., with a constant set of data to check for bugs, “Staging” would be used to smoke test everything before it is put into “Production”, and so on.

Once the environments are established, the next question is what to do with them and how to move the product through them to “Production”.  There are numerous ways to do this, and the ‘go-to’ way is by manually copying the product between them or even rebuilding the product in each environment.  However, by doing these manual processes, the move is prone to errors—anytime you insert manual, people-driven processes, you introduce error.

In order to eliminate as much error as possible, it makes sense to have machines do the moving.  This process is referred to as “Continuous Delivery”.  You can make this happen by utilizing tools that are out there to help with this very thing.  Some of them you may want to explore are: Jenkins, TFS, Ant, Gradle, Bamboo, or Puppet.  While these are a start, there are many, many others tools to choose from.  The selected tools will depend on your preference, i.e. if you are a person comfortable with scripting/coding or someone who feels better about checking boxes and clicking buttons.

These tools will help you move the product through the environments to “Production”, but they will also help you with another key aspect of transformation:  continuous delivery of each product increment.  To complete an Agile transformation, including the technical ‘stuff’, you really need to be able to deliver continuously to each environment.

Any organization that feels it has truly become Agile will hold to the true nature of Agile:  iterative and incremental delivery.  If this is the case, then it stands to reason that you need to be able to continuously deliver product, pretty much on demand.

If you get stuck and are not sure what to do, you can always call upon a Technical Agile Coach—they can help you align your environments, choose the right tools, and even get you delivering continuously!


As your organization prepares to transition to an Agile one, you will most likely want to know all that the transformation entails.  One of these things will be transforming your technical practices to better align with the Agile Engineering Practices…so how can you make it a success?

Plan For It 
Organizations typically will look at the process, the teams, and the projects they will transform in their move to Agile.  However, they often forget a key piece of the puzzle: the technical ‘stuff’.

In the scheme of things, it is fairly easy to change the process that one is doing from process A to process B.  It’s also relatively easy to choose the projects that will move to Agile and the teams that will work on them.  The hiccup is that they almost always forget about the changes that must be made to the technical architecture they have in order to ensure the complete transformation.

Identifying the technical changes that need to be made and ensuring they are part of the transformation plan are keys to making your agile transformation a success!

Architecture on the Brain
In most organizations, the technical architecture is one that is usually aligned with projects or, sometimes, aligned with what was pushed and when.  The architecture is most likely not aligned with the various applications or features that the organization produces.

When this is the case, the teams most likely will have a difficult time aligning themselves in a way that they can concentrate on any specific application or feature.  This concept produces issues for teams’ ability to work on a defined backlog, and even worse, creates barriers to them completing anything of value during a sprint.  This type of architecture is steeped in dependencies and blurry lines.

In order to ensure the architecture is set up to allow for the Agile Engineering Practices, it is imperative that the architecture be examined and plans be made to make the necessary shifts in the alignment of the architecture to match.

What About Environments?
Environments are another aspect that can cause issues when attempting to institute Agile Engineering Practices.

There are usually multiple environments, like DEV, QA, SIT, UAT, and PROD, that the team will move their completed increments through.  The biggest concern with this is that most of the time, the environments do not match up and they have varying states of the application and data.  This poses numerous obstacles to the team being able to produce effectively.

To deliver value effectively, teams need to be able to accurately test the stuff they are producing.  In order to accurately test, they need to have a “clean” environment to move their increments into.  When environments are not in sync and/or are not aligned correctly, teams will have issues creating successful builds and testing them.

When the environments are not correctly aligned and/or they are not working properly, there are major consequences that can result.  These consequences can range anywhere from not completing a sprint’s increments to producing low quality results to ending up with unwanted value.

A Couple Things to Think About
If an organization doesn’t identify and plan for the technical architecture changes they will need to support their Agile transformation, they will most likely cause more delays and, more importantly, pose more barriers to the team’s effectiveness.

Examine what your team has in its way when it comes to developing, testing, and deploying code.  What kinds of measures do you feel your team needs to take in order to deliver value on an incremental, consistent basis?

Stay tuned for the next installment where we will look at ways to make the technical transformation a reality…