[Photo credit: darkmatter]
I’d never really read much into Scrum beyond that it was split into sprints. But reading it closer recently it just seems like a horrible corruption of an inspirational idea, that could much more easily be integrated into normal project practices.
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.
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 whole team|
|The Product Owner||The business / customer|
|The Development Team||The developers|
|The Scrum Master||The Project Manager|
|The Sprint||Month / Increment / Project – Sprint isn’t actually that bad a word|
|Daily Scrum||Talk / meeting|
|Sprint Review||Month / Increment end / Project update|
|Sprint Retrospective||Month / Increment end / Project review|
|Sprint Backlog||Month / Increment / Project issues|
|Artifact Transparency||Bullshit elimination|
|Definition of “Done”||Happy Business / Customer|
Can I have a word…
“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.”
“Shall we go over the month end update later? I’m not convinced that the issues contain all that we require for the customer 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 eliminate the bullshit from this month’s issues document as the business feels we haven’t followed what we agreed at the last month end review.”
Please let the first type of conversation cease.