The value stream of the digitec lean portfolio Kanban system - step 3

It is one of the hardest things to understand the value stream of your organization. An essential element of Kanban is to visualize this value stream. Kanban is a “tool” to improve that by understanding the mechanisms and effects that occur in the system by working with and observing the system. This is not a blog about Kanban. Read the book Kanban by David J. Anderson and you know what I am talking about.

In this blog I talk about the implementation of our Kanban system around initiatives. Initiatives are the most abstract elements in our portfolio management that we manage in a Kanban way. We implement our strategy through theme related initiatives that realize the desired outcome.  See my previous blogs to understand what themes and initiatives represent in our portfolio management.

I do not talk about our strategy itself (if you are interested in the Digitec Galaxus strategy, go to one of our online shops following the links and try to figure out yourself ;-). 

Derived from the strategy we identify themes, initiatives, activities, milestones, decisions to be taken on that way that most probably will implement our strategy. We call this our roadmap. The roadmap has a real physical representation following the story mapping ideas of Jeff Patton (see Jeff Pattons blog and I recommend to read his book User Story Mapping). Actually our roadmap is a story map filling eight meters of a wall two meters high in our roadmap room. It is built out of about three hundred sticky notes in three colors, yellow for stories, blue for milestones and red for top level decisions taken by the executive team. 

An eight meter roadmap (sorry - cards are not able to be read ;-)

This roadmap wall is the idea generation engine, our seed feeding our innovation process. We identify themes, initiatives and dependencies standing in front of the roadmap and discussing about the next steps to go, about priorities, our capabilities, dependencies and time constraints. "We" is interesting. "We" are different groups of persons that walk by and reflect. So the wall gets its updates (...and there is still room to improve the update cycle) .

This is where the Kanban system starts: with ideas for themes and initiatives. As we identify a theme (could be one card in the roadmap), often very vague and unclear at start, it is decomposed into a first set of (one or two) initiatives with the goal to learn about the theme and to draw decisions about the further development (subsequent  initiatives) of the theme. During the life cycle of a theme there are seeding initiatives, more conceptual initiatives with or without prototypes and spikes, implementing initiatives – all in parallel and prioritized against each other.

Well I have to confess: With prototyping and spikes in conceptual initiatives we still struggle a bit. At the moment there is too much concept work done compared to prototypes or spikes that clarify and verify requirements, assumptions, technical risks and usability. At least we identified this impediment. So we have the chance to improve. You see - the second topic we do have room to improve. Things are continuously changing and improving :-) 

How we turn this story mapping wall into a Kanban System and how we implemented the Kanban System tool supported I will follow up in upcoming blogs.

Building up a lean portfolio management Kanban system – step 2

In my last blog I discussed the core requirements of our Kanban system and the introduction of a third abstraction level called initiative above user stories and epics.

Why did we use the term initiative? SAFe is using the terms epic, feature, story for the three abstraction levels of work items. Other methodologies are using theme, epic, story. Well our decision to go for these terms was pretty simple and straight forward. We are using the Atlassian tool suite. The Altassian JIRA tool suite just released itself an implementation of a lean portfolio management with three abstraction levels they called initiative, epic and story. We tested the Atlassian implementation. At the moment this implementation looked a bit too heavy weight for us, but eventually at a later point in time we move to the Atlassian implementation.  In this case we already established the terminology. Changing terminology is harder than changing tools.

To build a Kanban system around initiatives, we needed to identify and visualize our value generation stream and our portfolio life cycle. This life cycle includes the birth, the maturing and finally the working with and closing of initiatives, epics and user stories.

Interesting was the discussion about the term project. Do we still execute projects? What is the difference between a project and an initiative? We could not agree about what a project is. Actually I personally try to avoid the term project at Digitec Galaxus. I try to avoid that we run projects. Too many different interpretations and opinions exist what the term project represents. The most serious association with the term project is that a team has to work for a project, i.e. there is a project team working solely in the context of this one project. That does not support the idea and mechanisms of a lean portfolio management. Instead all work in the system shall be done prioritized by the existing teams. Work shall be pulled by teams, so that teams stick together and build a shared knowledge. In the classic portfolio management teams are constructed around projects, i.e. teams are built around work – often with functional specialization of persons acting in roles within a team that exists only during a limited period of time.

