Three Lessons from Our Glorious Agile Failures and Misuses

By Erez Morabia

At the recent annual Agile conference Beyond Agile Israel 2021, I talked about some of the glorious misuses of agile practices I had witnessed in my 7 years of experience as an Agile coach.

In this post, I will celebrate the mistakes I saw by sharing the top three lessons I learned. I hope these learnings come in handy for you in your Agile journey.

#1. Build Cross-Functional Teams, Not Silo Teams

One of the products I coached used overlapping sprints. In order to better utilize the silo teams, management decided on an overlapping sprint approach. At any given time, there were 2 sprints going on in parallel. Each sprint timebox was 8 weeks and equal to the release duration, meaning 1 sprint = 1 release.

A closer look at the sprint revealed sequential and gated development: Design > Coding > Testing > Acceptance testing. Each of these phases took about 2 weeks and was performed by a different silo team.

As you can guess, this caused multiple issues, including longer delivery times and poorer quality of work delivered, and here is why:

• First of all, because of the sequential process, where a big batch of work-items was handed off from one silo team to another, total productivity dropped, and cycle time almost inevitably ended up being close to the ‘worst case’ scenario. Each work-item was pending on all other items to finish.
• Moreover, the hand-off sequential process turned project communication into a broken telephone, when the initial comment can be misinterpreted by the final link. This also had a negative impact on the quality of the delivery.
• Furthermore, the overlapping sprints approach wasn’t very helpful for sprint planning: as teams were working on 2 parallel sprints, they had a very hard time predicting the amount of work they could deliver in each sprint. Performing sprint planning decisions based on empirical data from previous overlapping sprints was not a trivial task. Overlapping sprints also introduced additional complexity, because they required switching between tasks, which damaged productivity and reduced response time to issues raised within the sprint.

When we realized that, we decided to break down the gated phases of the silo teams and start focusing on small batches of work-items, where each work-item would be worked on from start to end.

This significantly improved the cycle-time of work-items and the quality of the product. The results opened a discussion about building cross-functional teams, shortening the duration of the sprints, and ultimately getting rid of the overlapping sprints model.

#2. Less Is More When it Comes to Scrum Boards

One of the scrum masters I coached had a huge Scrum board consisting of 6 columns for every 2-week sprint for a team of 5.

The scrum master believed that more columns would provide higher visibility and help the team achieve their sprint goal.

When the performance was less than ideal, his instinct was to add even more columns.

Unfortunately, the team suffered from low predictability, longer cycle times, and low velocity of delivered work-items. The more columns there were, the poorer team performance became.

We realized it was impossible to control the total work in progress with so many columns.

In my experience, a good starting point is limiting the number of items in progress to the team size.

Number of items = Number of people

This enables teams to concentrate on current work-items and move them faster from start to end. Having many columns makes it hard to control the limit, as each board column might need to have a limit of one.

Once we started to reduce the number of columns, it became easier to limit the work in progress, which resulted in shorter cycle-times per work-item, and greater team collaboration around the work-items. Team performance increased significantly.

#3. You Can’t Calculate Velocity with a Fixed Formula

Velocity refers to the amount of work effort a team can output within a timebox. One of the teams I worked with calculated velocity using a fixed formula.

The formula the team used was: Velocity = <Number of team’s working days> * 0.75.

Example:

Suppose we have a team of 5 developers working in a 2 weeks sprint, wherein the coming sprint 4 developers are available for 10 days and 1 developer is available for 8 days. Based on the formula, the team’s velocity equals 36 story points (48 working days * 0.75). 

The problem with a fixed formula? It doesn’t allow teams to base their planning on learning.

Moreover, the team used the term “story points” (which is relative sizing), but actually used absolute sizing (time/working-days). This made things worse, as there are certain things you can do with relative sizing that you can’t with absolute sizing. For example, a story that is marked as 3 story points can be moved between teams that have different skill sets, and still remain as 3 story points. However, a story that is marked as 3 days work, can’t be moved in the same manner (the less skilled team will need more time to deliver it).

This fixed formula method resulted in the team missing their expected velocity over and over again. The low predictability caused constant disappointment in management and teams.

Once we set aside the formula and calculated the teams’ velocity based on previous sprints, predictability increased dramatically. The sprint planning sessions got shorter and morale increased. There was no longer fixed velocity sprint by sprint, teams were no longer bound to velocity and could instead focus on quality output.

The next step was moving away from absolute sizing into relative sizing. This helped the teams save even more time in planning and enabled them to seamlessly move work items around while maintaining a predictability level.

Conclusion: Remember, Agile Is not the Goal

I’ve coached teams from different technologies, products, and cultures all over the world. No matter who or where I am working with, I always use these two main guidelines as my compass:

1. ‘Failure is a prerequisite to learning’ (quote by Eric Ries in his book “The Lean Startup”). Therefore, embrace failure as an opportunity for improvement.
2. ‘Agile is not a goal, but rather the engine to reach the goal, which is improving our business outcomes’ – this was one of the takeaways from my conversations with Dr. Jeff Sutherland (co-author of Scrum) 2 years ago, at Boston.

Agile practices are easy to understand but hard to master and implement effectively. Even having the greatest intentions can result in poor outcomes.

We must remember that agile is not the goal, but an engine to improve our business outcomes.

Keep experimenting with agile practices and accept the fact that failure is part of learning.

Let us all celebrate our glorious failures by learning from them and sharing those lessons, so we may collectively bring each other closer to success.