For the last two years I have been rolling out a standard Agile approach to a department of 350. One part of the roll out strategy was to have a published standard. This was to make the goal / end-game obvious even if we didn’t initially mandate everything.
The first version of the standard, published Oct 2006, was a 50 page document. Earlier drafts had been quite short but in reviewing the document people kept asking “What does that mean?” so we’d add another section explaining it. All rather worthy but, aside from the initial reviews before publication, nobody read it. And it diluted the document as a standard, defining what must be done, as opposed to a guideline about how to do it.
We published version 2 today. This version of the standard is one page. I want to give people a simple checklist so they know whether or not they are following the standard.
The new, one page, standard reads:
Agile Vision: “Empowered teams delivering high value software frequently”
The key practices are:
1. Co-Located cross-functional teams.
2. A clear product vision and roadmap.
3. Synchronised team activities with a regular heartbeat using:
- Daily Scrums
- Sprint Planning
- Sprint Reviews: Retrospectives, Product Demo
4. Release Tested Software every Sprint.
5. Empirical project management using release plans and velocity measurement.
6. Prove software quality through automated testing.
7. Just enough documentation to allow communication within teams and over time.
8. Teams are empowered to make decisions affecting their work.
You’ll notice bits of Scrum and XP in there which reflects the nature of the process we’re rolling out.
My Agile roll out team did have a wee internal debate about whether the standard as written actually listed “practices” or “principles“. I argued that as it was a standard, not a guideline, it had to list practices. And if you look at the items most are practices. The only exception being the one about empowerment.
We moved the material from the earlier 50 page standard, which was really “how to” rather than “what to”, to a wiki for those who wanted to find out what these practices meant.
This blog post was written nearly 6 years ago but seems extremely relevant to my team’s journey today. So, my question – how did it go? Did a one-page list of “practices” provide the inspiration and guidance you intended? What was the outcome?
Jeff, it went very well – as far as it could. Much better than the earlier attempt to explain everything. The more people you have to influence the less specific you have to be.
As it happens that department was chopped up in an organisational restructure a few months later and I moved on. But last year when I checked back the standard was still in use by some of the development teams involved despite several restructures and lack of management interest in Agile. I’m quite proud of that.
Having joined the Beeb in 2011 and working through to 2013 I can attest that all points 1-8 were being adhered to very well indeed. The big organisational split to Salford being the only one that messed point 1 as we often had POs in London, but they were regulars on the Virgin train service for most sprint planning sessions.
My only slight gripe after 18months of it was the ‘heartbeat’ was a bit metronomic (“scrum grind” I heard some say) and I’m pleased at my current gig that the project managers are choosing different sprint lengths, ending on Wednesdays, etc. etc. just to mix it up a little.