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.