We are about six weeks after pimping my team - let’s see what has happened since then. A massive change is usually followed by a calm period. During such a period the team adapts to the effects of the change (new environment and methodology) and only small additional changes are applied, something like fine tuning. This is what’s happened in our case, and I think it’s worth sharing these small things.
The team moved to a different part of our landscape where we could try out a new seating layout. First not everybody was happy with it, but now everybody likes the place, and I heard someone advertising it to other teams. So far so good. Unfortunately, we weren’t that successful with the methodology and our way of working. We started to work on a poorly designed feature on a fairly complex code base, while we did not make ourselves masters of the Kanban + XP methodology. However, we tried to solve the problem with a slight change of the board and our way of working.
Previously we were using items, but after watching the Single Piece Flow in Kanban presentation, we started to use and talk about MMFs (Minimum Marketable Feature). We broke the feature down to MMFs and did a release plan.
Let’s have a short interact about release plans. > A release plan carries important information for the customer about the forthcoming releases. Additionally in our case it also provides feedback to us about our way of working: “if we continue to work like this, we won’t finish our work before a certain date”. If the date of our predicted finish is after the expected deadline, we have to do something about it. The following options are available: > > 1. Escalate and negotiate a new deadline > > 2. Try to improve our way of working until the predicted date is before the deadline > > 3. Reduce the scope
Back to the release plan topic. So I came up with the following one:
We are going to work on two MMFs simultaneously, because:
-
Due to the nature of the feature, most of the MMFs can be done in parallel
-
Our team is quite large, so we have the man-power to work on two MMFs at the same time
-
We have to speed up, because otherwise we cannot make it to the next deadline (our predicted date is after the deadline)
Track 1 has higher priority than Track 2. This means that if someone becomes available for work, she is supposed to check whether she can contribute to an MMF on Track 1. If this is not possible, she should work on an MMF on Track 2. When her knowledge is required in Track 1, she should stop what she is doing and work on Track 1 until this necessity disappears. In our plan, MMF 1 and MMF 3 were essential, without them the new feature was worth nothing, so we were supposed to do everything in order to finish them.
Our Kanban board changed according to our release plan. When we started the Kanban + XP we had a WIP limit of 2 on the active items - now MMFs -, and now we have two simultaneous tracks, where the first track has higher priority than the second one. Fortunately, there was no need for a huge change on the board.
Before:
After:
The change log:
-
The Active items row became a column
-
The former 4 WIP limit on the ongoing items became 3 for each track (the global 7 limit still applied)
We started the work, but the first MMF was more complicated than we first thought. Almost everyone worked on it, and some old habits have turned up: when the team did Scrum, the individuals or pairs worked on different tasks simultaneously and when there weren’t any developer tasks left, they moved to the next user story. This was quite convenient, but this time there were no tasks, there were no next user stories, so the team members had to communicate and find out themselves what the next step would be. Based on observation (annoyingly asking me several times a day what to do next) this was very hard for the team, but I believe after having this particular skill they will be better at agile software development.
Until the team members mastered this skill, they needed some kind of guidance, so I asked them to have regular design discussions. During these discussions, they had to draw mind maps which show the main parts of an MMF, problems and possible solutions. These mind maps ended up on our wall so that everyone could see them all the time, and update them when necessary. With this approach, it is visible what needs to be done, how things are connected and which way to go. The team is still learning to use the* mind map*s, but there are very promising outcomes - the frequency of annoying questions is lower now.
Even this simple example mind map states how things are connected, what is done (Part 1), and in which order the nodes need to be handled (mind the numbers next to the nodes). It is easy to spot an important node (Part 2) , an idea (Idea 1) and something which does not work (Cont. Int.).
As I said earlier, MMF 1 turned out to be more problematic than we had thought before. Every day a new detail showed up, which delayed the delivery of MMF 1 day by day. Lean software management states that a team is not supposed to start working on an item until it is 100% sure what to do and how to do it. Actually, that is easier said than done. We realized that we needed to know more about the MMFs, so we started to do small spikes before starting to work with them - as XP recommends. Additionally, we added these spikes into our next release plan document to make sure that the team does them.
This is where the team is at the moment. In the starting post, I promised a series of posts, but actually this is the last one, because I’m going to leave the company I was working for when writing these posts. I hope that the principles I taught the team will help them survive and deliver the feature on good quality - not necessarily in time; quality is more important than delivery precision at the moment.
comments powered by Disqus