Scrum Isn’t Always Perfect (and that’s okay)
App Dev Manager AJ Weaver reflects on techniques to overcome challenges when implementing scrum in less than ideal circumstances.
Over the years, I have coached and researched dozens of scrum teams to adapt to “real world” scenarios. Some may call them anti-patterns or some may call them “not scrum”– but that is okay too because sometimes we have to work with what we have and still find ways to be successful. What I want to cover today are the 4 top scenarios/anti-patterns I have seen and how, in-spite of these scenarios, scrum was successfully adopted. I have realized that that scrum isn’t perfect for dealing with these things when you look at the Scrum Guide, but teams can be successful by not ignoring them and finding a way to incorporate them instead. Please note, I am not saying these are the only answers to your specific challenges, nor am I implying these are only scrum recommendations that you should follow. What I am stating is that these are my observations of working teams that may help you. I do want to mention that a solid foundation of knowing the scrum guide very well should precede trying to implement any variations of scrum.
1. Scenario: Scrum Team is dealing with a separate QA Team
I know this will cause some headaches for traditional scrum folks as QA teams are supposed to be integrated with the scrum team and be cross-functional. Yes, this is the ideal scenario. No, it doesn’t always happen this way or happen overnight. What happens is the following:
- Scrum team finishes the sprint (sprint 1), deploys code to be tested to QA
- Next, sprint QA team tests sprint 1 (and finds bugs) while scrum team is on sprint 2
How this has co-existed: By tracking how much time is spent on bug/issues found by QA, this can be addressed in capacity planning. For example, for three sprints the scrum team creates new issues in their tooling and tracks exactly how long it took to fix QAs bugs during that sprint. This time is then averaged much like a “bug fix velocity” and is incorporated into sprint/capacity planning. This is not a perfect scenario as there will be bugs/issues that aren’t addressed in the following sprint, but they can be put on the backlog for the next sprint as well – which is indeed the best practice.
2. Scenario: Scrum Team is dealing with support/fixes during their current sprint
This is very much like the above scenario; however this could represent bugs/issues from many sprints ago (weeks or months) depending on the triage process. I have seen teams take the estimated amount of time being spent on fixes and issues and reserve time like in the above scenario. I have also seen teams that take, say 20% of their team and put them on a support role for the sprint doing only support/triage/bug fixes. For example, a team of ten will have a rotating team of two that is always on support for that sprint. These two people would rotate over time sharing the responsibility to stick to the principle of cross-functional teams who can work across the product.
3. Scenario: Scrum Teams are dealing with dependencies on other deliverables
I have seen this manifest itself when there are contracts that have to be changed across service boundaries. This can be less of an issue with loosely coupled services and proper version management, so I am not saying this is something that is definitely needed, but what if your scrum team is dealing with a legacy service that needs to be changed? What if another scrum team that is designing services that do not meet your needs? The way I have seen this work (without the aforementioned design considerations) is by having an integration sprint in between X amount of sprints. This takes coordination across teams as teams will need to make sure they all work together for that particular sprint. For example, scrum team A may want to have a 1-week integration sprint with another scrum team and support team of a legacy system. Scrum team A needs to keep their dependency counterparts aware of the new needs of their services and plan accordingly to have a touch point where they work on integration.
4. Scenario: “Unmanageable” backlog
I have worked with teams that have Product Owners (PO) that are not very technical or just have way too many product backlog items (PBIs) and are not able to really groom the product backlog effectively for sprint planning. What I have seen teams do, is implement Product Backlog Grooming Sessions (PG Grooming) into their sprints. So for example, during a two week sprint, a lead developer and the PO may have an hour meeting every Thursday at 1:00PM. This may include other stakeholders to give more details and for the two of them (the lead and the PO) to come up with a swag at a story point and priority based on this swag. There would be two of these– so that way, the lead and PO have time to think and discuss complexity and priority so that walking into sprint planning, there is an idea of what type of effort might be included for the top ten stories even if only seven are supposed to make it. This can lead to more flexibility to bring stories in/or move them out since there will have been dialog before sprint planning. This also makes your sprint planning sessions go by more efficiently which I believe everyone will be happy about.