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!