My previous presentations and blogs on “Great Agile Debates” have proven extremely popular, so I thought I would add to this body of knowledge with a new blog series. In each blog, I will cover five more great agile debates for your consideration. Keep in mind that my opinions are my own, and not necessarily those of any other organization I am affiliated with. I’d also love to hear what you think, so don’t be shy – leave some comments, and let’s debate!
Here are the first five topics of debate about agile I will cover:
- The Developers are a Sub-team in Scrum
- The Three Questions are Required
- A Product Goal is Not Required
- Backlog Refinement is an Official Scrum Event
- Teams Cannot Combine Different Agile Elements
The Developers are a Sub-team in Scrum
This is now FALSE! In previous versions of The Scrum Guide, the Developers were considered a sub-team within a Scrum Team, but in the 2020 update to the guide, this concept was removed. The point of this change was to ensure that the team is a cohesive whole – without having a team within a team.
The former Dev Team concept created an “us versus them” attitude between the Developers, the Scrum Master, and the Product Owner. Going forward as one united team, many things that were once in the domain of the Dev Team are now jointly owned responsibilities among the entire Scrum Team.
Further, having everyone on the Scrum Team on equal footing as team members allows people to collaborate and build trust more easily. Everyone on the team should be “in the know” on what’s happening, without any surprises from the separateness of having a sub-team.
The Three Questions are Required
This, too, is now FALSE! In the previous versions of The Scrum Guide, the three questions were, in fact, the prescribed format for running the Daily Scrum. As a reminder, the questions were:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
The creators of the guide realized that requiring the answers to these three questions was far too prescriptive. Their goal was to simplify the framework.
Many Scrum Teams had already stopped using the three questions because it felt rote and repetitive. Answering these questions didn’t really give the team the real opportunity to figure out their collective plan for the day toward accomplishing the Sprint Goal.
I myself had already stopped using this format on my Scrum Team. A far better exercise is to “walk the board” – going through your Sprint Backlog and looking at each item (either by person or from top to bottom) and its progress. Having this visual also helps to identify if there are any impediments, whether some team members are overloaded while others might not have much to do.
There are other options, as well. The main idea is that you can choose the format that works best for your team in your context. Some teams prefer to post on a collaboration channel like Slack or Teams, while others simply go round robin verbally, without focusing on what has already happened – rather, looking forward to what needs to be accomplished today.
A Product Goal is Not Required
You guessed it – WRONG! A Product Goal is now required. Prior versions of The Scrum Guide did not include this concept. In the absence of this as a requirement of Scrum, many teams and Product Owners introduced their own idea to fill the void: Product Vision.
Some people might argue that there is little difference between a vision and a goal. I struggle with this myself, especially having trained many Product Owners and helped them craft Product Vision Statements.
In training new Product Owners, I now feel obligated to include the Product Goal as it is now an official aspect of Scrum. The way I see it, these can be two separate things. The vision is the aspirational description of what the product is and how it is beneficial, which is strategic in nature.
On the other hand, the Product Goal (or goals) is more tactical, with specific measurable objectives similar to SMART goals. These provide more direction on what is needed to achieve the vision.
Backlog Refinement is an Official Scrum Event
Sorry, folks! This one isn’t true, either (at least not yet). While The Scrum Guide infers that Backlog Refinement is an important, ongoing activity, it’s not an officially recognized Scrum event.
Personally, I would like to see this added as an “official” requirement of the Scrum Framework. To be successful in any type of endeavor using Scrum, whether project- or product-based, having a properly managed Product Backlog is essential.
Many teams only do this activity on an ad-hoc basis, which is inconsistent and unpredictable. I prefer to have this activity, if running two-week sprints, on the opposite day from the Sprint Review. This ensures that Backlog Refinement actually happens regularly.
I would also suggest a timebox similar to that of the Sprint Planning event. These events are very similar, but Backlog Refinement is a preliminary opportunity for the team to review and discuss upcoming stories, answer any open questions, and gain a shared understanding of each item. The team can also use this session to size the stories. Having done this work in advance also speeds up Sprint Planning.
Teams Cannot Combine Different Agile Elements
Once more, FALSE! There is no rule written that people cannot combine different aspects of various agile practices. Most Scrum Teams also use Kanban boards, and other concepts borrowed from lean, XP, or other agile frameworks.
Scrum alone isn’t always sufficient to create all products or solve all business problems. Support teams, for example, would be much better suited toward sticking with Kanban, but may also use Scrum activities such as periodic retrospectives to look for improvement opportunities.
Likewise, traditionally run projects (aka waterfall), can also benefit from inserting some agile ideas into their projects. They too may have more frequent retrospectives, rather than end-of-project Lessons Learned (when it’s too late to do anything about it).
For teams that want to avoid full-blown scaling, they might simply take from the Nexus scaling framework (or others) to achieve some parts of scaled agile, without adding too much additional overhead and cost.
The Project Management Institute also offers a certification in Disciplined Agile, which I would call a compilation of all kinds of agile ideas, that can be combined in whatever fashion makes sense and works for your team.
Wrapping it Up
Thank you for reading! This is just the beginning of many more great agile debates, so come back often! And, if you have an alternate opinion, I would love to hear it – please post in the comments below!