[Photo credit: darkmatter]
I’ve been reading into Scrum closer recently and it just seems like a horrible corruption of an inspirational idea, that could much more easily be integrated into normal project practices.
Agile
I love the agile principles. I’m repeating them here for my own benefit, I like a good list as much as the next.
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work not done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstances
Each principle makes sense, even if, perhaps, it isn’t attainable.
Their manifesto is harder to figure out, but still has a great aspirational feel to it.
| We value this | Over this |
|---|---|
| Individuals and interactions | Processes and tools |
| Working software | Comprehensive documentation |
| Customer collaboration | Contract negotiation |
| Responding to change | Following a plan |
However importantly note that the second column is still valued, but just not as much as the first.
Scrum
Now read the Scrum Guide™ (TM!). Scrum just seems like a conversion of agile concepts into sucky word project management.
I realised I’d already got it wrong with what a sprint was – I thought it was two weeks work. They suggest that it should be a month’s worth of work – which makes sense, but why not just call it a month’s worth of work – or if it’s going to be less just call it an increment.
Anyway I read through the Scrum Guide and here’s my unsucked version of their main concepts.
| Scrum Guide™ | Unsucked agile guidelines™ |
|---|---|
| The Scrum Team | The Team |
| The Product Owner | The Client |
| The Development Team | The Developers |
| The Scrum Master | The Project Manager |
| The Sprint | The Sprint (it isn’t actually that bad a word) / Increment |
| Sprint Planning | Planning |
| Daily Scrum | Talk |
| Sprint Review | Sprint Update |
| Sprint Retrospective | Sprint Review |
| Scrum Artifacts | Documents |
| Product Backlog | Issues |
| Sprint Backlog | Sprint Issues |
| Increment | Completed Issues |
| Artifact Transparency | Simplification |
| Definition of “Done” | Happy Client |
Can I have a word…
Scrum style
“Shall we go over the Sprint Review later? I’m not convinced that the Product Backlog contains all that we require for the definition of done. The Daily Scrum this morning wasn’t great as the Scrum Master had to get the Development Team to better explain their progress to The Product Owner. We need to make the Sprint Backlog artifact more transparent as The Product Owner feels we haven’t followed what we agreed at the last Sprint Retrospective.”
vs sane
“Shall we go over the Sprint update later? I’m not convinced that the issues contain all that we require for the client to be happy. The talk this morning wasn’t great as the Project Manager had to get the developers to better explain their progress to the business. We need to simplify the Sprint’s issues as the client feels we haven’t followed what we agreed at the last Sprint review.”
Please let the first type of conversation cease.
Ian Channing 
Leave a comment