Hitting a WIP limit (fessing up)
Goeff WithaG pointed out that three cards currently in the queue for projects were really not in the queue at all because he had done some work on them already.
So, fessing up, I moved them into the "pre-dev" "wip" column and hey-presto, our first red card! We had gone over our limit of 2.
 |
| Our first red card |
What to do?
My preference was to move them right back to the queue again. This is where "make the work visible" from our Kanban became valuable.
I spoke to The Hadster and Shoes about it, explaining that we were going to move it back in order to respect the WIP limit.
What this meant was that of
none of us were going to working on it.
This was a simple but powerful result for me. All of the people working on an item are working on the same priority and with the same focus.
This has always been a challenge in project environments for me; where a BA is working on items x, y, z; but TA is working on y, a, b - which very quickly gets hard to coordinate, especially in terms of communicating externally with documents.
In the immortal word of a dutch friend of mine "I like it a lot" :0
WIP limit on avatars
Javascript suggested at one of the standups that we could use our avatars as a way of limiting WIP on a person-by-person basis.
We've adopted that on the basis that we only had a few to start with. I'm not policing it yet mind you - and I noticed that the Hadster has run out, but all he's doing is arranging his cards so that his avatar is stuck across two cards!
Having said that, I'm seeing that limiting it will be a good idea at some point soon if the overall WIP limits we set on maintenance tasks doesn't solve the problem in a simpler way.
The backlog is not a wish-list
I was hoping to have a rationalised list of existing Jira items (pre-queue) by now. What I'm noticing is that it's been a notepad for any idea that has been emailed in from the wider community.
I look at the backlog every day, but despite that it's still difficult keep clear in my head.
I was thinking about how I apply the "limit WIP" philosophy to this.
It seemed sensible that
not everything should just be thrown on the backlog.
This was partly because it clearly hadn't helped to this point - there were items in there going back six months that we were in no danger of being worked on! nbsp; Another reason is that we had the same "spinning plates" problem, just earlier in the lifecycle. nbsp; With such a long list, the overhead of just.
So if not everything should go on the backlog, how do we choose?
Benefit-driven backlog
The logical solution is to only allow items on the backlog when we have enough information to sequence their benefit relative to other items in the backlog.
In our case, most of our suggestions come from a desire to take pressure of call centres or reduce cancellations, reduce dropout and so on.
I've spent time this week talking to originators of older Jiras, to get a feel for more metrics, to add them to comments for our prioritisation meetings (when we start them).
This in turn has lead to a suggestion to all of our stakeholders; to better track inbound call volumes, reasons for cancellations and so on. This seems to have been well received and it will give us a way to sequence our work much more effectively.
I've actually closed down a couple of the related Jiras with instructions to the stakeholder to re-submit it to us once they have some of these metrics captured.
Obviously this is something unrelated to Kanban, but using the "limit WIP" ethos seems to be working out for us in more ways than one, which is great.
Help someone else
While we're in transition, developers have been grabbing stuff from the backlog (Jira) that requires little or no pre-dev work and putting it straight into "dev" "wip".
Brazil came over today to chat about what to grab next.
Instead of going to Jira, we went to the board to have a look...
 |
| Maybe we shouldn't grab something new? |
Even though we don't have a WIP limit on maintenance yet, it was pretty obvious that there's too much going on, right?
We asked ourselves what we would have done
if there was a WIP limit.
The Kanban answer is - help someone else. So we had a look at what was on the board already and how Brazil could help move one of these along quicker.
Actually there was. Even though it required a 10 minute conversation with Geoff WithaG, there was an item already in WIP that Brazil was going to be working on later anyway, so we just pulled it forward.
Such a simple thing, but now instead of increasing the number of spinning plates, we're putting energy into moving the current work faster, which I suspect is going to be more satisfying for developers too.
Walk and Talk
While looking at the board with Brazil earlier, I noticed that there was another item there that Cheshire hadn't mentioned in the morning stand-up.
I asked him about it. He was waiting on Shoes to get back to him. She in turn was waiting on an answer from another team regarding a list of values for a drop-down, before she could hand it back to Cheshire and it could be completed.
Shoes was not at her desk so we walked over to the other team, who sit on the same floor. I introduced Cheshire to the business manager of that team and explained that it was holding us up. As it turns out, the person we needed to talk to wasn't around either, but now Cheshire is in direct contact with the right person I suspect it will move much faster.
Cheshire and I agreed that this walk and talk approach was a good one and more empowering, so I'll bring it up at our retrospective.
The agile manifesto "Individuals and interactions over processes and tools" is going to be a good strategy for us to ensure work items move swiftly through the system instead of being held up by email inboxes. At least I hope this is the case!
Happy with the "real" wall
After a full week using the "real" Kanban wall (more accurately whiteboard!) I'm pleased we went this way rather than opting for the electronic-only option.
We've only had a couple of instances of getting out of sync so far and these are more about getting used to the issue types in Jira rather than the process itself.
We're enjoying the upside of having something physical to interact with; it's encouraging people to grab other people, walk over to the board and have genuine interactions rather than relying on computers to communicate for them.
So despite the fact I was keen on the electronic version to start with, I'm taking full enjoyment from the low-fi solution.
First prioritisation meeting
We had our first prioritisation meeting this week.
During the week I've been instructing people not to raise new requests in Jira, but to keep a list and table it in person at the meeting.
The objective of this meeting was different from those I've run in the past with Scrum or XP.
Because Kanban is based on a "pull" principle, all we really needed to do was to put a few items in the queue - so that there was just enough for the pre-dev work to happen for 1 week.
As expected, the first meeting was a dog's breakfast in terms of side discussions and we went into too much detail on a few things. But we did achieve our objective, which was a list of 5 items that everyone agreed were the more important from a business perspective, for the queue.
We also agreed that we would use some of the remaining technical requests (e.g. purge job, cleaning up some properties files) as fillers if people had a small gap to fill at the end of the week.
Columns aren't human beings
One of the questions that came up last week was "do items move backwards and forwards?".
For example, if something is in acceptance testing and we get a bug, does it go back to in-dev?
Or if something is in dev and I need a clarification from someone regarding requirements, does it go back to pre-dev?
What we realised is that there's a tendency to treat the columns as groups of people - rather than the states that a task moves through.
It's a subtle but important distinction for us. Especially given that we're encouraging people to cut across these boundaries when they're helping each other out.
So the answer for now is no, we don't generally move things back and forth to represent handing it back to developers or forward to test etc. These are just overall representations of where the task it at in its lifecycle.
Big tasks vs. small tasks - what's on the board
As with any project, our big tasks are broken into smaller tasks.
If something has value and can be deployed by itself, it can go on a card on the board (and Jira of course).
If this "thing of value" is significant, we have two options:
- Break it into smaller cards
- Leave it as one card, break it into sub-tasks in Jira
My preference is the first option - but we can only do that if the two cards each have value in their own right - and can be deployed separately.
In cases where we deploy as one unit but break into sub tasks in Jira, we use Jira to manage and track the individual tasks - rather than the board.
This philosophy clicks with the rest of our operating model in two ways:
- Sub-tasks tend to be less than a couple of hours, so individually they're "noise"
- Most of the ones with sub tasks are projects
.. ( transmission ends ) ..
