In the second part of my new blog series on “Agile’s Great Debates,” I cover another set of five topics that people tend to argue about when it comes to agile ways of working.
Here they are:
- SAFe is an Agile Framework
- You Should Show “Not Done” Work at the Sprint Review
- The Sprint Review is a Status Update
- Agile is the same thing as Scrum
- The Sprint Review and Retrospective are the Same
SAFe is an Agile Framework
I know I’ll probably get a few haters when I say this, but NO!, I don’t view SAFe as an agile framework. It’s a bloated, complicated (and bastardized) way of trying to accomplish large and overly complex, integrated work. (Seriously, visit their site and you will instantly see what a mess it is.)
As an agile consultant, my recommendation is usually to avoid scaling if at all possible. By attempting to scale, you increase cost and complexity, and the risk of failure is much higher. It’s highly preferable to keep atomic and autonomous agile teams that are small and focused.
However, if you feel you must scale, there are (in my humble opinion), far better options than SAFe. These include Less and my scaled agile framework of choice: Nexus (which was created by the same people who wrote The Scrum Guide).
You Should Show “Not Done” Work at the Sprint Review
Uh, duh – NO! This is a cardinal rule of Scrum. Every team must have an agreed-upon Definition of Done, which is an official artifact in Scrum. And if an item does not meet this definition, it is not “Done,” and therefore should not be shared in a Sprint Review.
Unfortunately, there are many Scrum Teams that struggle with this. First off, many lack a Definition of Done, and without one, how does anyone know what “done” looks like? Short answer: they don’t! This means that stories can linger and change, because nobody knows where the boundaries are.
Teams may also be tempted to show things that are “mostly” baked. This usually means that the coding has been done and it’s been passed off to QA for testing, but testing is in progress and hasn’t been completed. Some Scrum Teams cheat to get around this irritating problem by adjusting their Definition of Done so it doesn’t include “QA tests passed without any critical- or high-severity defects.” Try not to be this team. Having a tested, working, useable, demonstratable, and potentially-releasable working increment is the whole point of each Sprint!
The Sprint Review is a Status Update
Honestly, this is one of my biggest pet peeves when it comes to agile and Scrum! NO! The Sprint Review is not merely a status update or a demo; this event should be much more than that (and it should replace the dreaded “Status Review Meeting”).
The point of the Sprint Review, according to The Scrum Guide is to:
“Inspect the outcome of the Sprint and determine future iterations.”
Yes, you should show your actual, working increment(s). This should not be a facsimile or a PowerPoint. Not only that, but the Developers should lead this event. They did the hard work of building the backlog items, and they deserve to get the recognition and credit that comes along with delivering.
The second, and very important part, of the Sprint Review is to come up with a plan for future iterations. In my experience, the Product Owner has a general idea of what is wanted in the next Sprint or two, and shares this plan with the audience. However, based on stakeholder feedback, that tentative plan may change to accommodate new user requests.
At the end of the Sprint Review, the expected outcome is an updated Product Backlog that serves as the input to the next Spring Planning event.
Agile is the same thing as Scrum
There is a widespread and common misunderstanding between agile and Scrum. This occurs because the Scrum Framework is far and away the most popular of agile approaches, but it’s definitely not the only one. Nor is agile synonymous with Scrum.
The way I describe this concept when training new Scrum Teams is that agile is a mindset, an umbrella that covers all the various aspects of different agile approaches. All the different “flavors” of agile, therefore, are agile, but they are not agile itself.
To better understand what agile is, the best resource (in my humble opinion) is the original Agile Manifesto, which was famously penned by a group of frustrated software developers who met in Park City, Utah, at a ski resort in my wonderful home state of Utah in 2001. My first child was born the same year, making the document 22 years old, which is relatively new in the grand scheme of technology.
In the Agile Manifesto, there are things that are valued more than others (which is not to say the other things don’t have any value). It also includes 12 core principles. Although agile has evolved past software development, the same ideas still apply to other contexts.
The Sprint Review and Retro are the Same
As an agile trainer and coach (Scrum specifically), I have seen that the two Scrum events that are most often confused, are the Sprint Review and Sprint Retrospective. I don’t quite understand why there is so much confusion, but my experience has proved it time and time again.
To clarify, NO, these two events are not the same thing. Each has its own purpose and audience, along with expected outcomes. The goal of the Sprint Review is to:
“Inspect the outcome of the Sprint and determine future iterations.”
In contrast with the Sprint Review, the Sprint Retrospective is only for the Scrum Team, without any outside or extra participants (including managers). The point of this event is to embrace the empirical process of inspecting and adapting. It allows the team to honestly look back at the Sprint and identify opportunities for improvement.
So, as you can see – the Sprint Review and Retrospective are two totally separate events, with totally different purposes. I hope this clears up any confusion!
Final Thoughts
This blog covered five more ways agile concepts and practices are misunderstood. To recap: try not to scale if you can avoid it, make sure your team has a Definition of Done, and only show “done” work at the Sprint Review, which is a separate event with a different purpose than the Retrospective. Finally, agile is a mindset – Scrum is an agile framework.
Now, as always – it’s your turn! What do you think about these debate topics? Do you have any differing opinions or experiences? If so, I would love to hear about them in the comments below!
Oh, and P.S. – if you missed the first blog in this series, you can find it here:
- Part 1 – Devs as Sub-team, the 3 questions, product goal, refinement, hybrids
Check back for more great debates soon!