How to improve productivity in agile scrum teams
Agile working is about flexibility, responsiveness, and balancing user and business needs. Consequently, Agile frameworks – such as Scrum – have achieved widespread mainstream acceptance and use in the software development industry. According to the Agile Manifesto, “The best architectures, requirements, and designs emerge from self-organizing teams,” and, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” But how do we define Agile productivity, measure it, and improve productivity in Agile teams? Find out in the article!
Table of contents
Agile software development relies heavily on teams and team productivity for success. Let’s look at some Agile productivity metrics and the factors that influence Agile team performance.
How to measure team productivity in Agile? Agile metrics
Metrics can be tricky. Nobody wants their performance to be driven or judged by statistics alone. Yet without some form of objectivity, any measurement of performance risks being purely anecdotal or opinion-based. The challenge is to give the team some objective indicator of how they’re doing, without encroaching on their agile self-organization and freedom to make decisions. The following selection of Agile productivity metrics gives an insight into Agile Scrum team productivity.
Sprint burndown charts
Scrum teams work in sprints - short periods of time with specific goals that result in a fresh product iteration. At the beginning of each sprint, the team agrees the work from the project backlog it will complete. A sprint burndown chart is a visual way of tracking the amount of work done over time, as the sprint progresses.
Product or Release burndown chart
Where a sprint burndown shows progress during a single work period, a release burndown chart tracks team activity on a longer scale, incorporating multiple sprints. Agile teams are quick to pivot, changing project priorities in response to changing circumstances. Sprint burndown charts usually show a consistent downward trajectory as work is completed. A product burndown chart reflects changes in priority (usually associated with additional or different tasks being added) to give an accurate ‘bigger picture’ perspective.
Velocity or Speed
Velocity is simply how quickly the team completes work during a sprint, often measured in work hours. This metric feeds back into the planning and forecasting process. Velocity indicates how quickly the team is likely to get through the remainder of the project backlog. Velocity can be used to track a new team’s development (they speed up as their collaboration improves), show whether ongoing performance is consistent, and act as feedback on changes to processes or ways of working (faster indicates the change was an improvement).
Cumulative flow diagram
Moving on from daily or sprint updates, the cumulative flow diagram represents the project as a whole, showing the user stories that have been created, are currently being created, and are waiting for work to begin. A big advantage of a cumulative flow diagram is that it monitors the work in progress (WIP). If the WIP begins to grow, that’s a warning sign – perhaps that tasks are taking too long, that the product backlog is getting out of control, or that there may be a bottleneck in the team’s workflow.
Benefits of Agile productivity metrics
The advantage of using Agile productivity metrics is that they act as early warnings when the project is at risk of derailing. Examples of warning signs are:
- The team regularly finishes sprints early (not committing to doing enough in their sprint planning).
- The team is missing sprint goals (committing to too much).
- The work is ‘burning down’ but is frequently ‘topped up’ as priorities change and features or tasks are added (this is potentially time to revisit the original project goals and assumptions).
- Velocity is irregular, possibly a warning of inefficient work estimation by the team.
- Growing levels of work in progress may indicate the team is not closing issues that are no longer relevant.
These are not the only metrics for Scrum team productivity. Others may be less agile-related but still relevant to the design and development of digital products, such as the number of bugs or defects discovered (both during development and after release), the level of technical debt incurred, and the number of user requests for support or help.
How to improve Agile team performance? 8 factors influencing productivity
Metrics and measurements are important but what can you do if those metrics begin to show low or falling team productivity? What are your potential productivity boosters that will impact the team’s work?
1. Consider Agile team size
Scrum development teams are self-organizing, working together with stakeholders to identify and deliver project priorities. Scrum comes with a range of tools and techniques to facilitate this kind of productive independence (for more on the benefits of self-organization, check out our article on why we don’t have project manager roles at Boldare!)
Agile team size is an issue. Too big and the decision-making process slows down, communication is strained, and time can be lost in lengthy discussions. The ideal is a team of three to nine people.
If the project is large enough to need more people, e.g. you’re building a range of products and require a bigger team, consider using Nexus Scrum which can be used to coordinate multiple Scrum teams.
2. Don’t take shortcuts with the product backlog
Clarity on what needs to be done and the order of priority for development comes from the product backlog and user stories the team puts together. Insufficient detail in user stories or the backlog leads to uncertainty and a lack of joint focus in the team. Spending a little extra time working through the product vision up front and creating user stories with enough information is better.
3. Keep everyone goal-oriented
Acceptance criteria for product iterations and definitions of done are critical for productive agile working. When the whole team is involved in discussing and agreeing on these key outcomes, it is focused on delivering the right work.
Acceptance criteria influence both the design and development work and the project’s testing strategy, ensuring that the right factors are checked before work is signed off.
4. Meetings, meetings, meetings…
Regular meetings are a key feature of agile working and the scrum framework.
- Sprint planning meetings should be ambitious but realistic, focusing the work of the sprint on the project’s leading priorities.
- Sprint reviews and sprint retrospective meetings keep the work on track and enable the team to look at the project from the outside, ensuring the process works for the team and the project’s benefit.
5. Transparency
People work better when they’re not in silos. A person who knows what they’re doing and also what their teammates are doing, and how that relates to and impacts their work can see the bigger picture. That perspective leads to better decisions, better quality products, and more efficient teamwork.
That transparency includes openness about the metrics and measures in use (put those burndown charts where everyone can see them!), but also a common understanding around priorities, roles, and skills. At Boldare, we have worked with a policy of radical transparency for some time now.
6. Continuous improvement attitude
In teamwork, mindset is everything and a mindset of continuous improvement is hardwired into Agile working; as seen in the final statement of the Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
This links back to the sprint retrospective meetings to constantly scrutinize and improve the way the team works. It goes further. When a philosophy of continuous improvement (including the belief that improvement is always possible) is embedded in the team, it is constantly searching for more effective (and productive!) ways of working.
7. Remove barriers and obstacles
External factors, unexpected interruptions, and unforeseen problems are normal occurrences in any project. Part of the role of Scrum master on the development team is to support, guide, and facilitate the development process, including using their Scrum and Agile expertise to anticipate and head off likely issues. The more issues can be spotted before they arrive, the less time the team wastes on non-productive work.
This can be especially true when working on scaling an existing product – while the team is working on the new or improved features, the product is still in use and users are flagging up fresh issues.
8. Equip the team with the latest tools
How does the team communicate? How does it manage and keep track of tasks and priorities? Are your developers up to speed with the latest development tools for integration, tracking changes, etc.? What about the latest frameworks and development practices? Visioning, product backlogs, and sprint planning help the team know what to do, but do they have the best tools to achieve that goal?
Anti-patterns in Scrum Agile development teams
Having outlined the key productivity factors, it’s worth flipping the perspective and listing some Scrum anti-patterns, or ‘no-no’ behaviors; often these are attempts at shortcuts that end up costing you more time or resources.
- Setting unrealistic target dates or deadlines as ‘motivation’;
- Agreeing on sprint goals that are too ‘easy’;
- Being overprotective of people’s specialisms or areas of expertise;
- Putting off tackling problems or defects to meet a deadline;
- Seeing changing circumstances or requirements as a problem;
- Not keeping the product owner or other stakeholders in the loop;
- Being distracted by interruptions or non-goal-related issues.
How to improve Scrum team productivity? Summary
The Agile philosophy and frameworks such as Scrum have productivity built-in. Like any other ‘system’, you can go through the motions, have all the right meetings, and so on, and still work inefficiently and miss deadlines.
To maintain high levels of productivity in your agile teams, first you need to agree exactly how you will measure that productivity – define it in concrete terms using specific Agile productivity metrics.
Next, while the Agile Manifesto paints a clear picture of the ideal agile development team and project, you need to consider the factors that determine whether that team and project operate productively or not: including the attitude of the team, the systems that fit the project, and how transparently they are used.
FAQ:
Q: How do you specifically adjust team sizes or structures in agile environments when a project scales up unexpectedly?
A: In agile environments, scaling up a project unexpectedly often leads to the formation of additional scrum teams rather than expanding existing teams. This approach maintains manageable team sizes, ensuring that each group remains agile and focused. Teams are organized around specific features or functionalities, using frameworks like Nexus Scrum for effective coordination and integration across the project.
Q: Can you provide specific examples or case studies where these agile productivity metrics have been successfully applied?
A: Companies such as Spotify and Google are known for their effective use of agile methodologies, including productivity metrics like velocity and sprint burndown charts. These organizations have adapted agile to fit their unique cultures and operational demands, leading to enhanced productivity and innovation. Their experiences are often highlighted in technology conferences and industry publications, serving as valuable case studies for the benefits of agile metrics.
Q: What are some common pitfalls or challenges when implementing continuous improvement practices in scrum teams, and how can they be overcome?
A: Common challenges in implementing continuous improvement in scrum teams include resistance to change, unclear improvement objectives, and inadequate feedback mechanisms. To overcome these hurdles, it’s crucial to establish clear, measurable goals for improvement efforts, promote a culture of openness where feedback is actively sought and valued, and ensure regular and actionable retrospective meetings. Educating teams on the importance of continuous improvement through ongoing training can also embed this mindset deeper into their daily routines, making continuous enhancement a standard part of their workflow.
Share this article:
