Sunday, February 1, 2015

Release trains are a good first step, not the last one.

In software development, the release train concept tries to bring about some cadence in releasing software. Once it is agreed that the software will be released "every X weeks", product development teams focus on ensuring that a release happens at every X week interval. For most teams it could be anywhere between 2 weeks to 6 months. However the main idea being that while the interval and schedule is fixed, the scope or content of the release is variable.

This concept is a boon to enterprises who struggle to release software for years, especially those who are running teams that are in a dependency hell. Aligning every team towards a shorter release cycle with negotiable scope and actually releasing more often is a great first step.

The problem occurs when the concept starts breaking down into a bureaucratic process of release management instead of focusing on the core engineering problems behind releasing frequently.

Here is what happens in large enterprises

  • Organisations start creating new release committees (with roles like release managers, deployment coordinators etc...) to manage releases every X weeks across teams that deliver a common software platform.  Since the release committee works across teams without enough bandwidth to understand details, delivery teams are requested to create a whole bunch of documentation to aid the committee's decision making, mainly around a Go/No Go decision for every release.
  • Conservative strategies such as early branching, code freeze, etc... are applied to meet the release timeline of the train. QA teams start demanding more time for testing as they are constantly worried about every release.
  • Teams start planning more conservatively during their release planning exercises. No one wants to pack in more scope and be caught as a dependent team holding up a release. 
The core issue in larger organisations is that even with release trains, it ends up being a process problem that needs to be managed rather than an engineering problem. As an example, even with release trains, a lot of teams incur a bigger overhead in managing dependencies instead of investing the same time in decoupling systems to release independently.

Organisations embracing release trains as a first step lose their way towards continuous delivery. They get caught in the false sense of satisfaction that a release train gives them and hate to see the amount of overhead still incurred with every release. 

The real goal should be to engineer software in such a way that you can reliably release it on demand, whether it is daily or even hourly. So, please do take the next steps.



Saturday, January 31, 2015

Painful truth about "Agile QA" in the enterprise world.

When Agile brought the idea of cross functional teams with Devs and QAs working closely together every day, it created enough disruption and a feeling of insecurity amongst the traditional QA organisation.

However most of the big enterprises have embraced the idea and called themselves "Agile",  by paradropping QAs from their organisation into Scrum teams. These QAs still report to the old QA organisation but are also told to work on priorities set by their Scrum Master. These folks then declared victory in Agile adoption even though they were struggling with  collaboration between Devs and QAs in the Scrum teams on the ground. And more often than not, issues with collaboration are brushed off as tactical issues by QA management.

The reasons for lack of collaboration between developers and quality analysts are fairly deep rooted in our IT industry.


  • The relevance of so called "manual QA" is slowly diminishing with the advent of Continuous Delivery. There is a huge community of technical folks who are working towards reducing the complexity of testing and releasing on demand with minimal effort. Gone are the days of large manual regression QA teams running test cases documented from a Wiki.  If an IT organisation is still doing this, the IT business might cease to exist in the next 10 years. So in that sense, the CD embracing developers become a threat to the traditional manual QA world.
  • In most companies QAs are not hired for their keen eye and rigour in looking at where systems could break. Instead, a lot of times, QAs are created out of developers who struggled to clear a developer interview. In a lot of places, such candidates are made to do a QA role for a while, and are promised that if they do well, they might move into a development role soon. This creates a psychological divide. QAs try to pick up automated testing so that they can hone their development skills along with testing. In this context, whenever developers try to help QAs in automation, they are viewed as a threat. Innovation in automated testing is needed at all levels in the Test Pyramid, and the current culture hinders progress in that direction.
As organisations achieve more maturity in Continuous Delivery, there will be a lot more overlap between Developers and QAs. This will also include roles that perform non-functional testing such as Performance, Security, Load etc... In that context, the purpose of a QA organisation needs to change towards cultivating people who are learning to solve testing, integration and deployment problems so that releases become uneventful. IT folks who invest in bridging the gap between Dev <=> QA <=> Ops actively will be the ones that succeed in providing true agility to their business.


Saturday, September 13, 2014

A false sense of agility at scale

"Agile does not scale" is one of the common challenges in the Agile community and one of the answers recently has been the Scaled Agile Framework (SAFe). While SAFe has been packaged and marketed really well, every enterprise going through Agile transformation is using it or devising a home grown way of scaling Agile development processes to the wider organisation.

Most of these frameworks break down very quickly. The reason being, the more one tries to scale, the easier solution become standardisation which is counterintuitive to agility in first place. Even the SAFe image has an uncanny resemblance to top-down planning like below.

Similar top-down planning approaches have been dominating the software industry for ages and have never delivered the agility demanded by today's dynamic business needs. One simple reason is the broken reverse feedback loop between portfolio planners and the actual teams doing the work. This failure is very evident in an organisation within a few months when people talking about the portfolio have no clue about the current engineering practices on the ground and are very soon making numbers of their own. PMOs structured like this live in a fantasy land thinking that they are adding value.

