Problems I see fairly regularly are tied to the code base and development team practices.
- Scrum calls for potentially shippable every sprint, but if team members (and worse, teams) integrate late in the sprint, it’s going to be problematic.
- “What’s QA doing the first eight or nine days of the sprint?” They should be writing tests against against the interface that the tester and dev discussed and agreed upon before coding started. “But that means additional builds and that’s hard for us and there’s surprises sometimes and so we don’t do it.”
- “We’re not getting our stories accepted by the Product Owner at the Sprint Review!” You should be building smaller increments and getting PO acceptance earlier instead of being surprised at the Sprint Review (I’ve heard the meeting called a “surprise party” – not good), but….(see item #2 above).
- “We can’t work the priority items the PO asks for because not everyone can work those items because they don’t know it.” Pairing would help solve that problem, and lot’s of unit tests would be the safety net for the novice to at least try and help make changes to existing code or build new functionality.
I could go on. My question is, “What are you doing about these constraints and impediments?”
One option is to train your development team to give them the information and hands-on experience so that they can start.
Consider the rare opportunity to attend our Certified Scrum Developer workshop in December. These practices are the building blocks for agility and DevOps.