Many surveys have concluded that Scrum is the most widely used agile approach to software development. This makes sense because Scrum is easy to understand and simple to implement — or so it seems.
The basics of Scrum are simple enough. We have three important roles: Scrum Master, Product Owner and Software Team. We have three process artifacts: Product Backlog, Sprint Backlog and Burndown Chart. There are three planning events: Sprint Planning, Sprint Review and Retrospective. Finally, there’s the Daily Stand-up.
Simple, right? Why not start tomorrow?
But wait there’s more — a lot more! Achieving greatness with Scrum is hard. There’s a lot more to it. Here are 30 questions to ponder before adopting Scrum. Many of these apply to every software development project regardless of approach though they are worded using the Scrum vocabulary.
- How much analysis, if any, will you do before your first sprint?
- Will the team be sitting together?
- Will there be a dedicated team room?
- At what time will the daily stand-ups take place and where?
- How will action items from each stand-up be tracked?
- What is the process if the product owner can’t make all the stand-ups?
- How will the backlogs (product, release, sprint) be managed?
- How long will the sprints be?
- Will time be allocated for refactoring during each sprint?
- Will time be allocated for paying off technical debt?
- What’s the definition of done?
- Will design reviews be done and if so, how?
- Will code reviews be done and if so, how?
- Will there be sprint retrospectives?
- When will production releases occur? (End of sprints? End of release cycle? Continuously?)
- Will you do release planning in addition to sprint planning?
- Will there be a planning sprint at the project outset (sprint 0)?
- Will the team need a final integration sprint at the end (sprint n+1)?
- Will post-sprint reviews be held with the business stakeholders?
- Will there be post-sprint demonstrations for the stakeholders?
- Will the team use multiple sandboxes (e.g. Dev, Test, Staging)?
- Will the team use TDD, FDD or something else?
- How will user stories be captured?
- What tools will be used to monitor progress?
- What tool will be used for configuration management?
- How will the code be tested and by whom?
- Will new code be integrated and tested late in each sprint or continuously?
- How automated will the testing process be?
- What metrics will be tracked and how?
- How will customer satisfaction be measured?
Still think Scrum is easy? Let me know.
Great challenge of the Scrum framework!
No improvement/change come easy, ever! Scrum provides a framework for actually achieving improvements. However my opinion is that it will only do so if the questions above have an answer. It’s a change of perception and attitude much more than a process change.
Doing only pieces of this, regarding some as impossible in your change process, will end up in what I call “Half Pregnant” which is not a desirable state of being and also quite impossible.
Change in small steps so that you can embrace all the important items above! Bit by bit, never ending the strive for getting better at delivering results.