The life cycle of an initiative – step 4

In my last blog I introduced you to the roadmap as seeding mechanism for our portfolio management. In this blog I want to explain how the initiatives are derived and managed in our Atlassian Jira system.

As you might imagine, at any time there are initiatives on different maturity level. Maturity spans from very vague und unclear ideas to well know initiatives with clear defined goals. Initiatives below a certain maturity level we call ideas. Ideas often are specified by a few phrases about what the outcome and the benefit for our customers and/or us might be. Ideas are the start of the value stream related with initiatives.

Ideas at Digitec / Galaxus basically are born at two different places in our organization. One place is a department like marketing, supply chain management, retail or engineering. The other place is the executive team.

The challenge is to create a Kanban system with simple and understood communication channels that route the ideas well prioritized through their life cycle. Quite a number of our ideas end up in our icebox, the icebox (actual the “on Hold” status in our Kanban system) holds potential initiatives for unfreezing any time in the future. The very creative teams in your company always generate many more ideas as can be realized with limited resources. Important is to communicate this aligned to our strategy and to make it transparent and understood.

Many ideas are tiny things a department can realize on its own. These ideas directly are handled by the department. This is part of the daily work of an department.

Many ideas do have the character of small enhancements that require limited engineering resources to be implemented.  These ideas we run through a fastlane mechanism I will talk about in detail later. So far it is only of interest that the fastlane mechanism is a specific very lightweight input queue of low bureaucracy to engineering.

Only very few ideas are potential initiatives. These are the ones that span over departments, are more complicated and/or require a certain extend of resources to be realized. These ideas we mature towards initiatives that we run through our company wide initiative Kanban system. To manage this stage in the life cycle of an initiative – from first idea status to the “pretty sure that this is a real initiative” status, we introduced a lightweight innovation process in the departments. I will talk about that in as well in a future post, but actually this innovation process is following the “Stars to Road” concept of idea maturity. This stage in the life cycle of an initiative looks as following:

Ideas move from departments into the (one and only strategic) company wide Kanban board 

As you see, actually we established two processes in our organization that work hand in hand. The innovation process that generates ideas and develop potential initiatives towards the company wide initiative Kanban board; and as the second stage in the life cycle of an initiative the portfolio process that matures and drives an initiative from proposal to closure. 

Formally we identified a well-defined set of states in the life cycle of an initiative from idea to closure. States of an initiative while living in the innovation process in the context of a department are:

• Initiative idea new: An idea comes into existence 
• Initiative idea approval required: The idea is proposed to the company wide initiative Kanban board
• Initiative idea approved: The idea is accepted by the innovation board that manages the company wide initiative Kanban board

In Jira we implemented initiatives living in the innovation process as issues of a new created issue type idea. Every department works with its own Kanban board for ideas. The Kanban board exists as a real physical white board working with sticky notes. Additionally every department owns a Kanban board in Jira managing ideas and normal tasks. The physical white boards are used as communication and collaboration medium. The Jira Kanban board holds a subset of the white board “cards”.

An initiative in the status “Initiative idea approved” will be moved from the department (Kanban board) to the company wide initiative Kanban board. In Jira this is a move of an idea issue from the department board into the company wide initiative Kanban board . With this step the department has to write a vision what the outcome of the initiative most probably shall be. The vision is a much focused description that shall not exceed two screen pages. In our tool setup an initiative is a Jira issue of type “initiative” (we created as well this issue type). The vision is stored in the description attribute of the issue and follows a template structure as following:

Vision template for an initiative proposal

This template guides a department to write a focused vision statement. On request a department gets support from the business development team in writing the vision statement. 

States of an initiative while living in the portfolio process in the context of the company wide initiative Kanban board are:

