Wednesday, 27 May 2009
Monday, 4 May 2009
Throughout the years I have been in contact with several initiatives to introduce Scrum to either a single team or to an organisation as a whole, as well as myself playing the role as consultant/coach/mentor. Most of the coaches that have driven these initiatives have seemed to be thoroughly convinced of the advantages of iterative work, time-boxing, limited sprint-commitments, demonstrable business value etc. Also, several of them have spoken about how Scrum is not a methodology limited to software development, but that it is a general project framework. Yet, very few of these initiatives, which are projects of their own, have been planned or executed in any way that resembles Scrum, with backlog items, sprints, demos, definition of done etc. Rather, most of them have either been waterfall (“first interviews, then determining sprint length, then …”), or they have been the process equivalent of “happy hacking” (cruising around in the organisation, going to the meetings that seem interesting at the moment, coaching someone here, throwing a workshop there, improvising from day to day).
If they really believe in Scrum, why don’t they use it themselves?
A project “introducing Scrum” out to be run as a Scrum project. In this project the product owner (“Scrum-product-owner”) is the one “owning” the process problem, probably the CTO, CIO or Head of Development; they are the ones that want see visible improvements. The role of the scrum master (“Scrum-scrum-master”) of this project is most probably the coach/mentor. Finally, the team (“Scrum-team”) consists of key people that will do the work of transforming the work: apart from the coach, there will most probably be the scrum master to-be, perhaps someone responsible for processes, perhaps a CM.
The backlog items might be
“As Head of Development
I want an estimated and planned backlog
so that Business side develop trust in that IT work to generate business value”
DoD: Of six named stakeholders, at least four should grade the statement “IT delivers according to priorities and plan” with “agree” or better.
“As Team Member
I want peace-of-work for at least two weeks to finish what I have committed to
so that I will be able to finish stuff”
DoD: Team has performed one sprint where they delivered what they committed to at sprint planning
Each of these should give a concrete organisational impact with an obvious value, and that value should be possible to demonstrate.
The team (coach and staff) should estimate how hard it might be to make that organisational change, and for the next month (or whatever sprint-length they choose) focus on that change and commit to make it happen. E g creating peace-of-work might be a fulltime-job to shield the team from “executive requests”, and will then be estimated high. In that case the Scrum-team should perhaps just commit to that story. Or, it might be easy, in which case it will have a low estimate, and the Scrum-team could take on doing something more in parallel. Of course, the Scrum-product-owner (CTO/HoDev) will judge what will give the most benefit for the organisation given the cost (estimates) and select the story that give most bang-per-buck. During the sprint, they meet daily to synch their work, and the Scrum-scrum-master (i e the coach) facilitate that the Scrum-team works in an efficient fashion. After the Scrum-sprint is over, they all meet, demonstrate what has been achieved, have a retrospective to gather and share experiences; and off they go again.
So, why is not more “introducing/improving Scrum”-projects structured this way? From someone promoting Scrum, using it for his/her own work should be a no-brainer.
Or, do they not think Scrum is suitable?
Or, is it awkward to put on the self-discipline needed to actually follow a process?
Or, is it just too hard to come up with a backlog?
Or, don’t they want to give up control to the Scrum-product-owner/CTO?
Or, have they simply not thought about it?
I have no idea. At least, this is the way I prefer to run Scrum-improvement projects, and I am surprised it is not more common that what it is.
I think eating your own dog-food have some merits.
Others recently read
- Idea Mingle to Bootstrap Open Space
- Make Implicit Concepts Explicit in Code
- Coding Kids, it is about Democracy
- Four Characteristics of a Good Product Owner
- DRY and False Negatives
- What is Snow?
- Refactoring as Time Machine
- Good Product Owner Wrapup
- The Way Agile is Fast - Fast as in Orienteering
- In Agile, the Practitioners Own the Process