Trying to see the big picture with Kanban

Awesome start at work!

I’m in a team of four very experienced and smart people, we have a product owner who is tech-savvy, knows what he wants and sits in our team room! On top of that we have an excellent room where single every wall is covered with material that you can pin stuff into. We have been given control over our tools and we are given a lot of trust (which is as it should be ;) ). We agreed to start with kanban as our development process and that made me extremely glad since I haven’t been able participate in a real kanban project yet!

We are now roughly two weeks into our green-field project. We started out with a simple three swim lane kanban-board where one swim lane is for product backlog stories, one lane for team stuff (environment, tooling, etc.) and one lane for the PO. Almost all work flow states have a WIP limit of 2, one has a limit of 4. At any time only two user stories can be under work. your basic kanban stuff.

We have the categorised the product backlog stories and pinned them on the wall. They form a vague big cloud, a chunk of things, that we are supposed to make. And this chunk is annoying since it does not provide a coherent vision, idea or goal for the team. Well, of course the goal is make the whole product, but that doesn’t really help in daily work. The team needs a short-term goal and a vision to support its work. The vision could be described as an epic, a collection of stories. Simply put, we need to know where to aim at on a shorter time interval. Our initial kanban board didn’t give this vision but our PO had already defined it and written it down on one of our whiteboards. So it was there for us but it wasn’t part of our kanban board. How could we incorporate it with our board?

I devised a kind of a funnel, a new stage if you will. Epics are pulled from the Big Cloud and placed into a funnel. It will be the teams goal and provide a clear path for us to work with. The contents of an epic are coherent and we can easily see, for example,  interdependencies between stories. It is also extremely useful when we manage to get some data about our lead time to help us estimate when a certain product increment is ready. This can then be conveyed to the stakeholders and business people. We can estimate and tell them when to expect a set of features instead of the whole product or just a single story.

To put it short, we now have three stages in our kanban wall. From the backlog cloud the PO can envision an epic for the team that will guide us to the next composition of increments. From the epic stage we pull stories to the kanban board for the teams daily work.

To some of you this may feel like we are aspiring for things that Scrum gives you out of the box. Well, we are but rather than restricting us with Scrum we are doing things that we feel benefit us and our stakeholders. We have retrospectives, we are going to show (or demo) what we have achieved and we are going to estimate the big chunk of stories. But we do an activity only if it will bring value. For example, if there is no value in estimating the backlog, we won’t do it. But we are going to try things that are deemed valuable either by the team or the stakeholders. And remember that the epic can be withdrawn at any time as it is not taken under work, we still do work only on story level!

I am eagerly waiting how the process will evolve and what is the direction it will evolve?

(picture by cantoni)

Kanban for delivering software

We work in an infinitely complex telco and service provider environments where it is extremely hard to keep up with the change. Our customers are driven by their user base which is as unpredictable as possible while the technological surroundings keep changing.

Thus they want their time-to-market to be extremely small. Despite the fact that we have solutions that are very flexible we sometimes struggle while trying to contain the changes. Year and a half a go we introduced Scrum in our R&D. Transformation is still ongoing but we have reaped some benefits of it.  Primarily we have managed to reduce a lot of waste, gained clearer prioritization and started to build continuoud integration systems.

We have delivery departments that deliver the required customizations on top of our platforms. They face ambigious, and sometimes even non-existent requirements from the customer and try to cope with them. There is a constant flow of changes coming from the customers as they elaboreate their own business models. Until recently everything has happened under waterfall processes, not least because of the strict contracts based on phases of the delivery.

As part of the Scrum transformation the deliveries have started to use Scrum in the delivery projects. The project teams are constantly fighting in a cross-draught of different projects. The teams may abruptly be changed taking away all that was built so far breaking every single aspect of team building, one of the cornerstones of Scrum.

After following the deliveries for a while I have come to a conclusion that their environment is too chaotic for Scrum. If they can’t even keep a team intact over one delivery it is useless. But there exists another process model in the world of Agile that fits this situation perfectly and that is Kanban.

Removing the unnecessary sprint plannings from their environment and concentrating solely on a continous flow of feature and change request deliveries they could achieve much more leaner projects. Prioritize tasks everyday, place strict limits on the amount of tasks that can be under implementation at the same time. In other words control the chaos by limiting the work in progress.

Limiting interdependecies

At work our Scrum transition has been going on for almost 2 years now. We tried to do a full adoption in one go and learned that changing the ways we work is rather challenging and that it takes time. Now after two years Agile thinking has penetrated most of our solution unit with little impediments here and there. One of the biggest obstacles we encountered and countered was the mess created by one huge backlog. You really can’t mix several teams within one backlog. It produces scattershot sprints and removes the feeling of continuity. It also makes it hard to commit to backlog goals.

It took something like 6-7 months to realize this and 4-5 months to finally get into a position where we could rethink our ways of working with backlogs. The solution was simple, one team one backlog. So, we ended up with 5 teams with their own backlogs. This has enabled us to focus more, to produce smaller stories and to concentrate on continuous integration implementation. By giving out focused responsibility to the teams we have seen a huge outburst of proactive working. People have seen and felt the change very positively and it has brought more inertia to the daily work.

As a byproduct we have accidentally created Bounded Contexts by removing dependencies between teams with the content of our backlogs. Now every team is responsible for a solution instead of an odd number of binaries with version numbers. We are not yet using kanban to manage the communication and work flow between teams but we might try (I have at least introduce the idea already).

The simple act of separating concerns and responsibilities into logical backlogs has reduced the overhead of knowledge transfer and decreased the effect of “chinese whispers”. As we have teams on different continents we are still waiting to see how things will work out. There will be more things to tweak, that’s for sure, but we are now much better off than we were. We have found the agile spirit again and we are closer to the intent of agile.

We have improved.