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.

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.