• Initiative new: the executive team proposes a new initiative. This is the input channel for the executive committee into the company wide initiative Kanban board. 
• Initiative approval required: the innovation board (this is our decision panel about initiatives) decides about initiatives in this status. The result is that the proposal is either approved, declined or set to on hold (stored in our initiatives icebox)
• Initiative approved: the innovation board accepted the initiative. In this status we invest more effort to develop the initiative (kind of backlog refinement) so it can be realized.
• Initiative on hold: the innovation board accepted the initiative. Nevertheless because of strategic reasons the innovation board decided not to invest effort now. The initiative is iceboxed. This status represents the icebox status of good ideas. The innovation board justifies why the initiative is iceboxed and gives feedback back to the source department
• Initiative declined: the innovation board decided that this proposal is never ever of any value. The innovation board justifies why and gives feedback back to the source department.
• Initiative in Process: we work on the initiative with the goal to create the outcome as fast as possible. 
• Initiative in Review: the outcome is realized. Now we review the outcome with all stakeholders before we move the responsibility to work with the results back into the departments. 
• Initiative closed: All stakeholders agree that the outcome is satisfying.

Our company wide initiative Kanban board  acts as following:

Concept of our initiative life cycle or value stream for change

Jira experts will encounter that such a board cannot be implemented as a single Kanban board in Jira. Actually our implementation offers two views. The first view implements the lower swimlane for evaluating a deciding about ideas, the second view implements the upper swimlane used in the portfolio management of initiatives.

Another challenging task in portfolio management is the demand – capacity balance. A lean portfolio management system is built on a pull system instead of a push system. Teams working with the Kanban system pull work as represented and prioritized on the Kanban boards. Once priority is defined, the speed items develop to the next status and finally to done depends on the resources made available. The goal of a lean portfolio management is to create the maximum outcome with a given capacity. What “given capacity” is depends on the investment management is willing to invest.

The demand is represented by the initiatives in our Kanban system. The capacity is limited by our workforce in the departments and engineering. One key resource and always a bottleneck for sure are our engineering resources, i.e. our software development department including business analysts, software engineers, business intelligence experts and (yes you may wonder, but I discuss this later on) project managers. The reason is obvious: we always have more ideas what we could realize compared to the affordable resources.

Well – I will talk about our ideas of demand – capacity balance in an upcoming blog (I see there are some upcoming blogs I have to write J). As well prioritization of initiatives is a very interesting topic I will address any time in the future. So stay tuned. 

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.

About energizing people and empowering the team

Maybe you once read the book Management 3.0 by Jurgen Appelo. If not – read it. Especially the chapters of how to energize people and build up motivated teams gave me insights and ideas that helped me in my current situation.  Let’s see and example.

After about two months of working we introduced additional ceremonies to organize our team work based on our daily work that was (intentionally from my side) somewhat ad-hoc organized so far. In this period we all learned what communication we needed within the team and in collaboration with all the other teams we interact at Digitec Galaxus.

My team members were not that happy that I as the boss did not define ceremonies right from the beginning. Becki once gave me the feedback “your listening. That’s good, I like that. But sometime I would like you to decide and define”. That was my experiment in building up the team. My idea and hope was that a certain state of unhappiness fosters the need for change and motivates every team member to think and reflect about improvements. The hard thing is to get the feeling for the right point in time for a change so that creativity for change does not turn into frustration.

By the way, I really like experiments. Experiments are the perfect instrument to develop a complex system – and every system is complex as soon as more than one person is part of the system. Experiments are small changes, tiny measures that are implemented fast. For a certain topic like the improvement of the portfolio process it is good to have a backlog of potential experiments. Then you apply an experiment. As it is small it is implemented fast. You get feedback very fast. Fallback is often possible in case the experiment fails as the change is small and the impact limited. Experiment by experiment you learn about the system and the number of successful experiments increases. Changes are small for all individuals involved and included in these changes. Ideal all individuals in the organization get used to that the system changes continuously. As most experiments succeed, all involved persons perceive change as something that delivers value. 

Well, back to my first experiment in my team. In the meeting itself – we explicitly took team ceremonies as the topic of our BD team meeting retro – the team expected some statements from the boss. Not too bad. I took the chance. But I did not present a solution. Instead I tried to summarize what problems in communication we obviously face and what goals are expected by the organization when introducing our ceremony culture. Additional I presented some alternatives and good practices out of my work experience that succeeded in other companies in similar context. I added some statements about further reading. Then I pleased my team to present their ideas how to organize our team culture.

