Lean PPM - step 15: Prioritization on strategic level at Digitec Galaxus AG - the starting point

(see this blog as well on my new homepage under http://tinyurl.com/zkcjw3r) 

There are many blogs about prioritization. Most of them criticize the typical current state in prioritization: The loudest voice in the room or the HIPPO (highest paid person in organization) wins the emotional fight for resources and budget (annotation: in this case I do not write “her”, playing the voice and HIPPO game is more a man’s world).  Some blogs give positive advice: prioritization based on business value and cost of delay. Unluckily most of them leave you alone when it comes to the interesting point: What is business value!?

Our starting situation in prioritization

When we introduced our Kanban System of initiatives at Digitec Galaxus AG we knew that we have to (should, strive to, …) prioritize on a strategic level. We knew that we had to find some means to structure the discussion about priority of the initiatives in our strategic Kanban board. As in other companies an often heard argument in discussion was: “I have the strong feeling that we urgently shall do A”.

Although in general the discussion in this round are positive and constructive – I personally had a bad feeling in these discussions because of the following issues:

• Prioritization often took place on comparison of two initiatives against each other. That might work for comparable initiatives. It is a lot harder if one initiatives implement an innovative customer feature and the other initiatives addresses cost savings through automation. In this case a one by one comparison fails. In this case a strategic alignment is required for decision.
• Arguments in discussion very often addressed what we gain, if we do X. Outcome of this type of discussion is typically that we see a gain in many things – in too many things. This leads into the trap to overload the truck, to neglect WIP limits and to start too many things in parallel.
• Very seldom we discussed what we will stop or shall explicitly delay and what we loose if we stop or delay a specific initiative. In my perception this is the most important discussion that has to take place on a strategic level: What to stop, not to start, where to focus consequently.

Additional I discovered that the decisions taken in the Innovation Board Meeting lead to substantial subsequent discussions in the teams involved in the development process – from functional departments to engineering throughout all participating persons representing all types of roles. This is a very important finding. The reason for these discussions I encounter in a communication gap between the Innovation Board members and the teams carrying out the decisions. Teams implementing the strategy require more information and background about priority decisions then just “the executive team decided A is more important than B”. The “Why” is as important as the decision itself.

To summarize our current state:

1. The discussion about priority missed concrete arguments. Arguments are more emotional than fact based.
2. The attendees (our executive team) try to push too much work into the system. Reason is that there is a value in every single initiative. So it is hard to say NO if there are no facts beside emotional arguments. This “push” factor must be eliminated.
3. Acceptance of the outcome of prioritization need to be improved. The information gap between the decision board and the development teams ended in many subsequent discussions. The communication and transparency of decision down to all involved persons need to be improved.

At this point we decided to improve the prioritization mechanism used for our initiatives representing the most abstract level of items in our strategic portfolio.

The Digitec Galaxus basics of prioritization

As starting point, we consulted different concepts of prioritization beginning with classical approaches like the requirements prioritization matrix by Wiegers (see http://www.processimpact.com/articles/prioritizing.html) to modern approaches following the cost of delay approach and weighted shortest job first idea from Reinersten (The Principles of Product Development Flow; Donald G. Reinersten; ISBN-13: 978-1935401001, http://www.leanproductflow.com/) as used in the scaled agile framework SAFe.

We decided to follow the weighted shortest job first (WSJF) approach adapted to the needs of Digitec Galaxus. We see this approach as the optimal approach for a company competing based on market driven requirements in the fast growing customer focused e-commerce market. What convinced us to base on WSJF was the “what do we loose if we do not implement X” mindset. This mindset leads to a real business value driven perspective in prioritization and to positive and fruitful discussions about what business value really is. To remind you on the theory behind WSJF, here is the principle:

Image 1: Weighted Shortest Job First (WSJF) concept

The image shows a very simple principle: Calculate the delay costs for X over time, if you do NOT change the status of X. Examples for delay costs are missed profit, running maintenance costs, even lost reputation on the market or whatever you treat as costs of delay.

Then prioritize all items based on the WSJF value as WSJF = cost of delay / time. If you as organization decide to always pull the item X first with the highest WSJF factor, you maximize the benefit for your organization because you minimize the delay costs. Or in other words: You decide NOT to development items that have a lower negative impact on your profit than the ones with the highest WSJF factor.

SAFe as well gives advice to calculate cost of delay as following:

• Cost of Delay = Business Value + Time Criticality Factor + Risk Reduction – Opportunity Enablement

This formula is hard stuff. No matter what organization you look at, at least the two factors “business value” and “opportunity enablement” are as transparent as a massive wall of bricks.

Nevertheless, we decided to go into this direction. Point is that any other theory about prioritization finally comes to the very same discussion: how to define business value. To be more precise, we decided to define all influencing factors on the right side of the cost of delay formula under the context of Digitec Galaxus.

See my next blog for the concrete discussion of the Cost of Delay factors Business Value, Time Criticality Factor, Risk Reduction and Opportunity Enablement.

Summary

I want to summarize the findings in this blog

• In many organizations the HIPPO or loudest voice prioritization is applied. Reason is the lack of a transparent, easy to understand and use prioritization system of items in a strategic portfolio.
• Even HIPPO or loudest voice prioritization may end in good results. The next problem then is to communicate these decisions to the teams that carry out the impact of prioritization. A HIPPO or loudest voice prioritization is nearly impossible to communicate. Distracting discussions and inefficiency in executing are the result of missing communication.
• Instead of comparing items based on the mindest “what item does generate the higher profit”, prioritization must be based on the mindset “What item does generate the highest cost if we delay the implementation”. This approach at is a good start at least for all companies competing in market driven environments.
• To quantify Cost of Delay is not easy as the factor Business Value, Time Criticality Factor, Risk Reduction and Opportunity Enablement are subject of hard discussions. To define a (for everybody) transparent, easy to understand and use definition for these factor is crucial for a Cost of Delay prioritization.

Lean PPM – step 13: Documentation consumer type 3: SW engineers, subject matter experts, technical experts

SW (SoftWare) engineers and experts do not have an interest in documentation. SW engineers as well as experts have an interest in the final solution, especially in a solution that fulfils the needs of the business or users. Unluckily many organizations prevent successfully that SW engineers communicate with the subject matter experts. That’s exactly what agile and lean processes try to address – to tear down communication barriers to the minimum.

SW engineers working in software development have an elaborated set of documentation means built in into Scrum. Epics, user stories, source code, acceptance tests, prototypes, a technical environment support the design, implementation, build, test and deploy cycle with versioning and release management (at least hopefully – if not, well you know now where you have aspects to improve. To be straight – this is where we at digitec Galaxus as well do have room for improvement).

Subject matter experts (example: actuaries in reinsurances), technical experts (example: hearing experts in the development of hearing devices) all have very special tools and environments. Actuaries often use Excel. I have seen monstrous solutions built from man dependent Excel workbooks driving business critical risk management solutions implemented by actuaries in reinsurances. Nobody else except the creator understood these complicate solutions. I once had the job to migrate such a solution into a scaling Java solution – what a nightmare. The most important individuals in this project were Prolbares (see above) that translated the requirements of the actuaries, hidden in the Excel beast, into something executive managers (“why is it so expensive to rewrite an Excel worksheet in Java??!!”) and SW engineers (“as a reinsurance key accountant I want to …”) understood.

Point is: Between SW engineers and experts (and managers) there is a distance that Prolbares try to reduce or even to eliminate - with distance defined as well as physical distance as mindset distance. In true agile environments elimination is the aspired state. What is important in respect of documentation: SW engineers and experts both have their specific way to deal with documentation.

With this requirements of SW engineers and experts for documentation are:

• The very specific type of work requires the support by very specific processes and tools (Excel for actuaries; epics, user stories, acceptance tests, source code and a build/deploy environment for SW engineers).
• The least amount of documentation is the best – no matter of the documentation is required as information source to start my work or as information sink required by anybody else in the organization.
• SW engineers and experts are not interested in documentation. They are interested to get their job done and to create results and to deliver.

Maybe I am a bit hard to list only these three requirements – but I am not unhappy with these interests of SW engineers and experts. I am always happy if people have an interest to deliver. It is the responsibility of the (leadership part of the) management that SW engineers and experts want to deliver something the organization benefits from.

Lean PPM – step 12: Documentation consumer type 2: project leads, business analysts, (requirements and software) engineers, or likewise folks

Prolbares (= project leads, business analyst and requirements engineers) express a lot more needs in documentation. Prolbares are around on all abstraction levels of requirements (see the requirements abstraction model RAM by Tony Gorschek and Claas Wohlin). Prolbares work from business goals, high level business processes down to tiny technical details. Prolbares are involved in the full lifecycle of designing and implementing desired changes (see “The life cycle of an initiative”). In the design process of a change they are responsible to elicitate, design, communicate, consolidate and confirm requirements of a change. In this context “change” is anything from a small continuous improvement in an existing system to a discontinuous innovation in form of a new product or service.

In respect if documentation, Prolbares are like chameleons. Some like to write novels, some hate writing any documentation, some like modeling, some prefer to paint pictures; some are more user experience oriented, some rather are technicians; some feel comfortable on the abstract levels of requirements like business goals, processes and features, some love tiny details…

Naturally the requirements of Prolbares for documentation are magnifold:

• In the initial part of the lifecycle of a change they have an interest about the current situation. Source code and acceptance tests are a good source of the current state of a piece of software – but unluckily, as mentioned in my last blog – this is often only part of the truth. Manual and organizational procedures do not have a source code. Documentation could be treated as the source code of a manual and organizational procedure.
• Prolbares consume and create many artifacts and share these with her team(s) like meeting notes, requirements specifications, prototypes, decisions, technical description, whatever is needed in the refinement of intiatives, epics and user stories.  Most of this is waste when the change is done. Most of it, but not all. Some pieces out of this huge amount of information is valuable for the first step – to remind on the current situation any time in the future when the next change is in the road.
• Because of the chameleon alike nature, finding anything that suits all Prolbares is like finding the holy grail. So we had to find options that satisfy the majority of the Prolbares.

Prolbares are hard to place within an organization. Reason is that Prolbares typically are not full time members in any team. If integrated into the IT organization (i.e. Scrum teams) they spent 50% of their time with stakeholders and business. If integrated into business, they spent 50% of their time with IT, and – if not – they loose contact to IT, what results in defects in the quality of requirements (conversation, confirmation, feedback loops). At digitec Galaxus business analysts are our Product Owners in the Scrum teams. 

If Prolbares act positive in an organization, they care for the whole (optimizing the system and not preferring a specific department). They act as mediator, moderator, translator between business and IT to balance needs and wishes. They support ideas to become visible; mature ideas into change projects and finally towards real implemented (continuous or discontinuous) innovations together with all involved departments, subject matter experts, external partners, management and whoever has stakes in the change.

This is the reason Prolbares typically have an interest on a higher amount of documentation than all other involved persons and job profiles in an organization. A good Prolbare want to understand the problem under discussion herself. So the write a part of the documentation for themselves. Then they use documented requirements to solve different views and conflicts between stakeholders in the design phase of a change project. Additional they try to create a documentation that best suites all stakeholder in documentation (from executive managers to engineers and technical experts). 

Unluckily often the documentation policies, structures and tools in an organization are not defined in a way to support Prolbares to ease their job. The results we encounter in many organizations. To many documentation; documentation that does not satisfy the needs of consumers; documentation that does not allow to search and find the requested piece of information to successfully work on a piece of work.

In my personal perception to identify an appropriate structure and tool support for this relevant part of documentation is the most critical point. In fact this is the part to support the activities of business analysis, requirements engineering and design in respect of the creation of required documentation. 

Lean PPM – step 11: Documentation consumer type 1: executive managers

Executive managers do not have a lot of time.  They are keen people…

I am sorry to break your flow of reading at this point for a short discussion about executive managers, middle management and systems that doom people to stagnation.

---Discussion about executive managers and locking systems

In my experience over the last 30 years, in most cases executive managers are really excellent people. “Indifferent” managers are mainly locked in the middle management – but not because the individuals are inaptly. Rather middle management is doomed by the system to work in an indifferent way. To change the system, I personally see under the responsibility of executive management. This is where I set my question mark. Maybe executive managers are doomed by the system as well. I encounter a real difference whether executive managers or owners are in the driver seat of an organization. Maybe managers better fulfil quarterly financial reports to satisfy shareholders. I personally encounter that shareholder profit in owner driven organizations is not that high as in manager driven ones, but in the long-term these organizations are more robust, show a sustainable growth, more creativity and innovation and you find a higher ratio of intrinsic motivates employees.

---End of discussion - back to the documentation thread

Executive managers read one page. Executive managers want to see things to progress or the reason why things get stuck. Executive managers take decisions and have an interest to receive appropriate information to take a decision. Executive managers have an interest to reach goals; in the big picture; in the change roadmap; in the alignment of the change roadmap with strategy; in financial factors. Executive managers lose interest very fast if they feel wasting their time. Sometime executive managers have an interest on tiny details – but in this case no documentation helps. In this case an executive manager best is informed face by face by a competent person.

So the requirements of executive managers regarding documentation are:

• Easy to find – best presented in a personal and (automatically) daily used dashboard.
• One Page information (scrolling is waste of time and inadequate).
• Executive managers pull information - except something might fail. In this case an executive manager expects a push about a potential failure so that she can take preventive actions.
• Executive managers do not like unpredictable negative incidents. 
• For sure executive manager like unpredictable success messages.
• As a subject matter experts: You can be sure that an executive manager has never read the detailed report about risks or delays until the issues bubbles up because of some accident
• Executive managers want to see the name of the competent person behind a project/issue/action in case she requires a face2face to receive tiny details (in case of an accident)

There is on important fact to remind: Executive managers typically are no team members. They represent the culture and visionary capital of the organization and own the additional responsibility of a catalyst: if a catalyst works well, the organization works clean and powerful; if a catalyst fails, the organizations state of health drops. Because of this face2face information is far more important as documentation. Documentation rather is used as form of reporting to detect devations from the expected path. The real communication for steering should be done personally in 1:1 or other forms of direct communication. It is a matter of interpretation, shared knowledge and trust.

At least this is my experience aligned with the following principle in the agile manifesto: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. And the head of the development team of a company is the executive management.

Lean PPM step 9: Working Software over Comprehensive Documentation

I promised to talk about documentation - quite a while ago, I know - sorry...

Documentation is a very special topics to talk about. I discovered, I have to write more than one blog to cover this topis at least a bit. so lets start:

Just to remember – in 2001 a group of agile individuals phrased the agile manifesto and the twelve principles of agile software that are relevant as ever. With respect of this blog discussion about documentation in our agile & lean world I would like to repeat the interesting statements.

Agile Manifesto

• Working software over comprehensive documentation

Twelve Principles of Agile Software

• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Business people and developers must work together daily throughout the project.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Simplicity--the art of maximizing the amount of work not done--is essential.

Just to point out: The other statements are as relevant. This subset is chosen in respect of the discussion in this blog.

In an agile & lean organization a core attribute is the continuous flow of development and improvement. An important impact is that many things are “in progress” at different level of maturity. As well many things are “done” and in operative use, like a deployed feature in our online-shop or erp-system.

This is where documentation comes into place. Core questions are: Who needs a documentation? What is the benefit of a documentation? To answer these questions, I present some typical scenarios out of our company

Scenario 1: The checkout process requires a change because of a new feature

Imagine we want to add a new feature like a new delivery option in our online-shop checkout process. The checkout process is a complex business process with many scenarios, dependencies, decisions and business rules behind. The working software unluckily is not a sufficient information source to change this complex process. To remind ourselves on all the decisions, business rules and compliance regulations is important before we change this process. As business people from all departments have stakes in this process (accounting, logistics, product management) source code is for sure the only truth of what is implemented, but for sure not best suited for the business people. So there is a need for some form of documentation beside the source code. Let’s phrase his need as a user story: “As a business reader I want to remind myself based on an easy to search, read and understand documentation what we decided that last time we worked on the checkout process.” Additional, as soon as the new checkout process is implemented the delivery process is changed as well leading to changes in operational process in logistics. This requires that we rollout the operational changes and educate our staff members in logistics how to deal with the new process. Therefore, we need some documentation as well.

Scenario 2: We want to rewrite the ranking algorithm of our products

Imagine we discovered that the ranking of products in our online-shop does not meet the expectations of you as a user searching for products. Ranking of products is a complicated (not a complex) algorithm. Many influencing factors determine the rank of a product. You might imagine some of them like: number of visits, numbers of sales in total, number of sales during a certain period, number of recommendations of customers who bought an article of this product…and some more factors. All these factor go into an algorithm. You can imagine that this algorithm is as complicated and secret as the ranking algorithm of Google in their search engine. In fact is kind of a similar problem. To nail this algorithm done more than one session with the right person on board (head marketing, head engineering, product managers, software engineers, …) is necessary. The outcome of these meetings in the end is kind of a decision table that lists the factors and the weight and influence of each factor in the algorithm. An excel table would fit – but unluckily you cannot discuss on base of an Excel table with a product manager for toys or living accessoires. To summarize: The user story to implement might be easy: As a user I want the products in the online-shop ranked in a way so that I find interesting offerings fast and at top on first view. The requiremrent engineering process to elicitate and specify the algorithm needs documentation in some form – as preparation, as discussion base, as outcome for implementation and test (algorithm, acceptance criteria, test data, …).  And at the time this new algorithm is implemented maybe we want to change it in six months again. Then scenario 1 comes into play.

I hope these two scenarios give you an insight why even in agile development documentation beside the source code is required in some form. Still we all are convinced that the best documentation is the one never written and we try to share information as far as possible by direct face to face communication. We encountered that this is unluckily not sufficient. So we strive to create just that minimum amount of documentation for readers and target groups that is sufficient to follow a sustainable path of development and improvement in our documentation.

Let’s see in some additional blogs what our idea about an agile documentation is – at least what we hope will meet our needs and deliver benefit. We are still on the road to establish a good agile documentation; we already found some good techniques and tools, but we still have lots of room for improvement.

Lean PPM step 8: about project leads and business analysts...

In some of blogs I mentioned that our organization knows the job position of project lead and business analyst. Especially the job position of a project lead may sound strange in a lean and agile organization without projects. Actually we never discussed these names, we just reused job position names that were around. The names existed when I joined Digitec Galaxus. Nevertheless names for job positions matter. The reason is that everybody in an organization assigns a set of responsibilities with these names. Everybody knows what to expect from a person acting in the job position of X.

Unluckily job position names can as well lead to misunderstandings. In my experience only a part of the persons in an organization are able to distinct between a job position and a role. This sometime puzzles persons if two persons with different job titles act in the same role, for example in the role of a business analyst. In our organization for example persons in the job positions business analyst, project lead, erp specialist and software engineer are regularly acting in this role. And it does not help that the name of the job position is identical to the role name. A typical question is “What, now a project leads does some part of the business analysis, I thought this is done by our business analysts?!” The more interesting point is: where is the difference, what are the responsibilities that are unique to a job position. You have to communicate rather these “unique owned” responsibilities within your organization. This fosters persons to discover the responsibilities of a job position and to receive support fast in case they have a request for this special responsibility.

Now, to discuss the job positions of project lead and business analyst it is interesting to look at the roles and responsibilities of the job positions. What is the common set and what are the “unique owned” responsibilities.

Just to remind to our SAFe like system working with initiatives and fastlane. Initiatives implement desired changes derived from our strategy or based on a demand coming from a department. Larger changes, like building up a new logistic center, introducing a standard software for X are decomposed into a set of initiatives and called a theme. Small software system related changes go through the fastlane channel from departments to engineering. Every department owns its own Kanban board managing its own changes and demand and there is one single organization wide Kanban board holding the initiatives (in SAFe called business and architectural epics).

Now, let’s see what the “unique owned” responsibilities of project leads and business analysts are. And just a word regarding “unique owned”. Our interpretation of owned is that this team of persons in the job position of X care to develop the responsibility in collaboration and communication with the rest of the organization that is involved in these activities. There is no “shut up – that’s the way to do it”. It is rather the way of “this is our recommended proposal for a standard method, technique, procedure or process. A common agreed and accepted standard proceeding will help us to be more effective and efficient. Let’s try to do it this way. In case we can improve it, based on our feedback, we will do so. Please give us feedback”. In the change process of our methodologies we established as well an experiment, inspect and adapt process. Luckily this is welcome and accepted by the majority of persons.

The core responsibilities of a business analyst are:

• Business analysts are the experts for our business processes – best in an end2end view. Together with the subject matter experts (we call them erp specialists, erp stands for our self-developed “enterprise resource planning” system) they take the responsibility to identify, develop and optimize the business processes.
• Business analysts help the departments to improve in alignment with other departments – as a business process typically crosses more than one department. They help the departments to develop ideas for improvements and mature these ideas into initiatives and fastlane issues. 
• In the context of initiatives they support the development of the user stories in collaboration with software engineers, usability experts and with the users working with a new process or a new system. They act in the responsibility of a Scrum product owner for the Scrum teams. In this context they work very close with project leads on definition of goals for initiatives and the measures to reach these goals. This collaboration is part of the alignment between initiatives and product backlogs of the Scrum teams.
• Business analysts care for that changes flow back into the organization. They take the responsibility of end2end tests together with the departments, with engineering and with project leads. Business analysts are an essential part in quality assurance of our business processes and systems.
• Business analysts are responsible for the way we build up an appropriate documentation of our business processes (the business process management process J). We just decided to document our business processes with BPMN. As our systems, processes and the number of involved persons increased over the time (and still are increasing) we have the need for a lean, easy to understand, read and to maintain BPMN documentation. Documentation is worth another blog… J.

The core responsibilities of project leads are:

• The innovation process, i.e. the way departments work with their Kanban system developing ideas for initiatives and fastlane issues. Project leads support the departments as (innovation) process coach.
• The portfolio management process around initiatives including definition what an initiatives represents, how to manage and document an initiative within our supporting software systems like Atlassian Jira and Confluence.
• Project leads overall are responsible to drive the implementation of our strategy working with and developing our roadmap. They care for and remind that initiatives are developed, the breakdown of themes into initiatives, that decision are prepared and taken by the executive team. They ongoing develop the roadmap together with the executive team.
• Together with business analysts, project leads they care for lean goals of initiatives and the identification of measures to reach the goals of initiatives. We try to treat every single initiative as a MVP (minimal viable product) to reach the goals of the initiative. They care for that a review is done in the closure of an initiative against the goals. They care for that learnings flow back into the organization, whatever learning that may be.
• Project leads are responsible to collect the information and feedback from all participants in the demand – capacity game, so that the overall system is not overloaded and the system is balanced and healthy. This includes the preparation and proposals for prioritization of initiatives for the innovation board meetings.

And finally what is common to project leads and business analysts:

• The task of business analysis and requirements engineering is shared. All business analysts and project lead know our business processes very well. This sharing lead to some discussion until we found our common understanding (at least I believe by now we found an agreement as the discussions went down and we have a lot of coffee and fun together). In general business analysts may have a bit a more detailed functional knowledge and project leads care a bit more for the inter-department and roadmap-alignment side of business analysis. But for some initiatives a business analyst may be in the lead, fulfilling everything a project lead does; in some initiatives a project lead does nearly all of the business analysis. But this is OK and accepted.
• We both work with departments to develop new ideas for initiatives and fastlane issues. While projects leads take more the role of a (innovation) process coach and support the departments to life and adapt the process to the special needs of the department without leaving agreed common mechanisms like the two demand channels fastlane and initiative, business analyst support more on the business process side to develop and improve the business processes. But as well persons in both job positions are able to act vice versa.
• Many skills and experiences are shared in our teams. This is the lean and agile way of project management, business analysis, requirements engineering, acceptance testing, stakeholder management – many disciplines you may find in a project management, business analysis or requirements engineering book. We even share our training and education events and care for that we improve our skills on a common ground.

Reading these three bullet lists you may now ask yourself why we distinct the job positions project lead and business analyst. To be frank: This is a historical reason and the status quo is satisfying and currently works for us. 

Other solutions to implement a working system are possible. For example Craig Larman and Bass Vode in their LeSS framework recommend to establish groups of competences, i.e. the testing group or the architecture group. These groups are not organizational groups, these are members of (organizational) teams that share a common competence. Jurgen Appelo comes up with a similar proposal he names guilds. A guild is a group of persons that share competences and skills and develop these competences and skills for the benefit of the organization. 

We at Digitec Galaxus have a mixture. We have “guilds” for example the erp (= enterprise resource planning system) guild or the architecture guild. For business analysis and project leads we have teams as part of the organization. Both mechanisms have the goal to develop competences and skills. Potentially we could as well integrate project leads and business analysts into the other organizational units, but why should we. It would only be a re-organization. 

As the current system is understood by everybody and there is currently no need for a change, we leave it as it is. Re-organizations are always something people are a bit afraid of, because personal threads and fears pop up with re-organizations. Maybe any time in the future we discover that this construct can be improved for some reasons. Well, then we will change it. Maybe any time in the future our organization is that flexible and transparent to every single employee that re-organization rather carries the attributes of new chances and interesting new responsibilities instead of threads and fears.

Lean PPM step 7: The relevance of slack time

Then there is slack time. Engineering explicitly owns 20% of their capacity for themselves. I am personally convinced that every person, every department and every company works on a sustainable path only if slack time is available. A slack time mechanism is the heart for creativity, innovation and continuous improvement. Like a TCP/IP bus system is working only if its capacity consumption is below a certain level with a performance break down if this capacity is exceeded, individuals and teams show a similar behavior. Above a certain level of work assignment – no matter if this assignment is done by the organization of by the individual herself – the productivity of the individual drops. The differences between a TCP/IP bus and a person are that

• The TCP/IP bus shows this behavior at once. A person shows this behavior with a delay whereas the delay is individual. There are some persons on the world that do not show this behavior, but these are really rare. Unluckily these individuals often act as template for the average.
• For most type of work – especially skill work – it is hard to measure productivity. So you never know whether productivity really drops. One reason is that it is hard to define productivity, even when managers believe there is measure based on hard facts to calculate productivity. That’s the reason hours working time often are used as equivalent for productivity. Luckily new management models follow stretched goal definitions and team goals instead individual goals to overcome this old management school disasters.

On the other hand to much slack time has a negative impact, even worse if there is no self-motivation how to invest slack time in a positive way. This is called the student syndrome. It is the responsibility of the management to identify the right amount and type of slack time – even for every single department in a different way – and to build up a self-motivation mind set so that slack time is invested into anything the organization benefits from.

For our engineering we are simple and straight. To prevent that initiatives and fastlane result in a 100% capacity consumption we simply defined an average 20% of the overall capacity as slack time. There is only one constraint: show stopper bugs are fixed eating up slack time. This creates as well a mind set to avoid show stopper bugs.

To discuss the statement “the right amount and type of slack time” a bit more: there are many different ways to implement slack time. Through the software community crawls the Google mechanism of the free fifth day. I personally never worked for Google, so I cannot say if this is a myth or reality – but this would be a way to implement slack time. In my previous company, Zühlke Engineering, slack time was implemented as 20 days education time every year for every single person with clear rules how to invest this time. Keen managers just care for slack time in their teams and care for a self-motivated mind set. You see, there are many different ways to implement slack time. The important fact is to implement it. Classical managers treat slack time as a thread, as unproductive. There is a general believe in classical management that pushing work into a team or onto an individual will increase productivity. I personally made better experiences with means like communicating a convincing vision, identifying mid-term stretch goals, establishing clear, understood and supported rules and constraints and the creation of a transparent and motivating culture. For sure that is the harder path to go for a manager.

But back to our engineering team and the implementation of slack time there. The reason we decided to implement slack time as 20% of engineering capacity is: engineering, estimating all work as user stories using story points, is very transparent. Engineering estimates even slack time as user stories, so it is transparent to everybody how engineering invests slack time. Other departments are just not that transparent and do not offer this easy mechanism. So this type of implementation is easy and a clear and visible protection for engineering against overload.

As we manage all user stories in Atlassian Jira, it is very easy to visualize the capacity consumption of engineering in a statistic. User stories carry attributes to produce different types of interesting statistics. Following is an example for the statistics over a set of sprints.

Engineering Capacitiy Consumption

There are two interesting questions related to slack time: 1. How does engineering invest slack time and 2. What about 3^rd level support activities and bug fixing for bugs that are not show stopper bugs.

The first question is easy to answer. The sprint backlogs make transparent how slack time is invested. The stories are marked as “engineering” stories. Most of these stories is invest into refactoring and improvements of the system. Some are research stories to experiment with new technology, for example to speed up product search or user interface experience. There are some fun stuff stories as well – but that is where the motivation comes from. This is what I mean with self-motivated. As our strategy is visible and communicated down to every engineer, the Scrum teams identify self-motivated what improves our system and care for.

For the second question, how we manage 3^rd level support and bugs of medium or low priority (class 2 and 3 bugs), we found a very straight answer as well. Nevertheless the way to this answer required quite a lot of discussion and communication because it sounds strange in the first impression.

We decided to move everything (class 2 and 3 bugs, 3^rd level support issues, whatever) as issues back into the department board. It is the responsibility of a department to decide what the next most important thing to do shall be. The mechanism is clear: either it will be a fastlane issue or an initiative for a larger change. If there are many class 2 or 3 bugs that fill the fastlane, this is a learning as well. In fact it does not matter if the bug is because of a false specification or a false implementation. The distinction between “wrong spec” or “wrong implementation” fosters only a finger pointing culture between departments and engineering. That was a long discussed topic: is it really required to know who is responsible for a bug.

We rather decided to treat many small bugs as a sign that the collaboration between department and engineering needs to be improved. Our Scrum implementation addresses this in reviews and retrospectives – and additional in form of review sessions related to the closure of initiatives. It felt strange to many of us just to give back bugs into the departments. Now we can say that this heavily discussed way to deal with class 2 and 3 bugs and 3^rd level support is accepted and treated as simple and successful. Simple solutions are always welcome at Digitec Galaxus. 

Lean PPM step 6: more details on the demand

My last blog discussed the demand capacity game on a coarse grained level based on initiatives in our Kanban board. Initiatives with clear business goals are decomposed ongoing by the teams into epics and backlog items and implemented by the teams.

Pure organizational epics (without software development) are implemented by the functional departments, software is developed by the Scrum teams and all these activities within an initiative are coordinated by a person in the role of a project lead.

That reminds me to write an additional blog about the difference between a business analyst role and a project lead role – and the difference of the position of a business analyst and the position of a project lead; and for sure why we still use the role project lead. These differences and options of misunderstanding lead to many discussion at Digitec Galaxus – and in other companies as well. One reason for this is that an agile company does not know the position of a project lead. We established this position for some reason – but let’s wait until I write this blog.

But back to the demand capacity game. So far it looks like the Scrum teams work only on stories that result in decomposition of initiatives into epics and stories. We at Digitec Galaxus discovered at once that this does not work – at least for us. There is additional demand coming into the Scrum teams. One type of demand is fixing show stopper bugs at once. Another type of demand are small enhancements in any of our software systems requested by functional departments that would increase productivity fast with small effort. An example is the change of a default value in a dropdown, so our users save two clicks several hundreds of time a day. Using initiatives for this type of demand would be the hell of bureaucracy.

So demand flowing into engineering has additional input queues beside the queues represented by the initiative Kanban board. We discussed this and experimented a bit with a very simple solution addressing the input queues for work into engineering. The decision may sound scary for classical management, but luckily our management agreed to experiment. With some small correction the solution works good and found high overall acceptance in the functional departments, in engineering and by the executive management.

The solution is as simple as this: From 100% capacity of the engineering team, 60% are invested into initiatives, 20% are invested into fastlane items coming from functional departments and (!) 20% of the capacity is slack time.

Some explanations to these input queues:

• The demand coming from initiatives is explained in my previous blog Lean PPM step 5: The demand – capacity game at Digitec /Galaxus. So read this blog to understand the mechanism.
• Fastlane is an interesting mechanism to open functional departments a very lightweight, well defined but clearly throttled queue into engineering. All departments have the right to move items in this one queue. I will discuss the constraints on this queue in the following.
• The most interesting mechanism: Slack time. Engineering decides completely autonomous about slack time consumption – with the one and only restriction: Show stopper bugs have to be fixed in slack time. This is a very keen mechanism to minimize the number of show stopper bugs. Show stopper bugs reduce the free slack time of engineering.

Let’s dive a little bit deeper into the fastlane and the slack time mechanism. First I present the fastlane queue.

I mentioned the fastlane mechanism already in my blog “The life cycle of an initiative – step 4”. Every functional department in our company owns a Kanban board to manage and work on their ideas. Everything that can be done within the department itself moves on this board from status “new” over “in progress” to “done”. The large things turn into initiatives and move to the status “idea approval required” to receive an OK or a declined from the innovation board. And there is a status we called “for engineering”. This lane represents the fastlane. In case the department encounters that an idea requires engineering to implement a small change, this item is moved into the “for engineering” fastlane. The fastlane for sure is prioritized as well. The most important small changes are on top.

As every department owns its own fastlane, you can clearly see a new problem: All fastlane issues from all departments compete for the 20% fastlane capacity of engineering. The question is: which issue to take from which department?! As we have seven departments, at every time seven issues are of top priority. We solved this problem as many problems should be solved: by a. a positive communication and b. by a clear assignment for a decision in case the positive communication does not end in a solution within a limited period of time. The communication partners are the subject matter experts of the departments (there is a subject matter expert in every department) together with the business analysts. The decision is assigned to the business analysts. In case the business analysts are not able to find an agreement (what did not happen so far) the head of business analysis takes the final decision.

In average we encounter that our Scrum teams are able to implement about eight to ten fastlane issues per sprint. So actually nobody has a real reason to be unhappy. On the other hand the positive communication between subject matter experts and business analysts creates a transparency about the needs of the departments. This results in a mutual understanding of the needs of departments. And yes, once – what a positive surprise – a department said “well we see, our need is not that important. It is obvious if we implement the need of the accounting first. That will end in a larger benefit for all of us”.

Interesting is for sure the discussion about slack time. Read my next blog for dis discussion.

Lean PPM step 5: The demand – capacity game at Digitec /Galaxus

In this blog I talk about the challenging task of the demand – capacity balance in PPM, or the problem of who works on what and do we have the required and capable staff members available at the right point in time. This is an omnipresent problem. We never have the perfect capacity to satisfy the current demand. So we have either too many resources or a bottleneck anywhere in our organization.

In classical PPM the balance is addressed by breaking down the work to resource level (work breakdown structure) in a first step and then – based on an effort estimation – the assignment of work to resources. The uncertainty that corrupts upfront planning are estimations based on assumptions instead of historical data and the effect of risks that materialize in the course of the projects.

The lean and agile PPM approach is not to break down all (!) the work right from beginning, i.e. avoiding big upfront decompositions and specification. Instead decomposition is done ongoing, so that at every point in time there are work packages that can be pulled by resources while work in the mid-term future may be still remind on a coarse grained level of specification. The PPM process cares for that at every time there are enough work packages available so that all resources can pull an appropriate package for further decomposition or implementation. The feedback about the speed the work packages are driven to the desired outcome (done criteria) is collected as historical data for estimation for the yet undone work packages. This leads to more reliable estimations, followed by a higher probability about milestones. As well changes imply less impact. Reason is that the ongoing decomposition of larger work packages into smaller work packages allows as well an ongoing adaption of the solution space to the changes in the problem space based on current findings and feedback. As side effect less effort is invested into upfront specifications that require rework in case of changes and materialized risks.

The core problem that demand and capacity never match perfectly is the same in a lean and agile approach. The core improvements of the lean and agile PPM compared to the classical PPM are more reliable estimations, the ongoing adaption based on fast feedback and less rework in obsolete upfront specification. As very positive side effect the feedback loops establish a better understanding and alignment to the strategy (if there is any ;-) The fundamental change is the switch from a classical push system (work packages are pushed to resources) to a pull system (resources pull work packages) together with feedback loops.

At Digitec / Galaxus we follow the lean and agile approach. But how does that work in reality? What are the “resources” we talk about and what is a “work package” that a “resource” pulls? Lets see how theory is put into practice.

1. The functional departments like product management, marketing or logistics. The core responsibility of these departments is to run our business, to be operative and productive. But additional these departments are responsible to improve and develop themselves either to implement the company strategy or to increase productivity. This is where the demand emerges. This is as well a conflict for the departments because any effort invested into specification (of the demand) reduces the capacity required to run the business. It is the responsibility of the top management to set goals and staff the departments in a way that they can deal positively with this conflict and have enough capacity to satisfy the specification part of their own demand. This is a serious topic – but out of scope of this blog. Many companies fail exactly here. 
2. The engineering and infrastructure teams. In my personal view these are the scrum and techniques teams. These are the experts responsible to develop and run the system(s) that automate and support the business processes on customer side and within the departments. This includes subject matter experts in the departments as well as business analysts or requirements engineers that – at least in my recommendation – are part of the scrum teams. These teams always are a bottleneck – at least in a dynamic and innovative company. Reason is that a dynamic and innovative company has multiple more ideas (creating demand) than by economic constraints limited investment power. So these teams are typically seen as the capacity side of the company, disregarding that these teams create as well demand to improve and refactor the system itself. Again, it is a responsibility of top management to set goals and staff the teams appropriate. 
3. The “product” or “program” management team. This a bit a special team. Partially it is a virtual team. It is neither demand nor capacity. It is neutral. The responsibility of this team is an optimize-the-whole mindset, a neutral position between demand and capacity. At Digitec / Galaxus the heart of this team is the Business Development team. This is a real team (not a virtual), an organizational unit of individuals with the job description project manager. In my point of view the complete (virtual) team has additional members: the top management responsible to define and communicate the strategy; stakeholder from departments and from engineering requesting their demand and by giving feedback about their current capacity situation.

From my point of view a project or program management holding a neutral position between the demand side, capacity side and the strategy side is a success factor for a company. Beside the responsibility to implement the strategy of the company by executing the projects, the core success factor is to find the right balance for every single project. This is done by organizational implemented feedback loops between the stakeholders of the demand side, the capacity side and the strategy definition organ. My team, the Business Development team at Digitec / Galaxus feels responsible as guards of a healthy organism that develops in a sustainable path towards the agreed vision.

At  Digitec / Galaxus the demand comes from the departments using the innovation process in form of initiatives. This maturing process of an idea to initiative is supported and guided by a project manager. The project manager starts to work with the stakeholders from the department(s) and with engineering as soon as a department proposes an initiative to the innovation board (see: The life cycle of an initiative – step 4). The responsibility of a project manager is to drive an initiative from idea to closure through the life cycle within the right balance between demand and capacity and aligned to the strategy. The alignment to strategy includes prioritization responsibility where the business development team proposes to the innovation board and reflects the decisions of the board back into the development teams and departments.

The organizational implemented feedback loops are 

• The monthly innovation board meeting itself. Goal of this meeting is 1. closing the feedback loop between top management all others about the progress and potential risks and existing impediments and 2. prioritization of the initiatives for the next round based on feedback from departments and engineering and 3. rating of new ideas coming from departments.
• A weekly standup meeting of the business development team to identify conflicts in the demand-capacity-strategy alignment game so these conflicts can be addressed in a next step. 
• The bi-weekly Scrum meetings in the engineering teams 
• A bi-weekly program level backlog refinement meeting where business analyst discuss the upcoming sprints on a cross-team level.

The most interesting meeting (scrum terminology: event) is the innovation board meeting.

The core responsibility of the innovation board meeting is the management of the initiatives Kanban board. This board corresponds with the Kanban board idea in the scaled agile framework managing the business and architectural epics. In the innovation board meeting we discuss the progress of our initiatives, collect feedback, draw out decisions about movements and priorities of initiatives. Input of this meeting is the feedback of departments and engineering about the currents status, existing risks and impediments, changes compared to the last meeting and proposal for the next round. The company strategy is omnipresent to the members in this meeting. The capacity – demand balance is addressed only in case of concrete conflicts or in case an initiative gets into discussion because of any impediments. The time an initiative rests in a specific status on its way through the Kanban board is influenced by the position in the Kanban board. An initiative on top of a lane (high priority) gets more capacity then an initiative below. To carry this out is completely under control of the teams working on this initiative. The board gets the feedback about the progress made and iff there are impediments or decisions to take. As the Kanban lanes do have a WIP limit (currently 16 for the “approved” and “in progress” lane) a new initiative can be moved to the next status only in case a free slot is available. The members of the innovation board meeting do have a transparent view how the teams plan their capacity by looking into the epic and scrum boards of the teams.

My team, the neutral Business Development team representing the PPM care within our weekly standup meeting about the feedback from all stakeholders about progress, conflicts and impediments of any kind. The proceeding of our meeting is pretty close to a daily scrum. As things change slower on initiative level then on story level, a weekly standup is sufficient to close the feedback loop. The two meetings before and after the innovation board meeting do have a special agenda. The pre-innovation board meeting agrees about feedback and proposals for the innovation board including new ideas coming from departments. The post-innovation board meeting works with decisions taken and identifies future measures to execute the decisions in PPM.

This setup of meetings in PPM basically works fine. Nevertheless we identified some flaws in the current setup we will address in the near future. The identified flaws are:

• The monthly rhythm of the innovation board meeting is very fast. This fast rhythm stresses the departments. Every four weeks changes in prioritization may happen and decisions about ideas are taken. That is a fast rhythm for departments. We think about to experiment with a six week period. The drawback of a six week period is a loss in flexibility and feedback. An experiment will evaluate benefits against drawbacks. 
• The bi-weekly program level backlog refinement period is too short. This meeting does not add that much value to the team backlog refinement as it 1. covers the identical time horizon and 2. Is a business analyst meeting only with lack of feedback from departments and stakeholders. We think about to align this meeting as follow up to the innovation board meeting. Additional we plan to invite stakeholders from departments and engineering as well to close a direct feedback loop working with the strategic decisions taken by the innovation board. This meeting corresponds in some kind with the release planning meeting idea in the scaled agile framework (SAFe). The difference is that we do not prepare a release. The agenda of the meeting is similar to the SAFe idea. Different is the frequency of one month instead of three months in SAFe and the duration of half a day instead of two days.
• The direct feedback about required capacity from departments in the initiative is distributed over too many individuals. No direct feedback loop between these individuals exists. The work on initiatives requires capacity from departments. We face situations where several initiative consume capacity in departments in parallel. This leads to conflicts if more effort and involvement is required as estimated. For sure we get the feedback and we prefer to invest into the high priority initiative first, but the feedback loop is indirect going over the project managers driving the initiatives. If the project managers do not share this information, capacity conflicts may escalate. We plan to address this as well with the redefinition of our bi-weekly program level backlog refinement. The new setup shall close a direct feedback loop through all involved teams.

Currently we are living a sub-optimal solution to visualize a capacity usage over all teams (departments, Business Development and engineering): My team established and maintains an Excel worksheet forecasting capacity consumption on key person and team level (from an initiative point of view) based on the feedback from teams and individuals. Yes, establishing an Excel worksheet is typically the sign for a sub-optimal local solution and an existing impediment. So this Excel is a strong hint to improve the process for capacity feedback from departments. This is one very important reason for the refactoring of the bi-weekly program level backlog refinement meeting. We are convinced that an improved program level backlog refinement meeting will close the feedback loop about capacity consumption far more efficient than any Excel worksheet or any resource management software.

While this blog discusses our demand – capacity game more on a high-level view, my next blog will dive deeper into the capacity game on program and team level, especially in engineering.

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.