Battling the False Start(s) of Agile Transformation
Sekhar Burra
Frameworks are good, but they are not everything: Never miss fantastic posts such as this one.
Framework promoters might be very upset at this statement, but I find it indeed, very true. I noticed several times that decision-making leaders or specifically few immature coaches, chasing a framework, rather than assessing weather fits the real purpose. In fact, I like every commercial framework in the market, could be Scrum or XP or SAFe or Less or whatever, because they always offer me something new to learn. But honestly, I’m biased to none of these, since by no means any of these is a silver bullet. Frameworks do not solve every complex problem of the real world, since it needs lot of cognitive thinking to get behind.
Insufficient due diligence:
Many transformations are under water because there is little or no due diligence. Proper due diligence exposes the black holes, the organization readiness, hidden value, assumptions, constraints and key major impediments. Remember, the more collaboration with the client partner during this exercise, the more valuable outcome would be. Given the quantity of massive unknowns, I see transformations frequently going into troubled waters. Moreover, not knowing the areas of impact of an organization agile transformation is like driving down the hill without brakes functioning at all.
Pilots may not always uncover the big picture:
I believe most of the pilots, may not uncover what we want to see and learn. Having said that, piloting is very crucial.
In the words of Dr. Reg Butterfield, Fellow of the UK Chartered Management Institute,
“[A pilot should be] one that simulates the reality that you want in the organization and includes all aspects of the environment that it will be expected to operate in. It must link into and involve the relevant management and staff who will be expected to operate in this new way if it is shown to be appropriate.”
Many pilots are often excused from the rules that other projects have to follow in an organization, and hence most of the pilots go well. Therefore pilots do not inform enough agile transformation challenges. We may not know how the pilot learning’s may work unless and until, the transformation applied to broader business units of an organization.
Scaling to descale or rescale?
Scaling being one of the hot topics in the agile world, it is truly plays significant role in achieving enterprise agility. However, on the flipside, blind scaling often leads to confusion, chaos and critiques. Try doing the basic scrum (or XP or any other agile framework) well, before you scale. If you try to scale agile teams without proper basics in place, you are simply scaling your problems. For example, I have seen a development team that needs 2 additional sprints to integrate their own previous 4 sprints of work. There was no automation testing in place. I have seen this team struggle a lot, when they were scaled, which means, they need to integrate their work with few other peer teams. This ultimately dragged down the productivity of the team and sometimes impacted the quality too.
There are few heavy frameworks in the market that even go to extent of prescribing scaling waterfall teams to agile. However, I’m not a big fan of such ruthless scaling. If scaling adds no value or pulls downs the productivity, I prefer not to go for it. Unless I see a reasonable value to opt for scaling, I prefer running the show with a simple technique like “Scrum of Scrums”.
Deemphasizing roles
If you unpack the first statement of Agile Manifesto, it ultimately translates into getting the right people into right roles must be more important than following traditional processes. Given the nature of transformations, the ground reality seems to be vastly different. Incompetency, low cost and let it go attitude kills the prominence of several important roles during transformation. For example, I have seen a project manager becomes an agile coach, when an organization tries to move to agile. How can we educate the leaders in this organization to have a competent change agent in place to derive the return on investment? The same story repeats itself for other key agile roles as well. Do you see any value in doing half-baked agile? On the contrary, the world on the other extreme side, talks about being agile, than just doing agile.
Complicated Metrics:
Transformational metrics are often too confusing to deal with. Several metrics are formulated not only to measure the impact of change but also the software delivery. This is a situation where you see lot of pieces moving within an organization. In addition, the complexity of waterfall organization structures, hierarchies and cultures create polarizing forces to make metrics directionless. There is no easy way or prescriptive way to get out of this metrics mess. Metrics should be collected with a minimum of disruption to the team so that the team performance is not impacted by the very act of measurement alone. Failure to collect and monitor the proper metrics could put the team at risk of reverting to waterfall development behavior, in which the team thinks in terms of long periods of time between deliveries rather that continuous delivery and the transparency that affords. For example, in an agile transformation it is useful to measure the “cycle time” – the time to get new ideas from concept to production use – and show that cycle time decreases as a result of the use of agile methods. The change in cycle time is a transformation metric.
Delivery by hook-or-crook:
Agile development is not only meant for valuable software delivery, but it has much more in it. Most importantly, agile way of working challenges every traditional practice of software development. The change may be too big for several organizations. Agile also helps in building great teams and leaders, revisiting the value proposition of every business unit that triggers the real culture change and a paradigm shift in software delivery. However, many waterfall-ists in the agile world have buried this basic intent. These waterfall-ists with delivery only motive always come in between the authority and team empowerment. Though, I emphasize that software delivery is important, but investing on building great teams that build vibrant organizations is even more important.
Sekhar is currently working as a Transformation coach in one the big four consulting firms based out of Singapore and Hyderabad, India. He has several years of Agile experience as a developer, Scrum Master, Product Owner, plus leading and coaching various Agile teams. He is a Certified Enterprise Coach (CEC), Certified Change Management Practitioner, Management 3.0 trainer and SAFe Program Consultant (SPC). He had led three large scale agile transformations so far.
Sekhar is an Engineering graduate and an MBA from one the premier B school from India. He is a well known speaker across various agile conferences in the country. He is on the editorial Board Member of ttp://www.transition2agile.com/ He is also a reviewer and contributor of the book titled- “The Human Side of Agile”, and the “The Agile Mind-Set” authored by Gil Broza.
Jpeg
Sekhar is currently working as a Transformation coach in one the big four consulting firms based out of Singapore and Hyderabad, India. He has several years of Agile experience as a developer, Scrum Master, Product Owner, plus leading and coaching various Agile teams. He is a Certified Enterprise Coach (CEC), Certified Change Management Practitioner, Management 3.0 trainer and SAFe Program Consultant (SPC). He had led three large scale agile transformations so far.
Sekhar is an Engineering graduate and an MBA from one the premier B school from India. He is a well known speaker across various agile conferences in the country. He is on the editorial Board Member of ttp://www.transition2agile.com/ He is also a reviewer and contributor of the book titled- “The Human Side of Agile”, and the “The Agile Mind-Set” authored by Gil Broza.