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!
Image may be NSFW.
Clik here to view.
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)