There is an additional factor in projects: the size. The size of projects is extremely different. For example adding a payment method to the online shop is most probably a small amount of work, a small project. Building a new stationary retail shop most probably is a large project with many aspects and sub-projects including construction, hardware, and software. What we try to avoid in our lean portfolio management is that such a large project creates the side effect that small projects lose focus just because one project is big and looks important. Small things might be as important and even generate a higher value for our company. The weighted short job first (WSJF) approach out of SAFe respects this. We decided to break large projects into smaller junks, a set of initiatives. Each of the initiatives owns a set of goals to reach and a well-defined outcome. To be more precise we followed here as well the terminology of Atlassian and renamed such large projects into “themes”. So building a new stationary retail shop is managed as theme that will be developed within a set of initiatives. Each initiative will have a clear goal and outcome and develop the theme to the next step, milestone or decision point. Initiatives within a theme can run in parallel or in sequence, depending on the theme.

With these discussions in mind we defined some constraints for an initiative to feed our Kanban system. The definitions we set are simple.

• An initiative shall deliver a business value, an outcome. We defined three basic types of value that we explicitly set for an initiative: 1. Innovation 2. Architecture 3. Housekeeping. I explain these three types later.
• An initiative is related to the strategy of our company. An initiative is part of the implementation of our strategy, so it realizes a change of any kind. Often this includes changes of end to end business processes or organizational changes and requires the cooperation between departments.
• An initiative shall last a period between 2 months and 6 months lead processing time. We strive that the average initiative will consume a lead processing time of 3 months. I will define what we understand under lead processing time below.
• We call larger projects a theme to demonstrate the difference between the classical interpretation of the term project to our way of working. A theme is driven by a set of initiatives that deliver an outcome to develop the underlying theme. There is a feedback loop between a theme and the initiatives that develop a theme. The outcome of an initiative may or course change the theme.
• Initiatives are the most abstract work item element that we manage in our Kanban system.

There are no other limitations. We did not define what the deliverable of an initiative are or look like. It can be a piece of software, a concept, an organizational change, a decision how to go on, or even a mixture of all that. We do not define limitation on budget or effort. If we agree that we start processing an initiative, the resources and competences are available, otherwise we simply cannot start.

I still have to explain the business value types of 1. Innovation 2. Architecture 3. Housekeeping and the term lead process time. We defined the value types as following:

• Innovation: The outcome of this initiative directly delivers a new feature to our customers through any of our channels in our multi-channel communication. A customer is a real external customer generating turnover, not an internal customer. Example: A new payment option or a new delivery option that we provide as service to our customers.
• Architecture: The outcome of this initiative prepares a new capability of our systems or our organization. With this new capability we are enabled to create a new innovation for our customers in a next step (initiative). Example: We implement a new standardized integration layer for an automatic data exchange between business customers and us. Next step will be the implementation of the data exchange (a new feature, i.e. an innovation).
• Housekeeping: Any means to increase productivity, efficiency, automation or usability of our systems that are not directly related to new innovative features for our customers. These initiatives improve our capabilities and competiveness in the demanding online shop market.

To phrase that less formal: Innovation is some direct benefit for our customer; architecture prepares our systems and organization to create a direct future benefit for our customers; and with housekeeping we improve ourselves internally to generate more profit.

It required some discussions until we agreed about the value type definitions. Especially many persons perceived the term “housekeeping” as a second class citizen. Well, “keep your house clean” is not that sexy than to generate and develop new features for our customers. Nevertheless to preserve the capabilities required to drive our business in times of growth within a demanding market, housekeeping is an essential activity. This is part of a lean mindset as well. Even all our internal processes shall be simple, straight forward, without rework, work on stock or waiting time. Housekeeping initiatives care for this aspect. I often used the analogy with housekeeping in your private flat. Think of refactoring your kitchen with new cooking devices, ovens, steamer and so on. You still will just cook - but the quality of the food will be impressing better; your friends will love you preparing the next exclusive dinner. That is housekeeping. That is different to just using the broom and wiping dust.

The next discussion still ongoing and probably still lasting quite a time is the term lead processing time. To understand the term lead processing time you have to understand the value stream of our lean portfolio management. This will be subject of my next blog.