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
Karl has offered this post explaining the difference between a task board and a Kanban board.
He draws attention to the common task board focus of tasks to do this iteration. No WIP limit, only tasks currently in development.
This differentiator becomes less apparent when we look at how teams develop their use of task boards. Personally one of my prime reasons for using a white board over an electronic tool is to open up the possibility of the team changing the layout.
It is common for teams to apply the mantra, don’t start something new if you can support an existing activity. In addition to, always ensure that you are working on the highest priority story to which you can contribute. While this is not a fixed WIP limit it does reduce the work in progress in terms of both tasks and stories.
It is also quite normal for a team to choose to show upcoming stories where early analysis is due in preparation for a sprint. Add to this a column for acceptance testing, again not unusual, and we begin to see similarities.
I really appreciate the contribution that the Kanban community have made to our collective body of knowledge. However, it may be beneficial for them to more openly recognise the broad overlap in values between Kanban practitioners and the rest of us agile folks.
May 27th, 2009 in
SCRUM | tags:
Kanban |
No Comments
Karl Scotland has proposed an agile workflow to counter some of the waterfall like connotations apparent when we look at a Kanban board.
So for each feature, one by one, we end up with:
Incubate –> Illustrate –> Instantiate –> Demonstrate –> Liquidate
Does that still seem like a waterfall process?
I think that Karl’s reasoning is sound and I have used similar workflows with SCRUM teams to ensure that they keep the entire value stream in view.
However, before I go on to describe the workflow I am currently using I should stress what this workflow is.
A feature workflow is just that. The feature goes through a number of states from the lightbulb moment to deployed, in use and generating value. A workflow in kanban does not mandate hand-offs between individuals. Equally there is no demand that the team do not swarm over the feature ensuring it travels smoothly and quickly between states.
As Karl states, it is common for SCRUM teams to visualise features as being to-do, in progress and done. I tend to add a couple more states in order to visualise the product backlog; it is nice to have items at the top of the product backlog that are ready for development to pull, everything else on the backlog is simply identified.
So, I have: Identified, Ready for dev, To-do, In-progress, Done.
To tidy this up a little more I can say: Identified, Ready for dev, Committed, In progress, Dev Done.
Again Karl identifies the fact that if it’s not deployed then it’s not generating value. I also tend to work in environments where there is more to do between Dev done with it’s automated unit and acceptance tests and go-live. I’m not saying this is ideal of even that it’s an end state but I am currently looking at workflows a little like this:
Identified, Ready for dev, Committed, In progress, Dev Done, Iterative test done, QA accepted
Where iterative test is an ofset risk mitigation exercise including exploritary testing, some performance assurance and anything else that we can’t pull into the iteration but we’d like to get feedback on ASAP. QA is just that, if we’ve done everything right then there will be nothing coming back from QA.
Of course a workflow like this provides me with the opportunity to visualise work in progress using cumulative flow and to identify bottlenecks. Don’t forget, this is a SCRUM team, we batch 2 weeks work into an iteration because right now that is helping us. Maybe one day we’ll decide to go towards single peice flow but not today.
February 26th, 2009 in
SCRUM | tags:
Kanban |
No Comments
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:
- Effective tracking of progress through delivery of end to end features rather than intermediate documents
- Effective risk management and mitigation through early detection and adjustment of priorities bringing risky features forwards or perhaps deferring to a later release.
- Effective adjustment of the plan in order to increase / reduce scope or adjust release dates according to delivery track record. Again adjustment of priorities can play an important part here by working with the PO to ensure a cohesive stable product for release.
- Effective stake-holder management through constant feedback and re-evaluation of the business case.
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.
February 23rd, 2009 in
SCRUM | tags:
Agile,
Management |
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
