One of these companies is new to the Agile programme, we did training for the entire company last month and this week I was there to get them started for real. This meant we had to design their board layout and talk about workflow. Once again I found myself advocating Xanpan, the cross between Extreme Programming and Kanban.
The board layout - effectively workflow - is on which reoccurs in Xanpan systems and I would like to discuss here. (I’ll explain the layout here and in a second blog entry I’ll post a picture and talk about the future.)
The problem companies/teams face is: they have planned and unplanned work to do. Typically this is some project they are working to deliver but they need to work on support issues - bug fixes - too. I say that, but it is not just support issues, sometimes it is clients who shouts very loud, or managers who can’t say no, or customers who refuse to wait a few days - indeed sometimes to do so would be the wrong thing to do.
The Scrum answer to this is to stamp on the unplanned work. The team are locked - remember commitment and Sprint-goal. This unplanned work is a problem the Scrum Master should stop - or declare Abnormal Termination of Sprint. Particularly in small companies this isn’t a very useful answer, the truth is, things are more complicated than that, planet-Scrum is too simple.
The ultimate solution is to look at the reason these unplanned items are arising and try to address the root course. In time it might well be possible to do that but right now we don’t want to block the team’s transition. Even in the long term this might be the way of the world for such a team.
The Kanban answer would be to go in the other direction: run all work as “unplanned” and just restock the to-do queue as needed. However this robs the team of the rhythmic certainty of a Sprint. Many of the teams I see need to move away from seat-of-the-pants decision making and knee-jerk reactions. Adopting regular iterations builds in decision making points and helps individuals understand their roles.
So: Xanpan, keep iterations/sprints but allow for unplanned work. To do this we design a board which begins with the three columns:
- Planned
- Unplanned
- Prioritised (usually this queue is limited)
- WIP: In development (usually WIP limited)
At any time work can be added to the Unplanned column. The column is unlimited.
A few minutes before the morning stand-up meeting around the board the person with authority populated the Prioritised column reviews and populates it. This could be the Project Manager, Business Analyst, Team Leader or someone else, the role and title doesn’t matter, what is important is that this person has the authority to do this. On one team this was the joint responsibility of the Project Manager and Business Analyst.
This person looks at the work still in the Prioritised queue, and they review the Planned Work and Unplanned work. From these sources they decide the priorities for today. When the team gather they can see what the priorities are. For the sake of simplicity it normally makes sense for the Prioritised queue to be limited and for the priorities to be ordered: 1, 2, 3, up to the limit.
If need be priorities can be changed during the day: maybe something even more urgent arrives - or goes away, maybe the prioritised queue empties, or some such.
Effort estimates are normally assigned to planned work during the planning meeting. For unplanned work some teams don’t both adding estimates, some added a quick estimate from the person who picks up the card when they pick it up and some put an effort estimate on when it is complete.
Importantly, the original source (planned or unplanned) is recorded on the card - maybe a different colour card, maybe a dot, a word, whatever. At the end of the Spring the team can review how much planned and how much unplanned work was undertaken.
Thats it really: planned, unplanned and prioritised. The first two are effectively queues for the third. Somebody, or bodies, are responsible for balancing priorities.
It is possible that this workflow/board layout is actually a transitional layout. After running with this flow for a while there will be data on how much unplanned versus planned work actually occurs.
Hi Allan,
ReplyDeleteThis a exactly what I'm doing with my Maintenance Team. Currently the Team lead is the person who decide which Story does into the Selected column. A bit the same as what you called Prioritised because the stories there are the ones with the highest priority. Our next step is to give that responsibility to the business and let them decide which story (ticket) is important.
What I am wondering about your method is the following:
You said the team does the usual Planning Meeting etc. Is this part the same as in Scrum? So come up with estimation then based on Velocity take the number of Stories into the Sprint etc.?
Because if that’s the case, how do you deal with blocking issues. So I’m not talking about unplanned bugs that can wait and therefore easily planned, but more about this-issue-needs-to-be-fix-now-otherwise-we-will-lose-customers-and-or-money kind of issues. In other words, if these kind of emergencies occurs (which happens randomly) the possibility of not completing the Sprint can be outcome.
If a company has these kind of issues exists and the teams velocity is heavily related to it, then what’s the use of having a planning meeting if the team can’t commit.
Cheers, P.Ross
Ross, planning meetings are the same as Scrum/XP.
ReplyDeleteThe "this-issue-needs-to-be-fix-now-otherwise-we-will-lose-customers-and-or-money" are unplanned work and I would expect them to jump straight the the top of the priority queue. If they are serious enough then something WIP would need to be stopped, even moved back, so someone is freed up with deal with the issue now.
As for not completing the Sprint... well the Sprint is always completed because sooner or later you hit the end date of the Sprint. I suspect your question is really "How do we do all the things we said we would do if we take in unplanned work?"
The answer is really: you can't, so don't even try.
Lets be clear: if the work to be done changes after the start of the sprint then all bets (or commitments if you prefer) are off. There is a trade off here: predictability (locked Sprints) v. speed of delivery (urgent stuff.)
This is part of the reason I don't sign up to Commitment protocols. You can manage this problem (active management, tracking, velocity, etc.) but asking laying the issue at the feet of the team is unfair.
Hi Allan,
ReplyDeleteThanks for your quick response!
I totally agree with you that’s it’s unfair to ask the team for a commitment while the scope is continuously changing. It’s simply impossible…
Do you still think it’s still useful to do the planning meetings then? Because the goal of those Planning Meetings are functional understanding of the stories as a team, coming up with estimations and see how much work the team can include in the next Sprint.
As you know, the estimated complexity can be used for calculating the team velocity again…
In short, a lot of time are spend (and wasted) on trying to be predictable as a team while the environment constrains us for being just that…
What we do now is:
- Sprint Planning Meeting with every aspect that I mentioned above.
- Start the sprint. (2 weeks)
- Blocking issues occurs, so WIP gets stopped.
- Fix blocking issue
- If it’s fixed then we continue with your Stories.
- At the end of the Sprint we count all the points and that’s our velocity.
- Based on that velocity we take x amount of work in the next Sprint and hope no issues occurs…
It’s basically about accepting that these kind of issues may occur and it affects our sprint… Only thing we can do is do our best and at the end of the Sprint show the business what we have done and explain over and over again WHY we didn’t f complete all the stories and hope that the organisation will change… (sounds a bit depressing he?)
Cheers Pablo,
Pablo,
DeleteSorry for being slower to reply this time!
Are planning meetings worth it?
Difficult to answer without going into details of what you do in them. Two forces I can think of immediately:
- If you still have some planned work then it is worth planning
- If the team are getting value from the meetings; to me a planning meeting is more than estimating its also design and requirements elicitation
Have a look at my Story Points mini-series from last year
http://allankelly.blogspot.co.uk/2012/04/points-4-of-4-breakdown.html
Your description of a planning meeting sounds pretty much like I'd expect. You don't mention a retrospective, do you do them?
Two thoughts as to why they may not be very effective:
1) you say "hope no issues occur". This sounds like there is a lot outside your control. It also sound likes you aren't actively working to prevent issues occurring.
There is more to resolving blocks and issues: you should be resolving them now and then fixing the courses so they don't occur again. If you are not able to do this then we need to talk about why.
2) Who is controlling the flow of work into the sprint? Do they have the knowledge, authority and time to plan in advance?
How much of the unplanned work could have been identified?
Getting the business to change is really hard, you can take a horse to water but you can't make it drink. Until the business get the idea you will be hampered. However until you can deliver regularly and meaningfully they will have no motivation to change.
Hi Allan,
ReplyDeleteSorry for the late reply as I have been busy these couple of days.
I believe that the Planning Meetings still add value, but perhaps we shouldn’t be calling it Planning Meetings anymore because business usually think “when there is a planning meeting then the result will be a solid plan”. There are some stories that can be planned of course, but if we can finish it, is another thing.
Yes we have retrospective planned at the end of every Sprint, but we’re still in Sprint 1. Looking forward to the retrospective ;-)
You’re right about no control of the incoming issues. The issues that I mentioned aren’t maintenance issues that can wait. Those issues are usually problems in production, so unplannable and unpredictable.
This is actually something the team can’t fix because it’s an organisational problem because they don’t have a proper helpdesk/first/second line support installed yet, so all problems goes to Development directly. The organisation is currently fixing this problem, but it takes time.
Pablo