Introduction
When I first encountered the Agile framework, I was awestruck by how software engineering teams worked so differently from what I had been used to and achieved much better results than I had seen before. I saw developers work in groups of two or three at the same workstation for hours on end, I watched Post-It notes move rapidly across a whiteboard labelled with ‘To Do’, ‘Doing’ and ‘Done’, and I viewed monitors showing the results of hundreds of unit tests running constantly and rarely failing. The notable absence of multi-paged design documents and architect drawings, the presence of customer representatives among the engineering teams, and the collaborative layout of the environment hinted at the reasons why Agile exists. The authors of the Agile manifesto value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
I was excited by this new way of developing software and worked with my peers to introduce automated testing, pair programming, and scrum boards. However, the pressures to conform to more traditional ways of working bore down on us constantly during those early days. Today, Agile has gained widespread acceptance and many organisations have adopted Agile as a way to deliver software. But, over time, I have witnessed many of the core principles of Agile become neglected affecting organisations’ ability to deliver products that customers actually want. Here are the five mistakes I regularly see Agile teams make.
One – scrum boards as Gantt charts
The scrum board is a simple concept. It consists of a list of work items to do on the left, a list of work items in progress in the middle, and a list of work items completed on the right. Engineers pull items from the todo list, one at a time, move it to the the ‘doing’ list until it is completed, and then move it to ‘done’. Yet, this basic design has grown in complexity over time. So now scrum boards are used to plan ahead, often in time-limited iterations called sprints. During planning sessions, delivery teams are instructed to add their work items to the board representing when they are likely to do the work. It’s no longer documenting work in progress, but documenting work scheduled for… I have also seen swim lanes added to the boards to represent the various disciplines required to complete the scheduled work items. Standing back from this board, and looking at it holistically, I see a Gantt chart, which is a tool used for planning projects in a linear fashion. Typically, it looks like this…
The main reason for this phenomenon is the need for organisations to plan ahead. They need an understanding of when projects will be completed so that stakeholders can forecast revenue. Agile only plans one sprint at a time, usually covering the next one or two weeks. Although this doesn’t fit with long-term planning, it is more accurate. In reality, planning several sprints ahead is never accurate, especially if your engineers are being asked to plan for a sprint several weeks or even months away. Instead, you need to return to basics and start working on the iterative development and delivery of working and demonstrable software at the end of each sprint. Scrum boards need to focus on work in progress, while the todo list is refined by the product owners as the product evolves and customers provide regular feedback.
Two – velocity measured as time
The second mistake I see is the use of a distinct time periods to measure velocity of a team, normally based on resource availability. For example, I often see sprint metrics that show a velocity calculated by the number of resources multiplied by the number of days in the sprint. So, if there are eight people working in the sprint for two weeks, the velocity is measured as 80 (days). Sometimes, an arbitrary number is used as a factor to indicate the proportion of the day engineers realistically work. So 80 may be reduced by 20% to give a velocity of 64 days. This is not velocity.
The velocity of a team (which is also an indicator of capacity) should be calculated based on the amount of work that can be completed by a team based on previous sprints. This work should be represented as story points, which are comparative measures of how much work is required to complete a work item. For example, you could distinguish work items by relative t-shirt sizes (small, medium or large), or by numbers of the Fibonacci sequence (1, 2, 3, 5, 8, 13). In each case, engineers estimate work by working out whether one work item is smaller, the same as or larger than another work item. Using the Fibonacci sequence as a guide, if a team is able to complete 3*5 and 2*8 sized work items in a sprint, the velocity is recorded as 31. Which means work items measuring 31 story points can be pulled into the next sprint. If the team completes 31 worth of work items before the end of the sprint, the velocity of the next sprint can be recalculated accordingly. At no point should engineers determine their velocity based on actual units of time. The goal, of course, is to continuously look at ways of increasing velocity by reducing impediments. This brings us on nicely to the third mistake organisations make.
Three – no continuous improvement
A key component of Agile is the ability to provide continuous feedback using the scrum board as evidence of progress made during each sprint. This feedback provides early insights into where there are delays or impediments that slow the delivery process down. As a result, it is easier to remove those impediments and accelerate the progress of work items along the scrum board. The main cause of slow progress is wasted time, such as waiting for a response from an external team, trying to figure out a difficult algorithm or understand a poorly defined requirement. In some cases, your engineers may decide to proceed without waiting for a response, take short cuts in writing a complex piece of logic, or use their own interpretation of a requirement. These assumptions lead to mistakes that require time-wasting remedial activities. In my experience, these impediments happen time and time again, with no real desire to fix the underlying causes. As a result, velocity stagnates and engineers continue to work on activities that do not add business value.
The resolution simple. Everyone in the Agile team must work on continuous improvement and to reduce waste. If external parties are required to remove impediments, then make sure they are engaged in helping your Agile teams with solutions. If one engineer is struggling with an algorithm, breaks a build or is unable to complete a work item, then pull all the resources together to resolve the issue as quickly as possible. Every opportunity must be taken to continuously improve the work flow and reduce waste. It is the responsibility of the whole Agile team to look for and put in place processes to reduce bottlenecks. Teamwork (or lack of) is also a factor in the next mistake that organisations make.
Four – stand-ups based on individual activity not team
Every day, your Agile teams meet, preferably at the start of the day, for a meeting that is often referred to as a ‘daily stand-up’. The focus of these meetings is to ensure that everyone is able to complete their allocated work items during the sprint. They are meant to last no more than 15 minutes. Typically, these scrums involve each team member answering the following three questions:
- What work did you do yesterday?
- What work are you doing today?
- Are there any blockers preventing you from completing your work?
However, these three questions focus too much on the individual. I have seen many meetings become a soundboard for engineers to talk about how they are working through a problem, or how they “worked on work item x yesterday, will continue to work on work item x today and there are no blockers”. Conversely, you see the eyes of engineers glaze over as they listen to each team member talk about their own work items in detail. Unfortunately, these meetings become wasted time due to the focus on individual progress. If we want to know about how each individual is progressing, we need only glance at the scrum board. Here we may see that one of your colleagues has had a small work item in the ‘doing’ column for longer than expected, or another colleague is working on a similar work item and therefore you should consider pairing up.
The value in the daily stand-up is not to determine how individuals are doing, but know how the team is progressing. Therefore, during the daily stand-up the team should ask the following three questions:
- Did we, as a team, manage to complete what we had hoped to complete yesterday?
- What are we, as a team, planning to complete today?
- What is stopping us, as a team, from completing these work items?
This emphasis on the team allows everyone to focus on the delivery of value to the business by giving the team an opportunity to quickly fix an issue. For example, during the meeting, an engineer may state that because a unit test keeps failing, they are spending too much time on a work item. The team can decide that the focus of the day is for everyone to help the engineer complete the unit test successfully. The whole team can move forward as a single entity rather than a group of individuals working through their own work items.
Five – demonstrations are progress so far
The fifth and final mistake I see Agile teams regularly make is to go into a demo at the end of a sprint to show off work in progress and not work completed. Realistically, the end of sprint demos should allow engineers to show the product owners the functionality of a shippable product. However, I’ve not seen this happen too often. Engineers wax lyrical about how this amazing piece of functionality will impress customers when it’s finished, but there are a few problems which they are hoping to fix in the next sprint. The main reason for this mistake is because engineers take on too much during a sprint. Rather than working on the features that add the most business value, they try to deliver everything in one go. Typically, 80% of the value of your organisation’s products comes from just 20% of the functionality. Unfortunately, the demos do not focus on the 20% of completed functionality that adds business value, but a proportion of the whole functionality that the engineer has completed. In other words, they demonstrate the 80% of work completed that only generates 20% of value to the business.
This returns us to one of the main values of the Agile framework: working software. Every sprint should deliver a working product that can be used by your customers. Each sprint should focus on delivering real business value that can be demonstrated to your stakeholders who can then make the decision whether to deploy the working product to customers.
Conclusion
If you have adopted the Agile framework but are not reaping the benefits it brings, maybe you are making some of the mistakes listed here. Agile is not a collection of ceremonies such as scripted stand-up meetings, long-term sprint planning and capacity management. It is a framework that gives your teams autonomy to work on the features that add real value to your business that can be delivered at the end of every sprint. Often, waterfall methods are embedded in your organisation’s culture and Agile is used to frame the waterfall process. However, for Agile to be truly effective, you need to embed the values of Agile into your organisation’s culture. Ultimately, you need to avoid making these mistakes if you want to fully benefit from Agile.