In a recent post Karl Scotland drew my attention to this post by Craig Dickson on Agile DZone. Karl and Craig differ on their approach (when working with Scrum) to prioritisation of stories by the product owner within a sprint.
Craig has a valid concern that we might loose sight of our Sprint commitment if we have high and low priorities within the sprint, what if we don’t get to low priority stuff, well it was only low priority! He also raises concern over the degree to which the team is empowered if the Product Owner specifies a priority order for within the sprint.
By contrast Karl has his focus firmly on WiP (work in process), and through that lens the sprint is secondary to a focus on flow, prioritisation will encourage the team to focus on flow. I have some sympathy with this point of view.
As is so often the case I feel that I fall between these two camps.
- I believe in an empowered team who pull from the backlog
- I believe in the team making a commitment to a sprint scope
- I believe in the team self-organising around moving that scope through to releasable product
But, there is always a but, these things don’t preclude prioritisation.
We pull from the backlog in order to take into account team capacity / capability. We pull in the correct amount of work with an appropriate profile e.g. not all database heavy wok if we have limited DBA capability. This means that the team may not always pull items from the very top of the backlog. The team commitment is an open honest expectation that this work can and will be achieved by the end of the sprint. We don’t sack or punish the team if a commitment is missed, in fact it could be argued that the commitment should be missed from time to time due to special causes. We don’t want to pad sprint plans with high amounts of contingency. Finally the team self-organise around achieving the goal.
When I introduce teams to Scrum I recommend working against a prioritised sprint backlog. Why? The prioritisation helps in a number of ways:
- The team is challenged to find ways to move stories to Done faster
- The team is encouraged to collaborate and help each other out in favour of picking new tasks
- We bind people to tasks late, prioritisation helps them select tasks according to team need rather than specialisation
- Where a sprint commitment is missed we loose 1 story rather than a bit from each story.
So in short, I agree with much of what Craig has said, it should not be the responsibility of the PO to prioritise the sprint backlog. However, I do see the need for the team and PO to collaborate in order to ensure that the needs of the business do not take second place to the needs of the process. I also share much of Karl’s motivation with respect to limiting WiP and achieving Flow.
For me prioritisation is a strategy that a team can use to self organise around a given sprint commitment. It encourages collaboration and mitigates risk, how can that be bad?
February 3rd, 2010 in
SCRUM | tags:
Prioritisation,
SCRUM,
WIP |
1 Comment
SCRUM and Kanban (as applied to software development) are different. Proponents of the two drift from staunch opposition to declaring Kanban as a special case of Scrum.
I have been practising and coaching Scrum for a number of years and I delight in the effect it has on project teams. While I practice Scrum I find that Lean Thinking can both help me communicate Scrum and help teams to become more effective in applying Scrum. This way of thinking led to me becoming interested in Kanban a year or so ago since when I’ve being most concerned with where I ought to recommend Scrum and where Kanban.
Recently I have spent time with maintenance groups for whom Scrum would be a poor fit. Kanban offered me an alternative when the client was leaning towards a ScrumBut implementation.
There are some fundamental differences between early project / product development work and the later stages and I don’t see this as a problem. Toyota themselves hold two separate approaches. The Toyota Production System (TPS) is the most widely known Lean Manufacturing implementation. This is the world of work cells, standardised work, Kanban boards and Andon lights. However, when Toyota want to create something new they use the Toyota Product Development System. This approach focuses on a chief engineer holding a vision and rallying a team around him. High bandwidth communication, discovery and experimentation are the order of the day.
So back in a software development context Scrum was designed to manage uncertainty and complexity, to foster high band width communication and seems a valuable fit for early development.
Corey Ladas in his ScrumBan Book declares the following Axiom for applying his application of Lean to software development
Axiom 2: It is possible to develop any value adding increment in a continuous flow from requirement to deployment
Corey makes it clear as he progresses that this well defined workflow is critical to his desired approach. In a new development that workflow is often not known and usually not linear. Rather the team swarm over the requirement often returning to the customer for feedback before offering a completed deployable feature.
My suggestion is this, Scrum is a powerful approach to managing uncertainty as well as being a supportive environment for building a team. I believe that one goal of product development should be to reduce the uncertainty and evolve the workflow. As adding features becomes more straightforward we may find that we are in a state akin to production and can take advantage of a Kanban approach to further optimise for reduced cycle time, increased throughput and just in time scheduling.
July 28th, 2009 in
Agile,
SCRUM | tags:
Agile,
Kanban,
SCRUM |
1 Comment
Recently I’ve mentioned, both on groups and blog posts, the fact that many limiting Work In Progress in reserved for those taking on Kanban Software Development.
In this post I’d like to share a couple of the techniques / approaches that I use in managing WIP within a Scrum framework. These tools may be useful to you in order to improve an existing Scrum team or as a step in moving towards Kanban (see also Scrumban by Corey Ladas).
Daily Management
Members of an agile team should be empowered and trusted to work on the right thing. This may be helping out a colleague or fixing a broken build as well as building new features.
In order to encourage the right behaviour I propose the following filter to new teams. When looking for the next task to work on:
- Is there anything I can do to assist a colleague in moving a high priority task to Done?
- What is the highest priority task on the board that I have the skills to take on?
This has the effect of keeping the task in progress to a minimum as well as weighting the teams effort towards the top of the board (i.e. towards higher priority stories).
Some of the teams I have coached have had a code review column that development tasks must flow through, reviewing some code would be one way of assisting in getting to Done.
The effect of this approach is to minimise the stories in progress, maximise the chances of completing the higher priority stories in the iteration, encourage swarming over tasks and stories.
Project tracking
Many Scrum teams use burn down charts. Consider using a burn up chart, this provides visibility into changes in scope as well as room for further improvements as you’ll see in a moment. By tracking two lines representing scope and done we can our progress towards some milestone. In the example below blue shows the known project scope and green is work done by the dev team.
It is common to do some early analysis work before an iteration to ensure that the acceptance criteria of a story are known before the sprint planning meeting. We want to ensure that we don’t over invest in this analysis work retaining a healthy buffer of stories ready for development.
This part of the scope that has been analysed can be shown on our burn up chart, yellow in the example below. Here we can see where analysed work is building up.
Of course if we are doing this we may also add an analysis column to the task board along with a ready for development column.
Another category of work common in Scrum teams is post iteration testing. After the demo we hand off work to a QA or UAT group that validate the requirement has been met. By recognising this work we continue to expand our view along the value stream.
Below I show in red the work that has been accepted by QA. This demonstrates a problem in the system which was not made visible by the original chart. We can see that work that is developed but not tested is building up. If we care about WIP and cycle time then this is a problem, also if we care about project success we should consider this to be a build up of risk.
A final line could be added to show the deployment of software. A delay in deployment can mean missed revenue earning opportunities as well as a missed opportunity to learn and react.
I use these type of charts (Cumulative Flow Diagrams) as an aspect of project reporting in order to expose a more complete view of the development process beyond the confines of the Scrum team.
Also, where applicable I will augment the task-board with these extra states to show more project context to the team.
June 30th, 2009 in
SCRUM | tags:
SCRUM,
WIP |
No Comments
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.
January 19th, 2009 in
SCRUM | tags:
SCRUM |
No Comments
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?
November 4th, 2008 in
SCRUM | tags:
SCRUM |
No Comments
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.
September 22nd, 2008 in
SCRUM | tags:
SCRUM |
No Comments
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.
September 8th, 2008 in
SCRUM | tags:
SCRUM |
No Comments
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.
July 16th, 2008 in
SCRUM | tags:
SCRUM |
1 Comment
Last week I attended CSM training in Manchester run by Boris Gloger and Tobias Mayer. What a good course!
I do quite a bit of training myself and also get to see plenty of other trainers both good and bad. Suffice to say that the course Boris ran was excellent. With 11 people in attendance the group was diverse enough to promote discussion while being small enough to be sociable. The training was very hands on and Boris and Tobias provided an ideal environment for learning about SCRUM.
Amongst the highlights for me were the demonstration of self organisation and the emphasis on agile planning. This course gave me a useful insight into how SCRUM has been tailored to great effect in a variety of organisations.
This is quite an old post but seems to get plenty of hits. While Boris and Tobias ran an excellent course, neither are UK based.
If you are looking for UK based SCRUM or agile training please contact me using the form below.
March 13th, 2006 in
SCRUM | tags:
SCRUM |
No Comments