While in the midst of such top-down planning the larger problem often gets forgotten.


If your business needs the level of agility that can push newer products to the market, it will not happen if there is no adaptive budgeting in the organisation. If frameworks like SAFe work within a yearly budgeting model, they are bound to fail. And this is what happens in every large enterprise that has a lot of resistance in moving away from their traditional annual budgeting models. The top down approach puts the budget and the product even further away from each other only to make it extremely difficult to determine the value from the investment made.

The solution to all this lies in keeping investments and products as close to each other, and as close to teams that use the investment to deliver value.


There is no easy path to scaling. And one size does not fit all. Here are some things to try.
  • Move away from annual budgeting and look at a rolling wave budgeting model based on return on investment.
  • Focus on realising value quickly by reducing time to market and feeding that back into your budgetary processes
  • Don't fall into the trap of standardisation when scaling agile development.
  • Push more autonomy to the teams and keep teams closer to budget and product so that you have a better sense of return on investment. It also provides the team a larger sense of purpose.



Wednesday, March 12, 2014

An agile enterprise...really ?

Every IT enterprise claims to be agile or wants to transform into one pretty soon. There are roles, processes, consultants and certifications, that specialise in Agile these days. But deep within these big enterprises who want to climb the Agile bandwagon, the meaning of being agile is lost.

If you are part of an IT enterprise ask yourself a few things by observing the people around you who are responsible for building the software to power your business.

Are people around you worried more about what is an Epic versus a Feature or a Story ? Are people discussing about what should happen in an Iteration/Sprint/Release planning meeting endlessly ? Is there disagreement on how things should be stored in that new Agile project management tool that your company just bought ?

 Think Individuals and Interactions over Process and Tools. 

What is more important here is not what an activity or an artefact is labelled as, but how we as software craftsmen create easy mechanisms to interact and collaborate and get the job done. Hiring a smart developer is way more important than coming up with a smart label or a process. That developer you hired will figure out a way automatically, trust me.

I would like to stress even more on the individual. How much is the developer you just hired empowered ? Can he/she pickup a story to be developed , question its business value when in doubt and challenge the product owner into not getting it developed ? Can he/she even visualise this as a remote possibility in between all the "Agile process" loops one has to cross ?

Look at people around you once again. Are they saying a story should not change within a sprint/iteration etc..? Are your sprints and releases locked in for even a few months at a high level ?

Think Responding to change over Following a plan

How are your people embracing or even responding to change ? Isn't it just another way to follow a plan ? What does it take for a developer on the ground to say a particular story will take 2 more days than what he/she thought initially ? What is the behaviour of people around when such a thing happens ? How easy is it to adapt to this reality in your organisation ?

So.. is your enterprise really agile after all ?

Tuesday, October 8, 2013

Stop locking down the Agile project management tool

I have seen this common behaviour at many of the bigger client organisations I have worked with, who are transitioning to organisation wide agile adoption. The company will invest a lot in researching and eventually buying an agile management tool of choice (Greenhopper, Mingle etc...) and then lock it down so that project teams will have minimal access to change how they want to use the tool.

The sheer irony is that these tools are actually written to be as adaptive as possible to the development process followed in the team. These tools, and especially Mingle for one, is written keeping in mind teams that are following agile will evolve their processes as they move forward.

Story statuses and types could evolve a lot. For a team that has just started, they might just have to deal with stories and defects. But once the team starts making releases, they might also have to deal with enhancements which probably has its own workflow. Changes have to be done to the project tracking tool to accommodate this change in processes. These changes are not one off. A team might discover new types of work and also new ways of tracking and progressing through the work on a frequent basis.

The driver for locking down the project management tool is to force teams to use the same set of statuses and processes so that reporting can be rolled up at a program or an organisation level. A lot of times, senior program management tries to come up with an "ideal agile workflow/template" that should work for all teams and then use the tool to impose it on all teams within the program. The result of this is immense frustration within teams while they try to find workarounds to the system that is being pushed on to them. Teams in this state start moving away from the tool that was chosen and end up tracking themselves through more lo fi means (physical card walls etc..). This reflects poorly on the investment made in buying this agile project management tool in the first place.

Here are a few suggestions

* Roll up reports at a fairly higher level of abstraction when reporting for a program. This gives teams some more flexibility in coming up with actual numbers for the KPIs. For e.g. instead of tracking "Velocity in points", track "Velocity". This gives flexibility for one team to use story points and another  which can use days, and another which can count stories :-).

* Don't rollup reports and don't lock down your workflows when the teams are still forming and storming. Let teams reach a stage where their development processes have matured a bit. Until then let each team present a different status report for themselves. Start rolling up once the teams have reached a performing state together.

Remember, every agile team has to adapt to different set of challenges and they can potentially come up with different creative processes to deal with them. For these teams to succeed the supporting systems and tools need to embrace change rather than impose order.