As the closing date for proposals approaches I’d be delighted to receive any comments on my submission.
Real agile adoption – lessons learnt
Comments should be posted on the Agile 2009 conference site.
Agile approaches to software development can be seen as quite hostile to project management. I have been told in the past that “we no longer need PMs because we have a SCRUM Master”. This is not a line I agree with. Furthermore, I can see this type of attitude causing unnecessary hostility. In fact I see agile as offering tools to project managers that can make them more effective and better able to deliver to demanding customers.
So what does a project manager do?
For me, while a SCRUM Master is responsible for supporting the team and the Product Owner can be seen as a domain expert able to make calls on prioritisation the Project Manager should be focused on the project context. This is likely to involve commercial considerations, stake-holder management and external risk management as well as possibly choreographing deliverables from different suppliers e.g. software delivery and data centre space.
It is of little surprise that many in the development community feel the need to push back on PMs. As an industry there are many of us who have experienced over bearing, micro-managing PMs who seem to live to interrupt us mid flow and demand estimates as well as challenge actual time taken on a task. It seems that many PMs cannot appreciate the difference between an estimate and a quote as well as a seeming inability to acknowledge unachievable deadlines based on everything going right.
In fact, should we be so harsh? A PM is tasked with ensuring the success of a project. Many retain a list of risks with no opportunity to mitigate, hold a plan with no possible intervention point if things seem to be slipping and furthermore it is often almost impossible to measure our current project state against the plan.
It is my view that agile methods offer a set of levers to enable effective project management. Examples of these include:
So, in conclusion, while SCRUM was defined without a PM I see this as a crucial role in a commercial environment. While the PM will collaborate with the SCRUM Master and Product Owner (or equivalent in a none SCRUM team) this is a distinct role with distinct commercial and stake-holder management responsibilities.
Recently there has been something of a backlash against SCRUM. There are two obvious camps (maybe you can think of others) of people who have knocked SCRUM recently.
The ‘agile is pants’ camp who see it as a fad and the lean camp who see SCRUM as a special case that is easily superseded by lean practices.
By contrast I find SCRUM useful in my day job of coaching teams to assist them in delivering code more effectively. In my opinion SCRUM has three benefits; it places quality at the core through doneness and ensures two way communication between organisation and team through demo and retrospective, it compels the team to take responsibility for process improvement.
If you have these elements in place then maybe you won’t benefit so much from SCRUM. However, if you don’t then adopting SCRUM can be like turning on a light. The team is given respect and space to make it’s own delivery commitments, in return the business can expect a degree of professionalism and should have this demonstrated to them in terms of what constitutes doneness for this iteration. The team are invited to reflect on both progress and impediments at the end of a short iteration, likely outputs are the identification of organisational or team factors that are constraining the team. As such the team should, if supported, speed up over time.
So for the mature effective development team in a supportive organisation maybe it’s not necessary. I also firmly believe that Lean principles have something to offer to software development. However, when presented with an under-performing team or organisational issues I would recommend SCRUM as a framework that will make space to improve.
This is a question I have been presented with often. If I suggest two weeks there is usually someone around who can make reference to a SCRUM text book that states 4 weeks. I’ve heard good arguments for three week iterations, often along the lines of a compromise and that you are left with a clear week in the middle to be ‘in the zone’ from a development perspective.
Recently I’ve had a team I was coaching ask to be allowed to make iterations longer. On occasion I’ve challenged teams to consider shortening iterations.
But what iteration length is correct? A short iteration serves to expose the inefficiencies that can be hidden otherwise.
For example; a team cannot work on a two week iteration because of the time taken to prep for the demo. What do we do? We can extend the iteration to 3 or 4 weeks at which point we can stomach the inefficiency or we tackle it head on identifying where the pain is emanating from.
On the other hand if a team running a three or four week iteration is comfortable do we have the courage to challenge that. By reducing the length of the iteration we increase our feedback rate and also give ourselves the opportunity to identifying the next hidden constraint that is limiting our throughput.
In short there is no right answer. I tend to lean towards two weeks, four weeks feels too long to me for most teams particularly where we need to learn and want that rapid feedback.
What are your experiences?
In his excellent presentation on Heartbeat retrospectives Boris Gloger makes a passing reference to a team backlog. This chimed with me since I’ve had teams ask recently “where do we put tasks we know we have to do but are not on the product backlog?”.
This is an interesting questions (IMHO). Should tasks exist if they are not on the PB? Who gets to prioritise? Is this a good way to handle technical debt?
I have used such a backlog but with certain rules. A team keen to keep track of previously accrued debt did maintain their own backlog. This could have items added to it by a team member at any time. The team would take items from the team backlog into the sprint often as an output from the retrospective. This worked because the product owner understood the importance of clearing away technical debt.
I do still have reservations. Who owns the technical debt on a project? The team are best placed to identify such debt but is important that a team backlog is not hidden from the product owner. We cannot absorb velocity with no regard for the product owners needs.
The team that I used this technique with had the team backlog large and visible next to the task board. Items were proposed to the product owner during the planning meeting. Acceptance of tasks from the team backlog into an iteration formed a part of the commitment for that iteration.
The product owner needs to care about technical debt. Making debt visible is a teams responsibility. Providing capacity to pay back accrued debt is the responsibility of the product owner.
SCRUM is a framework for product development. In my world this is software product development.
I coach teams with varying knowledge and experience of SCRUM and other agile approaches. I tend towards using SCRUM as a starting point when asked to introduce a team to an agile way of working; it provides a basic contract between team and business, expresses the individuals responsibilities and leaves plenty of room for engineering practices to develop.
There is one artefact that I find gets lost. Often when returning to teams after a period away I will observe that while there is a product backlog, burn-down charts and a task board describing the current team state one artefact has been quietly dropped.
The impediment backlog or blockers list is a crucial artefact for most teams to deliver to their commitments and continually improve. This list of issues currently impeding progress is added to by the team as issues arise (or risks are identified). The SCRUM master / project manager needs to be reacting to these issues and eliminating blockers or escalating impacts through organisational channels.
Where team members have raised issues it is crucial that these are addressed. An absence of action from management in the presence of blocking issues shows a lack of interest in the project and can demoralise the team. Issues should be further addressed in iteration retrospectives, recurring issues can be a major drain on development efficiency. A recurring blocker could be down to tight coupling between development teams or a stove piped approach to discipline (i.e. none cross functional team).
So, if you are in a SCRUM team take a look around. Where is your impediment backlog? What actions are being taken in response to blocking issues? How visible is your impediment backlog? A visible backlog can serve a team as it constantly reminds managers and stake-holders of their obligations in support of the team.
I have been working with large finance clients recently in London and will be using this site to attempt to capture some of the experiences and lessons learnt during this period.
In particular I will be highlighting the barriers to effective agile adoption and showing how we could effectively recover from arising issues.
I trust that this will serve as a resource for those looking to adopt agile and working to resolve items on there own impediment backlog. Which leads me on to the most common of omissions by teams adopting SCRUM and I’ll get on to that very soon.
This is a fantastic little book for anyone facing organisational change.
See my review here
A useful resource for those interested in agile retrospectives is the google hosted recording of a presentation by Esther Derby and Diana Larsen.
None
Managing the design factory – A product developers toolkit by Donald G Reinertsen
