What I learnt in first two years of Agile Implementation

Numerous agile frameworks are available in the market today, each one claiming to help implementation of common agile principles in different forms and manner. We, at BluePi, started our official agile journey almost 2 years back. Before that, agility was demonstrated at personal level by few individuals but was not a common organization wide practice.

Two years back we decided that we need to bring transformation in our processes especially the way execution of the projects are carried out which includes,

• Ability to foresee the bottlenecks in projects and work towards those in advance like, resource availability, scope management of projects.
• Create enough visibility in the project delivery pipeline and inform customer about delays in advance. This also includes, keep customer informed in advance about delays which their dependencies may cause.
• Gather enough data to make informed decisions on project health, timelines, budget etc.

With above objectives in mind, I started reading about Agile frameworks, which believe me, after reading two books, I felt empowered and excited enough to solve every problem of the organization and make it next Google of the world. Alas! that didn’t happen. I fell short of much of my expectations and others as well.

What I learnt are the pitfalls in Agile Implementation

Agile is not a magic wand

First thing I realized after couple of months of failure that Agile is no magic wand to fix the organizational issues. As much as easy it is to understand, it is much more difficult to follow in reality. Unlike coding, one cannot google it, train others with sessions and make an agile savvy team overnight. It’s a mindset and culture shift of everyone, top to bottom. Agility is a habit, which must be de-facto in any situation and since humans love inertia, letting go of existing habits is very difficult. So it needs a lot of patience, belief and persistence to steer your team and in turn organization mindset towards agile mindset.

Results often take time to appear and as an agile coach one needs to ship sail under control and steer it time in time out towards the goal. Also I understood that agile frameworks are not the solution in itself to fix the organizational deficiencies but it helps in surfacing those issues while team and organization try to find the fix of those issues by themselves and verify using agile processes that those fixes actually work.

Let your team fail

This may sound contrary to belief but the fact is no one learns as much from their successes as they do from failures. While I tried to keep my teams falling short of the expectations, I realized pretty soon that team will fail during first time of agile implementation. As much as agile looks easy, its difficult to follow because as said above, it’s a mindset change. Team members are so much wired of someone else telling them what they need to do that they often feel that this new found freedom is overwhelming. Most of the times, response of a scrum master in such cases is they try to resurrect the team morale by handholding them like earlier times which does more harm than good for the team.

Being agile is like learning to swim. One feels out of breath, fears of drowning, try some radical ways to save oneself but till one gets into water and learns how to be calm, it’s not possible to learn swimming. One needs to embrace the fear and learn how to float first before they can swim. Similarly scrum masters need to help team in floating first and then teach them to paddle. Team and in turn organization may fear for their life but rewards are enormous.

Back your Hunch with Data

While lot of agile concepts feel alien and philosophical in nature, scrum masters often feel powerless in what they can do in improving the Agile adoption in team and company overall. But agile adoption is only successful when it is backed with data. Data when collected correctly and adequately, surfaces the areas where team is lagging and fixing those areas or even making team aware of the shortcomings can go long way in adoption. Most of the scrum masters focus on velocity, cycle time, sprint burndown charts to see how team is doing. Though useful these are all lagging indicators of team’s performance. A whole iteration is required to identify these metrics and with a small duration projects like we have in BluePi, most of the time project is over before any significant change can be brought.

A scrum master can only help when he understands the underlying reasons for dipping velocity, long cycle times. Some other metrics like team’s day-to-day utilization sometimes can give a better view of whats blocking the team. In my teams, this has lead to unearthing many interesting observations like team is too much dependent on one of the team member who is becoming bottleneck or that the customer himself is bottleneck. Similarly tracking how fast tasks under stories are moving on day-to-day basis can unearth many underlying issues of the team. So a scrum master needs to understand what data makes sense and deep dive to find the leading indicators of the team’s performance. Also processes must be setup such that team does not feel overwhelmed while those processes help team improve a bit on daily basis.

In a nutshell, Agile implementation will not fix all the issues one may have in the organization. Instead anything that it will do, is to make your teams slow initially but also surfaces issues which are often pushed under the carpet. A scrum master and team must be enabled and informed enough to help themselves sail through the cloud of storms towards the bright sunshine of self organization.