The trigger for this blog is a blog I recently came across written by a developer on failures with agile. He had actually talked about why organizations are bound to fail with Agile. This was a very strong message but I must say that the author had lots of valid concerns. And the interesting thing was that, while he talked about specific issues with the way Agile (more specifically Scrum) is typically implemented in organizations today, he had also suggested some ways to work around them – even if they may not satisfy Agile/Scrum principles. I wanted to take three real concerns that he brought out, and talk about my own recommendations based on experience
1.Too many / too much time with Agile meetings
This is an issue that has been highlighted by many organizations when I begin my coaching stint with them. Let me illustrate with some simple arithmetic for a typical Scrum implementation. If you take a typical team that implements a 2-week sprint – at 15 minutes per day (for 10 days) for stand-ups, up to 4 hours for planning, one hour for retrospectives, one hour for sprint reviews and just one backlog refinement session of one and a half hours during the sprint – we get 10 out of 80 hours for each person. That adds up to 12.5% of the team’s effort overall. This is a bare minimum and any team that is inefficient in the way they do stand-ups or any of the other events could easily end up spending 15 to 20% of their effort on these events. And we are not even talking about technical meetings – such as design discussions, code reviews etc.
Now the obvious question, in my opinion, should not be what %effort a team is spending in meetings but whether the meetings are effective and the team believes they get value for the effort spent. To take an example, if daily stand-ups enable teams to collaborate and track the team’s deliverables better, then there is nothing to worry about. In this regard, the team does not even need to wait till the retrospectives to figure out how they are feeling about their stand-ups – they can do a quick reflection even every day for a minute at the end of the stand-up to ensure people are feeling energetic, there is a sense of urgency and the team believes time spent in the meeting is well spent. The key role in ensuring all agile/scrum events are effective is obviously that of the Scrum Master.
2. The role of the Scrum Master
This is an area where every organization literally learns the hard way. Most start with technical people as part time Scrum Masters – whose only job is coordinating scrum events and following up on actions – and move to the other extreme of having dedicated Scrum Masters (sometimes non-technical), mostly on the advice of their Agile coaches. When they do this, they find there are newer, and more often, thornier issues depending on how (in)effective their Scrum Masters are. I have personally seen organizations that have spent huge effort / money in building a centralized pool of specialist Scrum Masters (mostly lateral hires) but don’t know how to make it work or what to do with those Scrum Masters when they turn out to be ineffective. This is especially true in a highly technical product environment. My view on this subject is to pick technical team leads who are potential leaders of tomorrow as SMs.
To me SM is a leadership role and every individual you want to grow to being a technical leader or manager in the organization in future, must have gone through the SM role at least for a couple of years before they take on that leadership role. This role is about getting the best out of the team, about developing relationships with other organization functions to help resolve the team’s bottlenecks timely and effectively and if you are putting a half-hearted effort as an organization in leveraging this role, you are bound to fail.
The question of whether it is a full time or part time role is relatively insignificant – a good SM can handle two (and at best three) teams if he/she is a full-time role but it may be a better idea for a tech lead of the team to take up this role (assuming he/she fulfills the criteria I mentioned above) on a part time basis (could be 40 to 50% time) while using the rest of the time for his/her other responsibilities as an individual contributor.
3.Agile Leadership
One of the major reasons for failures with Agile is the lack of senior leadership understanding of what they need to do to succeed with Agile. They often think that Agile is about implementation at a team or a program level and they don’t need to do anything different themselves. The other extreme happens when it is implemented as a top-down directive (either due to market / competitive pressures or other such reasons). Neither of these helps you succeed as an organization.
Agility is about a cultural change that needs to percolate across the organization and needs to begin with senior leadership living the change they want to see. PM Power recommends a sandwich approach to the transformation with cultural change initiatives, people development, systemic improvements like waste removal, orchestration of flow and business value etc. driven from the top and team level practices and coaching support, at the program level, to ensure the spirit of agile is implemented. There has to be a special emphasis on key roles such as that of the Scrum Master and Product Owner and appropriate training / coaching and development support for such roles from a leadership perspective.
While these are three of the top issues to be dealt with in my opinion, would love to hear from you on what issues have bothered you in your organization that have prevented you from succeeding with agile.
JV
