I recently had the privilege of being a guest on Greg Miller’s podcast “The Agile Within”. In the first podcast Greg and I talked about how the Scrum value of Focus leads to high quality and a more productive Scrum team. In the second podcast we discussed the importance of Commitment and how the Scrum Values all work together for the betterment of the Scrum Team. You can listen to these and other episodes of The Agile Within on Google Podcasts, Buzzsprout, and most other major podcast platforms.
It can be challenging for teams new to Scrum to get value from the Daily Scrum meeting. The natural tendency is for the team to treat the Daily Scrum as a status meeting, where everyone on the team reports their status to the Scrum Master and/or the Product Owner (or even worse their manager). This is particularly true for teams made up of people that have spent their lives in a command and control environment, where meetings are an opportunity to show off in front of your boss and peers by telling everyone how busy you are. This might make you feel good, but provides little value to the rest of the team.
While there may be some benefit to simply letting everyone know what you’re working on, the real benefits that come from a well-run Daily Scrum are realized when the team uses it to plan their work as a team. As stated in the Scrum Guide, the Daily Scrum is an opportunity “to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.” Remember, the team owns the responsibility for completing a product backlog item (PBI), not the individual. Scrum teams are self-organizing, and the Daily Scrum ensures that every day the team plans how they intend to “accomplish the Sprint Goal and create the anticipated increment by the end of the Sprint.”
Some tips for having a more effective Daily Scrum:
1. Always start the meeting on time, and keep it to no more than 15 minutes. Starting on time reinforces the importance of the meeting, and meetings lasting longer than 15 minutes are a sign that something is wrong: either the team is too big or you’re using the meeting to solve problems. Table any issues or problems until after the Daily Scrum; you can always meet right afterwards to have any needed discussions.
2. Consider asking the team at the end of the meeting “how confident are you that the team will meet the Sprint Goal and complete all of the items in the Sprint Backlog?” Have them vote simultaneously using a scale of 1 to 5, with 5 meaning that they are sure that they will meet the Sprint Goal, and 1 meaning they can see no way the goal can be met. If you get all 4’s and 5’s you’re good to go, but if anyone votes a 3 or less have a discussion after the Daily Scrum as a team on how to get back on track.
3. Try organizing the meeting by PBI rather than by person. Instead of having each person take turns answering the 3 questions, look at each PBI in progress and discuss as a team what it will take to move the PBI to done.
The Daily Scrum is an important “inspect and adapt” opportunity for the Scrum Team. Don’t waste it by letting it become just another status meeting or by just going thru the motions. The goal is not to “do Scrum” but to continuously improve by being Agile.
Organizations look to scale their agile teams for any number of reasons. But is scaling the answer? And what exactly is the real question?
Why do you want to scale?
As agile software development is becoming the norm, we get asked a lot about scaling agile teams. Our first question is always “Why do you want to scale?”. Are you looking to have multiple teams working at the same time on loosely related projects (each with its own product backlog), or have multiple teams all working on a single project from a single backlog? What problem are you trying to solve by scaling? Do you believe that you need to scale because you have big projects, or because you have lots of developers that you need to keep busy? Are you hoping to increase your overall velocity by getting more done sooner? Or is it because your organization has announced an “agile transformation” and you’ve been told to “scale” to support that?
For most teams all of these factors are involved in their desire to scale. But is scaling really the answer?
Scaling is hard
Whatever your reason for scaling, our first piece of advice is to do everything you can to AVOID scaling. Creating great agile teams is hard; scaling them is even harder. Scaling magnifies any dysfunctions you have at the team level, so don’t consider scaling until you are really good at independent teams. Issues caused by scaling include:
- Cross-team dependencies, which are difficult to track and visualize. Each additional team exponentially increases the number of dependencies between units of work and the communication channels between the members of the teams.
- Integration of work becomes more challenging. At some point (at the end of each Sprint in Scrum) you need to integrate all of the work into something that is potentially shippable to the customer.
- Brooks’ Law. We’ve known since the seventies that adding people to a late software project makes it later (from The Mythical Man-Month: Essays on Software Engineering, 1975). Adding more teams does not ensure that more work actually gets done.
- The J-curve Effect. Any change made to a people-based process will cause productivity to initially decrease (disruption period) as people get used to the change. Hopefully productivity does eventually increase (making the curve look like a ‘j’), but the depth and length of the disruption period is difficult to predict.
What to do instead of scaling
There are several things that you can do to improve velocity and throughput with just a single team. Things to consider before scaling include:
- Are you really being Agile? Make sure you are not just DOING agile but are BEING agile by living up to the 12 principles outlined in the Manifesto for Agile Software Development. We see many teams that just go thru the motions of doing Agile and do not get the benefits of truly being Agile.
- Have you automated everything you can? Automation is the key to an Agile workflow, and manual processes cannot keep up with the pace of Agile software development.
- Is the work properly organized? You can minimize cross-team dependencies by creating feature-based teams that can work with minimum interdependencies.
- Be the best team you can possibly be. You may find that you can create enough value without adding new teams.
If you must scale
There are several frameworks and methodologies for scaling Agile teams:
- LeSS – Large Scale Scrum
- Nexus – Scrum.org
- SAFe – Scaled Agile Framework
- Others include DAD, Scrum@Scale, and RAGE.
Let’s take a look at the three most popular scaling frameworks.
LeSS (Large Scale Scrum)
LeSS was created by Craig Larman and Bas Vodde based on their experience working with large telecom and finance companies in Europe. Basic LeSS is designed to work with up to eight teams; LeSS Huge is meant for up to a few thousand people working on a single product.
The LeSS framework:
- Adds three new events to basic Scrum (Sprint Planning 2, Overall Retrospective, Overall Product Backlog Refinement).
- Is based on the following three principles:
- Teams should be deep and narrow over broad and shallow
- Requires top-down and bottom up support
- Uses volunteering to get work done
The advantages of LeSS include:
- It leverages what you already know about Scrum
- It’s great for collaborative organizations
What LeSS does not do well includes:
- It doesn’t address enterprise-level processes
- There is no project/program management
- Places lots of pressure on the single Product Owner
Nexus was developed by Ken Schwaber (the co-creator of Scrum) and his team at Scrum.org. Basic Nexus is designed to work with 3 – 9 Scrum teams; Nexus+ is their framework for when ten or more teams are working on a single product.
The Nexus framework:
- Adds 1 new role (the Nexus Integration Team)
- Creates five new events (Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint Retrospective, Refinement)
- Adds three new artifacts (Nexus Sprint Backlog, Nexus Goal, Integrated Increment)
The advantages of Nexus include:
- It is Scrum scaled by the father of Scrum
- Nexus works well in collaborative organizations
The disadvantages of Nexus are:
- It adds a large number of meetings to Scrum
- As with LeSS it puts a lot of pressure on the single Product Owner
SAFe (Scaled Agile Framework)
SAFe was created by Dean Leffingwell as a scaling methodology for enterprises that require a more prescriptive framework at the program level. SAFe defines four framework levels; Essential SAFe, Large Solution SAFe, Portfolio SAFe and Full SAFe.
The SAFe framework:
- Is Scrum at the team level and Kanban at the program level
- SAFe is highly structured at the product and program level
The advantages of SAFe include:
- SAFe works well in control-focused organizations
- Creates top to bottom visibility into the development process
- Gives detailed guidance at all levels
Disadvantages of SAFe include:
- SAFe is very prescriptive and structured; does not encourage experimentation
- Requires lots of training (or consultants) to implement
Which framework for you?
So you’ve done everything you can to make your single team as productive as possible, but you find that it’s still not enough and you need to scale. Which framework should you choose?
Choose LeSS if:
- You’re committed to Scrum
- Desire lots of flexibility
- Value collaboration over following rules
- Want your teams to be as agile as possible
Choose Nexus if:
- You’re committed to Scrum
- Value a framework created by the father of Scrum
Choose SAFe if:
- Want a high level of team coordination
- Desire more control over the process
- Want formal process and reporting
Scaling is difficult and not for everyone. Start with small changes, inspect the results and adapt. And whichever framework you choose, make sure you have an experienced coach to guide you.