Luckily my team took as well the chance. Especially Becki and Andi, the long term Digitec Galaxus employees, started to present their view based on their insights and experiences inside our company culture. For sure sharing my experience and ideas biased and influenced. I recognized this carefully. But this is positive. The influence is mutual. We as a team work on a common goal: to identify and agree upon an effective and efficient ceremony culture that satisfies the needs of our organization.

The result was ok, practicable, a good start. It was not the perfect solution. We all knew this. We agreed to start and to improve as soon as we learn more. Meanwhile we changed our team ceremonies by applying about five additional experiments. These improvements often are agreed upon at the end of a meeting. One team member raises its hand and starts: “By the way, I believe we could improve our meeting culture as following…”. Small experiments are agreed upon fast and implemented at once. If we are not able to agree we move the discussion to one of our BD team meetings.

Now, three months after my start I can say that this way of involving the team in all decisions is an essential step of team development. My personal experience and competence out of my professional life is welcome as part of the team and not perceived as “the expert overrules us”. We learned as well – following the delegation model presented in Jurgen Appelo’s book Management 3.0 – what decision are team decision on eye level and what decision are solely on my side as the head of, but still influenced on the important input and shared knowledge of my team.

Now, three months after my start I ran through the yearly performance process with each of my team members. I recognized and honored the open feedback that I got about what is good and what is not so good. But what I value most is that all of my team members agreed that it is fun to work in our team; that they are happy with their job and fully motivated to engage for  Digitec Galaxus. That again motivates me. We are working on a common goal.

Building up a team from scratch – the first steps

You enter the room. Five persons are curious looking at you. Two of them long term Digitec Galaxus employees assigned to the new built department called Business Development. Two of them new hires, one an experienced project manager, one a graduate from university. The fifth a trainee that will work for a trainee time of 6 months in my department. I am myself a new hire with only small knowledge about Digitec Galaxus history and culture.

I had been announced as expert in agile, lean, portfolio management. I had been announced as the one who will help to identify and establish the right way to work and define the portfolio and development processes; as the person that will improve the existing home grown agile way of working into something that enables the next step of growth, while preserving the flexible startup spirit of Digitec Galaxus.  I could feel the one and only one question in this room: “who are you and what will it be like to work with you as my new boss?”

Well it was not that easy this first meeting. In a first round we exchanged our expectations and experiences. Becki was asking for leadership and support as she was missing this for quite a while. Andi and Marcel wanted to develop themselves and act in interesting jobs. Martin, the experienced project manager demanded to take responsibility, Cornelia coming from university wanted to learn and start her carrier. We discussed values and identified our common ground. The common ground was trust – which we need to create – an interesting job with the chance to learn and build up competences, no micro management, open communication and self-organization, mutual respect. We discussed that self-organization and self-discipline are the two sides of the same coin. This common ground was a good place to start from. I marked my first task of my first backlog story – to find a good start as head of my new team – with done.

I knew that the hard part follows. To develop the common ground into a living entity, a team that represents, lives and develops the values that we identified as important.

What we did is to write down our team values on cards, one card per value. Becki proposed to select a random card for the value of the day every working day. Now the value of the day is visible in our team space on a wall and still is changes every day. Oh yes, meanwhile we added new cards. Some are fun like “homemade cookies” or “sleep ‘till noon” – even members from other team started to add cards, which is fun.

Our Team Value of the Day for today: a creative environment 

Meanwhile we introduced Kudo Cards (read the management workout from Jurgen Appelo). As most of us love coffee and the others at least drinks tea we started a regular but still spontaneous morning coffee where we share our weekend or discuss the most important issues in our team. We defined a team ceremony, our monthly BD team meeting for our team retrospectives and to define measures to develop ourselves. We found and agreed about some means and informal ceremonies that support us to build up trust and share experiences. I treat all of this as an important steps to form a motivated team. Let's see how everything develops...

Building up a portfolio management Kanban system – step 1

My blog “Herdingants – so many opportunities, where to start?” listed some of the “post migration” main problems Digitec Galaxus currently is facing. The need to prioritize the work aligned to strategic goals but still preserve the agile and flexible way of dealing with changes was given.

