In the fifth installment of More Agile Great Debates, here are five more areas where people have differences of opinion:
- 1. There should be no Conflict on Scrum Teams
- 2. Anyone on a Scrum Team can Lead
- 3. Product Owners Should Have Technical Knowledge
- 4. The Product Owner Must Write all the User Stories
- 5. It’s okay to extend Sprints
There should be no Conflict on Scrum Teams
I’ll be honest – I’m not a fan of conflict, in general. If I see it coming my way, anxiety kicks in and my “fight or flight” reaction gets triggered – and I usually run the other way. However, in healthy Scrum Teams, conflict is a source of many great new ideas, and if handled respectfully, it’s not a bad thing.
That said, it is bad when conflict is not healthy. If the team resorts to playing games, yelling, screaming, and dominating until one person gets their way, or personalities are under attack rather than ideas or issues – things will devolve quickly. This is an unhealthy type of conflict that should be avoided at all costs.
When teams have mutual respect and have developed trusting relationships, all ideas should be welcome. When conflict does arise, these teams address the topic at hand – not the feelings or perceptions people have of each other. By staying focused on the issue, and debating it safely, the results tend to be good.
Anyone on a Scrum Team can Lead
One aspect of being on a Scrum Team is that leaders can emerge. So, although the Scrum Master and Product Owner are leaders (by definition), that doesn’t mean someone else can’t stand up and take the reigns from time to time.
An excellent opportunity for this is the various Scrum events. While a Scrum Master is responsible to make sure they happen and that they are positive, upholding the Scrum values, it doesn’t mean they’re required to be the facilitator of all these activities. Anyone on the team may volunteer to “drive” any event.
Another place where leaders may emerge is in the technical realm. Perhaps someone is an expert in a new technology that no one else is familiar with. In a case like this, the person could teach the other Developers about the technology so everyone can know something about it – raising the skill level and knowledge of the whole team.
Product Owners Should Have Technical Knowledge
I wrote a previous blog on this topic because I have found it troublesome to have a technical Product Owner. Usually, this results in backlog items being solutioned; rather than simply stating the “who, what, and why,” the technical P.O. will include solution-specific details, which the team then implements without question.
Why isn’t this a good idea? Well, it’s because the Developers are supposed to figure out the “how” of a User Story. If they’re given too much technical instruction, they don’t have the opportunity to be creative and come up with the best way to meet the business need. I don’t think most people like to be told what to do or how to do it (micro-management, anyone), and this comes too close to that.
Another problem with having technical Product Owners is that they are focused too much on the details and aren’t seeing the big picture (can’t see the forest for the trees). The person in this role must have their eye on the market, the competition, and the vision, rather than being concerned with the minutia of how things are getting done.
The Product Owner Must Write all the User Stories
Yes, the Product Owner is responsible for the Product Backlog, but no rule says this person must write all the backlog items herself. Most Product Owners have too much work to do and simply don’t have the time to do the level of management required to keep a Product Backlog healthy and full of “ready” items to feed the team.
Anyone on the team is allowed to contribute ideas to the Product Backlog. But while new ideas might be added, it doesn’t necessarily mean they’ll be prioritized for development. This decision is still the responsibility of the Product Owner, and if there’s value in an idea, it may rise to the top, otherwise, it will remain lower on the list.
Another way team members can contribute is by assisting the Product Owner in eliciting the details needed for each User Story, to ensure they are sufficiently written that they are suitable for development. A Business Analyst is often a Product Owner’s best friend and sidekick in this regard, who takes this burden off the Product Owner so she can focus on the big picture.
It’s okay to extend Sprints
Uh… NO. When the timebox for a Sprint expires – that Sprint is over. End of story. If you need “just a few more days” to finish something, well, that’s just too bad. At the of a Sprint, whatever work has not been completed (according to the Scrum Team’s Definition of Done), may be put back into the Product Backlog or selected to be included in the new Sprint.
As an agile coach, I have been asked this question before, and I’m usually surprised when I hear it because The Scrum Guide couldn’t be clearer on this point. As a Scrum Master myself, I would never even consider extending a Sprint, simply because of the cascading nightmare that would result in the re-scheduling of all the Sprint events and activities.
Now if the cadence of your Sprints isn’t working (either too short or too long), this is a topic that can be discussed in a Sprint Retrospective. If the team agrees that the length isn’t working, they can experiment to test different Sprint lengths to see what works best for the team. If a permanent adjustment is needed, it can be done. But there’s no extending a Sprint for no good reason.
That’s a Wrap
Five more agile great debates have been tackled. I’m curious to get your take on these topics – so if you have any experiences you would like to share, please do so in the comments below.
Oh, and in case you want to read up on the previous blogs in this series, check them out:
- Part 1 – Devs as Sub-team, the 3 questions, product goal, refinement, hybrids
- Part 2 – SAFe, showing undone work, Status Updates, Agile = Scrum?, Review vs. Retro
- Part 3 – Product Development, Backlogs, Scrum: Methodology?, PO owns budget
- Part 4 – Scrum Master needed?, Silver Bullet, adoption is easy, PO at Scrum, 10+ teams size
And, bonus, the one that started it all: 20 Great Agile Debates.