In the ninth episode of my blog series on More Agile Great Debates, I wrangle with five more topics about agile that are argued about often. They are:
- It’s Better to be a Generalist than a Specialist
- Everyone on the Team is Responsible for Quality
- The Scrum Master can Cancel a Sprint
- Scrum Teams should Support the Products they Build
- While you have a Product, you should always have a Backlog
It’s Better to be a Generalist than a Specialist
I saw a presentation at the Building Business Capability (BBC) Conference a few years back, and the topic was whether the profession of Business Analysis was doomed. The main point the speaker was getting at is that we should not be specialists, and that to continue being relevant, we need to become generalists.
On an individual basis, I think choosing to become a specialist is okay, but when you’re part of an agile team, it must contain all the necessary cross-functional skills to create a “done” increment each Sprint. If everyone is a specialist, it means the team is single-threaded; unique skills quickly become a bottleneck.
Ideally, each team member is a T-shaped learner, with a top skill, but many other secondary ones. By becoming more generalist in this way, your value as a team member increases, and the overall success of the team will increase. Not only that but with how rapidly technology changes and how hard it is to keep up, you should never put “all your eggs in one basket.”
Everyone on the team is responsible for Quality
Whenever I’m helping a new Scrum Team craft their Team Working Agreement, I usually try to insert one important point, which is that everyone on the team is indeed responsible for turning out a quality increment.
As we all know, quality is usually the first thing to get cut or suffer when the pressure is on to get something done. By cutting corners, you’re stabbing yourself in the back, though, because the cost of poor quality far exceeds developing good quality in the first place.
Every person on the team can contribute to ensuring a high-quality product. It doesn’t matter if you have a person on the team whose specialty is quality assurance – each person who touches a piece of the product increment has an opportunity to inspect and adapt it and catch problems (and fix them) before they ever escape to production.
The Scrum Master can cancel a Sprint
So many people still equate a Scrum Master to a traditional Project Manager, but that couldn’t be further from the truth. The Scrum Master is there to serve the team, guide them in solving their own problems, ensure the Scrum values are being upheld, and create a positive environment in which the team can grow and thrive. They are not “in charge” of anything.
That said, there is one person on a Scrum Team who does have the power to cancel a Sprint, and that is the Product Owner. Only this person can determine when a Sprint is no longer valuable, and while it’s very rare, a Sprint can be stopped dead in its tracks.
The reasons for canceling a Sprint usually involve things like mergers and acquisitions, new executive leadership, new and unexpected competition, government regulations, drastic swings in customer demand, etc. And though the Product Owner can cancel a Sprint, it’s no small matter, and she should weigh very carefully the cost and consequences of doing so.
Scrum Teams should Support the Products they build
Whether or not the team that built a product should support it is another hotly debated topic in agile circles. Some argue that “of course!” the team responsible for building something should also make sure the product continues to work well.
However, Scrum Teams continue to evolve their existing product or may shift to building a new one. Product-type support issues can seriously derail a team if they are interrupted by mission-critical defects that must be fixed immediately (mid-Sprint).
I could go either way on this one. In my ideal world, once a major phase or feature is released to the public, I would prefer to hand off future support to a dedicated support team that services all customers. Then the Scrum Team can keep innovating and building new stuff. However, I can also see how this could lead the developers to cut quality corners to get things done faster since they know they won’t have to deal with the repercussions. What would you chose?
While you have a Product, you should always have a Backlog
I don’t remember where I heard this statement, exactly, but I believe it’s true. If your product is a vital, living, growing entity, then it needs to be fed and cared for to remain strong and relevant. And that means having a robust Product Backlog that is actively managed by the Product Owner.
If you start running out of new ideas, improvements, or enhancements to your product, then you might want to evaluate if you need the same-sized team supporting it. As products mature, they naturally reach a point where all the major features are stable and there are plenty of “delighters” to keep customers happy. At this point, the team could become smaller and function more in a maintenance mode.
On the other hand, if you want to keep your product going as a profitable endeavor, you should continue to invest in it – and that involves doing market research, talking to customers, checking out the competition, and creative, innovative thinking. When you’re doing these activities, it will be hard not to have a healthy Product Backlog.
That’s a Wrap
Well, five more tricky agile topics have been tackled. What do you think? I’d love to hear your opinion, so please share in the comments section below!
If you missed any of the previous blogs in this series, here they are:
- 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
- Part 5 – Conflict, leadership, technical POs, who should write User Stories?, extending Sprints
- Part 6 – Timeboxes, SM on 2+ teams, Managers at Retros, staying together, uses for Scrum
- Part 7 – Story Points, Job Titles, comparing Velocities, PM on a Scrum Team?, Business Analysts?
- Part 8 – Starting backlogs, improvements, “special” Sprints, people swapping, cross-functionality.
And, don’t forget to read the one that started it all: 20 Great Agile Debates.