The problem of us was that our backlog contains far too many items. I counted over 1200 items on different abstraction and maturity levels, sizes and of different types (bugs, features, ideas, …). The overview got lost and with this the chance to select and prioritize.

Working on a white wall with sticky notes and a technique like story mapping was not establish in our company. So applying Jeff Patton’s story mapping technique for clustering, selecting the important stories, identifying a walking skeleton and getting rid of deprecated stories just was not possible. Working with white walls besides feeding a sprint was unknown at all. Teaching and coaching this is interesting and valuable. Unluckily that takes some time until the teams are enabled to apply this and produce an outcome. I put this technique into my backlog and moved it a bit down. We needed an approach that produced faster outcome.

Well, that sounds like some kind of implementation of an agile framework might fit, addressing the needs of a larger organization. I personally know and expertimented with elements out of the frameworks and approaches 

1. SAFe by Dean Leffingwell, 
2. LESS by Craig Larman, 
3. Evidence-Based Management for Software Organizations (previous called Agility Path). 
4. DAD by Scott Ambler. 

With the consulting mindset of my previous work the temptation was high to go for one of these framework and to implement it in some adoption following my intentions. I had a grass play area. Well - I decided different.

I reminded myself on the approach: create a vision about a direction to improve and apply a series of small experiments to move towards the vision. First step in this approach is to create a common vision. To do so you first need to know about the different visions that are around in the minds of the different people. I started with a workshop about “agile portfolio management” with a set of involved persons like the team lead for business analysis, the head of engineering, one of the CEO’s and some team members that already work on a first concept of a portfolio management and innovation process.

Of course the attendees of the workshop expected my again to present a ready-to-go solution that fits for us. I started presenting SAFe with the background not to implement SAFe as it is. I used the SAFe picture to present a potential vision and to point at some important mechanisms and techniques relevant for organizing things in an agile way for a larger organization. This started a positive discussion what the requirements and constraints of the different stakeholders in this room were. We were able to create a common vision and picture as following:

• We need to manage items on a higher abstraction level then user stories used in the product backlog of (software) engineering.
• Such an item (a project?) aligns to strategy and shall deliver an outcome that creates business value.
• We need to re-prioritize items fast in case of external events.
• No item shall block our system so that other items have to wait.
• We want to follow the lean idea to limit the number of items we work on in parallel. So to say we introduce a work in progress (WIP) limit for the items in progress.
• We want to manage all types of work in this system: work that ends up in implementation of software, conceptual work (for example a new concept to organize a core process), organizational work (for example re-organizations), and combinations of these work types.
• We need a transparency for everybody in Digitec Galaxus. As we are distributed over several location (logistics, retail shops, headquarter) a tool support is required. As we already use Atlassian Jira, it would be wise to go for a Jira implementation of whatever we do.
• We need to offer the departments the chance to implement tiny software related changes and improvements in a fast way.

The SAFe image for sure influenced. The idea to use three abstraction levels of requirements and a Kanban system around the highest abstraction level was convincing. So we agreed about the first experiment: Beside the two already as default in Jira built-in abstraction levels of user story and epic we create a third and more abstract issue type we called initiative.

That was a start - no we had the tasks to work different from tomorrow on.

Herding ants – so many opportunities, where to start?

Many new hires for a position with high visibility believe it is necessary to set a footprint right in the beginning. Reasons are: Expectation are high on the new hire, changes are welcome and expected – better yesterday then tomorrow. This results often in fast and wrong actions just to demonstrate power and deliver results – whatever the value of these results may be.

I decided to act differently. I took my time to walk through the departments, to talk CEO, heads and employees. I listened carefully to what my team is working on. I even worked some days in some departments, for example packing goods in the logistic or entering product date in product management. I am a strong believer that you have to understand the system, the processes and especially the persons working here and there before you start dancing with the system.

What I discovered was:

