Tale of an Agile Transformation

Once upon a time, in a far away land, there was a beautiful and powerful kingdom. King Arthur was its ruler. He ruled it wisely and there was peace and prosperity everywhere. The King was however not content with the slow pace at which his kingdom was growing. Software was the kingdom’s strength and that’s what they had to offer to the world and King Arthur badly wanted to see a rapid growth chart.

One day the reformer Jean came to the king’s court. He had created a new SECURe framework that if implemented would make any kingdom the best in the world regardless of its current state or type of business. The king was very happy and agreed to adopt the new model that would skyrocket his kingdom into greatness.

Thus the transformation started.

There were huge coaching and training exercises for developers and pretty much everyone focused on how to do iterations. Unfortunately there was a lack of coaching for product owners and business. This problem haunted the whole transformation for a long time in the form of poorly conceived backlogs, poor practices of engagement with teams and business stakeholders, lack of empowerment, lack of ownership, lack of business vision and road map, unavailability of features during planning sessions for teams etc to name a few.

The engineering subjects of the kingdom started with iterations and due to failure in adopting good engineering practices it was found that integrating code base was a nightmare. Three increments into the transformation there were too many versions of code at hand with dependencies. Nobody had the forethought to think of what to do with the code base generated by many teams. Absence of a regression test bed added to the woes. All of the coaching was focused on the processes and very little on good engineering practices. In every iteration they struggled to efficiently integrate and test the code base and much of it did not happen adding to the technical debt.

Part of the development work was contracted to vendors from a neighboring kingdom and saw rapid increase in the team size. Transformation started with one vendor team in the first increment and by the fifth increment it had grown to fourteen teams. It was conceived as the need of the hour. But what it did to the transformation was damaging. Adoption of the framework was done in many different ways and in many cases in a wrong manner, as collaboration became a challenge due to the rapid growth. The influx of so many fresh people into the system diluted the effectiveness and depth, pace and purity of the adoption. Existing teams were split and assimilated into the various increments as mentors to fresh talent, and hence the teams never really reached the sustainable performing state during this period.

In the middle of the transformation the king and his courtiers decided to do a restructuring of the kingdom to bring about some cost effectiveness and expelled many experienced and knowledgeable subjects from the kingdom. This had a negative impact on the transformation instilling fear in the subjects. It lead to a lack of trust and collaboration and stoppage of open communication at all levels. This in turn resulted in dilution of the underlying principles of the SECURe framework, increase of dependencies, lack of motivation and ownership etc. It was very unfortunate that during the time of a drastic change in mindset, when trust had a very important role to play, such an action was taken. All activities on all forums ceased in a day as if someone had hit an OFF switch.

The restructuring also led to wrong customization of the SECURe framework. Since some people in key roles were expelled they were never replaced. And the whole value-addition that the role gave to the entire framework was lost resulting in an ineffective transformation going forward. Also people tampered with the roles and responsibilities laid down by the framework in order to make their position secure and for personal gains which resulted in the breakdown of the framework. Frameworks are adopted to make transitions easy, but wrong customization of frameworks without understanding the underlying principles will have a very negative effect.

The vendor contract was revised to a fixed high level scope fixed bid contract later on during the transformation. This had some unforeseen effects on transformation at the grass root level. Previously the teams had the freedom to choose how much to be included in an iteration or increment according to their velocity. Once this contract became effective velocity became meaningless numbers. Teams were expected to deliver specified points regardless of their past performance as the revenue of vendors was linked to the points delivered and/or the capability which is a high level scope.

The King’s court was also chaotic due to frequent leadership changes and cheap politics. The engineering and product ministers and deputies were replaced multiple times. Every time a new minister was posted, his first action was to try and prove the work of the old ministers wrong. This resulted in much wasted time and effort for teams and loss of morale. The whole kingdom did only additional testing, for many sprints, just to prove that the quality so far was not good, even though only few bugs were unearthed. Wasted effort to say the least. Result was total inattention to result.

The kingdom slowly declined and collapsed.

Everyone learned their lessons.

Few things to take care of during an agile transformation

1. Coaching at all roles and levels is equally important
2. Adopting good engineering and DevOps practices are very important
3. Rapid increase in team size is not good for transformations
4. Restructuring of organisation is better avoided during a transformation
5. Customization of frameworks should be done without conflicting with underlying values and principles
6. Fixed high level scope fixed bid contracts are better avoided
7. Frequent leadership changes are not good for transformations

Disclaimer: All characters and events are imaginary, all views are personal