In the eighth installment of my series on Agile’s Great Debates, I tackle five more topics that my fellow agilists like to argue about:
- Product Backlog must be complete to start Sprinting
- Scrum Teams must choose one improvement each Sprint
- Certain Sprints are “Special”
- People can easily swap in and out of Scrum Teams
- You don’t need to have a fully Cross-functional team
Product Backlog must be complete to start Sprinting
Do you need to have a fully refined and ready Product Backlog before you can start Sprinting? Those perfectionists among us might not feel comfortable with having a less than fully fleshed-out backlog, but I think that is essentially anti-agile.
You can begin Sprinting without having a complete Product Backlog. Keep in mind that the backlog is a dynamic and ever-changing artifact that will never be complete. What’s important today may not be as relevant in a day, week, or month from now, so you’re better off with a lighter-weight backlog.
Not only is it better to have a small backlog, but it also makes managing it that much easier. I’ve had backlogs that numbered in the thousands of items – there’s no way a human being would have the time or patience to spend stack-ranking a list of that size. Smaller is better, and all you need is enough to start.
Scrum Teams must choose one improvement each Sprint
It’s true that in older versions of The Scrum Guide, it was recommended that Scrum Teams choose improvement items each Sprint to add to their next iteration’s backlog. Feeling that this was too prescriptive, this element was removed as a requirement (but it’s still suggested that it’s a good practice).
If your Scrum Team is not choosing items to improve upon, they’re missing the point of the empirical process – the idea is to continuously improve. If you don’t actively identify areas of opportunity to work on, how can you ever get better? I don’t think you can – it takes conscious effort.
So, technically, you don’t have to pick something to change, but it would be in your team’s best interest, and a best practice, to do it anyway. Even if you feel like your team is perfect and you don’t need to adjust anything, you’re probably wrong – there’s always room for improvement.
Certain Sprints are “Special”
I just checked a book out of my library because it was recommended on someone’s Agile website. It’s called “Sprint: how to solve big problems and test new ideas in just five days.” The title caught me by surprise – well, kind of annoyed me, actually – because it goes against the idea that each iteration is the same length, that it should be the heartbeat of Scrum, and allow a team to maintain a sustainable pace.
But, not wanting to be close-minded, I’m going to give this book a chance. In my experience, once a Scrum Team starts to treat Sprints like special phases (aka waterfall phases like design, development, testing, etc.), the whole idea behind agility gets lost.
So, while I’m not generally a fan of having specialty-purpose Sprints, sometimes I recognize that they might be necessary. I still don’t think it’s a good idea or a good practice, but reality has taught me that sometimes you can’t escape the bureaucracy of an organization, and you must jump through their hoops (think Sprint Zero, Integration Testing Sprint, Hardening Sprint, etc.).
People can easily swap in and out of Scrum Teams
As I’ve mentioned before, no two Scrum Teams are the same, and everyone’s experience will be different. Does this mean they can easily swap in and out of other Scrum Teams? I think the answer to this is the most common consultant answer: it depends.
If a person has had formal Scrum training at some point, and they have been on one or more Scrum Teams, they at least have the basic understanding and vocabulary to be able to slide into a new team. However, they should still expect some differences, and adjust accordingly.
On the other hand, if the person has never used any agile practices, been on a Scrum Team, or has no familiarity with the work, domain, market, or industry, they’re going to have a rough time trying to fit into a new team. At a bare minimum, they need basic Scrum training, and it would also help to have a period of observation before joining as a contributing team member.
You don’t need to have a fully Cross-functional team
All I can say to this assertion is “Doh!” (Homer Simpson’s typical response). One of the core ideas of Scrum is that each team should have all the necessary cross-functional skills on the team to be able to deliver a done increment at the end of each Sprint.
What happens if you don’t have all the skills needed? I’ve seen it too many times to count, but here are a few issues that result: 1) inability to get Sprint Backlog items to “done,” 2) waiting in line to access a special skill set not possessed by your team, 3) impatient and angry stakeholders, 4) working on lower-value items while you wait… and on and on it goes.
If you find yourself in this situation – lobby long and hard to get the skills you need on your team. Whether it’s through cross-training, taking classes, job shadowing, hiring for the skill, borrowing a person from another team, or any other creative solution you can come up with – don’t let yourself be dependent on people outside your team – you’ll have a very difficult time succeeding.
That’s a Wrap
And, like that, five more Great Agile Debates have been addressed. I’m always curious to know what you think, though – so please share with me in the comments below!
If you missed any of the previous blogs in this series, check them out now:
- 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?
And, bonus, the one that started it all: 20 Great Agile Debates.