• Software development (called Engineering) is working Scrum alike. Some practices might be not that good as it could be (there is always room for improvement), but all the teams are living an overall healthy agile process based on one shared product backlog.
• The interface between software development and the functional departments is – hmmm – suboptimal. Very obvious the reason is the very hard migration phase where engineering, especially the business analysts in the engineering, set the pace. Departments felt somehow overruled by business analysts and business analyst felt left alone by everybody. A typical scenario in many companies.
•  Digitec Galaxus owns a real mission, vision and a clear strategy. It is short, easy to understand with clear and understandable goals. That was really surprising. Only a few companies I had the chance to work with own these essential communication elements on that level of maturity.
• Digitec Galaxus is working in a good, pragmatic and collaborative style and culture, tool supported on an Atlassian Confluence and Jira infrastructure. There are only very few documents on a shard folders. PowerPoint is treated a poisoning.
• A huge potential exists for innovative features, enhancements, potential improvements, and optimizations of suboptimal implementations of business processes. Problem is: There is no shared agreement of what is important and what to do next.
• With this I found a wild mixture of about 1200 open Jira issues of all different kind and sizes accumulated over the last eight months. Some of the issues are bugs, some enhancements, some are tiny things, and some are essential and large ideas. Some are firefighting rescue things to survive today, some are real innovations for our customers in the future. The huge number of items is a challenge for prioritization or comparison. That is success and malediction of open collaboration. Things get accumulated and then it is hard to find a way through the jungle.
• A first rough idea of a portfolio management Kanban system exists called innovation board. The idea of the innovation board is to list strategic projects.
• A first ideas of an innovation process exists (not to puzzle with the innovation board) that shall enable the functional departments to announce, prioritize and enroll improvements ideas. These improvement ideas shall end up as either local projects or as strategic projects in the innovation board – or as small change requests that can be realized fast and flexible.

Listening to my boss Florian (one of the Co-CEO’s) and all the other people I talked with, I received a strong request to build up a system that supports prioritization, focusing on the important things. A system with built-in flexibility that supports a fast growing company with more and more individuals working for a shared vision, the vision of Digitec Galaxus. 

This information base was a good fundament to start. I reminded myself on Deming, Kaizen and Jurgen Appelo. I decided to start where we are and to improve step by step with fast feedback following plan-do-check-act circles. I designed my personal change backlog for my responsibility at Digitec Galaxus as following:

1. (story): As the head of Business Development (my official position) I want to empower my team so that we develop competence and are a highly motivated team in its responsibility to drive the agile portfolio. Acceptance criteria are trust, self-organization in the team and the motivation to change the organization following a Kaizen approach.
2. (story): As CEO of Digitec Galaxus (my boss) I want a transparent, flexible und lightweight system, so that all my teams work on the projects that generate the highest outcome and get things done. Acceptance criteria are that the existing innovation board is improved and changed into a system that supports the executive team in prioritization and implementation of strategic projects; that the innovative slow down caused by the migration is turned into an alive innovation factory again as fast as possible.
3. (story) As a department I want to know that innovative ideas based on the customer demand and optimization ideas based on internal productivity demands do have a chance to get realized in some way and somehow. Acceptance criteria are to work with an easy to apply and transparent system where a department can place, develop and realize its ideas; to get fast feedback and support in the realization of ideas; to get the chance that fast, small and urgent changes run fast through the system creating impact as soon as possible.
4. …

Reasons I prioritized my change backlog in this order was the strong believe that I cannot succeed without a strong team. My team and my department was setup totally new as result of a re-organization including three new hires (included myself) and one trainee. Some of the ideas around the Kanban portfolio process and an innovation process are concepts of team members in my team. My team matters. My team always matters. Yes, I set the strong demand of my boss on second priority. I was convinced – and this proved to be a good decision – that the start phase of my boss’ story might be slower in that way, but sustainability and overall speed are ways better with a strong team driving instead with my person acting as an expert and lonely wolf pushing things forward.

In one of my first weekly’s with Florian (what an opportunity to have the chance for a weekly with the CEO) I challenged this backlog with him. For sure we discussed this and that. We agreed upon and added potential following stories in my backlog. But with a self-defined WIP (work in progress) limit we agreed upon these stories as the most important ones.

What I put aside at that time was the interface between the departments and engineering; the stack overflow of 1200 issues in the Jira engineering backlog. I had the strong feeling that on one hand things will change as soon as learned more about us and invisible things get visible and on the other hand that I need to know more about us before we start to experiment in this area.

So my first plan-do-check-act circle was ready to start.