Wednesday, May 18, 2016

Lean PPM – step 16: Prioritization at Digitec Galaxus AG – a real world example for calculating Cost of Delay

Just to remind you on my last blog: At Digitec Galaxus we decided to adopt the weighted shortest job first (WSJF) approach for prioritization of initiatives. The reasons we decided for the WSJF approach are as following:
  • The executive members of the responsible decision board prioritize based on the mindset “What are the items to be delayed for realization so that we can work with high focus on the items we will lose to highest amount of profit, if WE DO NOT implement them. This mindset supports and fosters our Kanban based pull system.
  • A transparent, easy to understand and use prioritization approach supports the communication of prioritization. The often mentioned gap between top management and development teams can be closed as decision are more structured and fact based instead of based on gut feeling and common sense.
The principles of WSJF are defined in the scaled agile framework SAFE or in the book The Principles of Product Development Flow by Donald G. Reinersten (ISBN-13: 978-1935401001, as following:
WSJF = Cost of Delay / duration, with
  • Cost of Delay (CoD) = Business Value + Time Criticality Factor + Risk Reduction – Opportunity Enablement.
  • Duration as the proposed time period required to implement and deploy a feature to operational state.

The Problem of quantifying Cost of Delay

The right side of the Cost of Delay formula is somewhat weak. Reasons is: the factors on the right that are hard to quantify. In literature only a few examples or case studies are available at all – and if so, these examples often require measurements on a very detailed level and a very standardized production process as prerequisite that is neither lean nor applicable in a fast changing and customer driven ecosystem.
Based on these somewhat dis-motivating background we at Digitec Galaxus AG decided to define the CoD factors in our very own context. We decided to calculate Cost of Delay on a set of concrete, normalized and quantified factors that implement the idea of Business Value, Time Criticality, Risk Reduction and Opportunity Enablement. The factors shall represent our business context as e-commerce company in a consumer and market driven environment.
This blog presents our solution to calculate CoD in our very specific context. It is important to understand that our solution works only in our context and not in your context. The reason I describe the solution in detail is my offering an support that you might develop your own creative ideas how to design your CoD definition.

Our design background for a Cost of Delay definition

It is important to understand what conceptual ideas we respected in our CoD design. Our first step was to identify the factors that express Business Value, Time Criticality Factor, Risk Reduction and Opportunity Enablement in our context.
Luckily we already had a good source to populate these factors. The source is the implementation of our Lean Balanced Score Card (LBSC). On top level of Digitec Galaxus we observe our company performance based on a Lean Balanced Score Card with KPI’s on all four perspectives as there are: 1. Financial perspective; 2. Customer perspective; 3. Potential (or learning and growth perspective); and 4. Internal business processes perspective. The KPI’s in this Lean Balanced Score Card are a very good base to select an as balanced set of factors in our CoD calculation. This approach confirms the alignment of our company strategy.
It is important to understand that the Lean Balanced Score Card for sure targets another goal than the CoD definition for prioritization. In our Lean Balanced Score Card are about five to eight KPI’s per perspective. Each KPI has a clear measurement behind that is maintained and implemented by our business intelligence team. Nevertheless, if the factors in our CoD definition would represent a different strategy than our benchmarks in our Lean Balanced Score Card, our internal alignment just would be wrong.
Another conceptual idea was to normalize each factor in our CoD definition on a scale between 1 and 10. The normalization gives us the chance to level changes in our company development. For example, given the fact that we luckily could double our turnover and one of our CoD factors is growth in turnover, we can justify the growth by mapping larger values in turnover to the normalized numbers between 1 and 10.
The third conceptual idea is that a calculated CoD and WJSF number – whatever calculation scheme you use –shall express – at least in the overall direction – the average gut feeling for prioritization of the executive management. So we decided to run test rounds with calculation results. In a first round the business development tested the calculation. The test was easy: every member of the business development team set the factors for each initiative blind. We then compared the results against each other and against the existing prioritization in our productive Kanban board if initiatives. In that way we came to a common interpretation of the factors and their weights.
The second round of test was the real live usage. We just deployed the WSJF number visible in our Kanban board of initiatives and right away started working with this new feature with the executive team and all stakeholders. We challenged the executive management to set the factors and to reflect the results against their gut feeling prioritization.
In our world of Digitec Galaxus AG we often just deploy a new (small or even larger) feature or process change and start working with it right away. Changes are welcome and in most (not in all!) cases not seen as thread. Our staff members from executive team down to the normal worker are used to that and give feedback right away. You just have to stand the feedback in case you deployed crap…
Finally, we redefined the factors, the normalization and the weight factors in the algorithm several times until we confirmed ourselves that the identified formula represents our strategy and proves to be a helpful instrument in prioritization.

The Digitec Galaxus approach to quantify Cost of Delay

Let’s get to the point. The final formula for CoD uses the following influencing six factors:
  1. Strategic alignment: the degree this feature supports our strategy as expressed by our strategic roadmap.
  2. Potential for increase of turnover: I guess this is self-explanatory
  3. Potential for cost saving or increase of efficiency: Cost saving features typically are automation of steps in business processes like invoicing or order management.
  4. Competitive advantage: This factor is our benchmark against our competition. For example, we set a 10 for a feature that represent an USP customer feature that is totally new in e-commerce.
  5. Loss of value over time: Often features do have an impact on the market only if operative within a certain time window, the window of opportunity. This is a very important factor for market driven companies. A feature may have only a very small window of opportunity requiring to implement it very fast.
  6. Increase of capabilities: this factor respects our learning and growth. We do have initiatives in our Kanban board that address solely learning aspects. For example, right now an initiative strives to improve our acceptance testing framework and the quality of our automated acceptance test suite. This includes as well training and coaching measures.
I mentioned above that we normalize all factors on a scale from one to ten. This requires to map a value on the one to ten scale to a clear status change or measurable quantity in the real world. The benefit of normalization is that a. The results are relative therefore easier to rank and b. the algorithm behind the Cost of Delay is more stable.
I want to demonstrate the way to normalize on two factors: Strategic alignment and competitive advantage. We normalized these factors as following:
  • Strategic alignment: As I reported in a previous blog about the implementation of our strategic roadmap, the physical representation of our strategic roadmap is an eight-meter-long wall of sticky notes following the ideas of Jeff Pattons story mapping approach see (see Jeff Patton’s blog about story mapping). The normalization then is easy:
    • If the item to prioritize represents one to one a sticky note on the strategic roadmap, the item is mapped to a 10.
    • If the item to prioritize is related to or supports a sticky note on the strategic roadmap, the item is mapped anything between 4 to 7.
    • If the item to prioritize cannot be related to any sticky note on the strategic roadmap, the item is mapped to a 1.
  • Competitive advantage: The benchmark of competitive advantage are the features offered to customers either by our company or by our direct competitors. We use this benchmark of features as base for normalization
    • If the item to prioritize implements a clear USP feature, the item is mapped to a 10.
    • If the item to prioritize implements or improves a core feature or a required base feature that helps us to excel our competition, but it is not an USP of our service offering, we map the item to a 4 to 7.
    • If the item to prioritize implements a me-too feature not seen as required base feature, we map the item to 1.
The point in these mapping schemata for every single factor is that we have gone through a vital discussion what we interpret as a 1, 4, 7 or 10. We describe these mapping with very clear and measurable benchmarks or quantify the mapping. For example, the mapping of factor “potential for increase of turnover” is quantified in Swiss Francs. The discussions and the feedback back rounds in the mapping the definitions resulted in an overall accepted and understood interpretation of the factors.
Now we reached the point that we were able to set the single factors that influence the calculation algorithm. Next step is to specify the calculation algorithm. As we are currently following a growth strategy, we consequently have to weight turnover and competitiveness higher than cost saving. The calculation formula respects this by setting the weights of the factors accordingly.
In concrete our algorithm is as following:
  • Cost of Delay =   0.6 * strategic alignment +
    0.6 * potential for increase of turnover +
    0.4 * potential for cost saving or increase of efficiency +
    0.4 * competitive advantage +
    loss of value over time +
    increase of capabilities.

As every single factor in the algorithm is a number between 1 and 10, the Cost of Delay value is in a range from 4 to 40, with the lowest Cost of Delay as a 4, the highest Cost of Delay as a 40, i.e. there is a multitude of ten between the lowest and the highest number for Cost of Delay.
The final step in our calculation is the WSJF value. As we normalize the quotient “Duration” in the WSJF formula as well on the scale between 1 to 10 the WSJF value results in a number between 0.4 to 40.

This approach is unique for Digitec Galaxus

Dear reader, please be aware that this concrete solution for calculating WSJF numbers is valid only in the context of Digitec Galaxus.
So what is your take away? What are good practices that can be transferred into a different context?
From my personal point of view the transferable learnings are:
  • The WSJF approach improved our prioritization system by making business value and other influencing factors transparent
  • Align your factors with your strategy. A Balanced Score Card – used in a lean way – could be used as starting point. The weights of the factors in your WSJF algorithm have to reflect your strategy as well.
  • The most important activity in specifying the WSJF algorithm is the discussion about the influencing factors AND the benchmarks used to quantify a factor.
  • If the WJSF results and your gut feeling about the results differ, you have to step back and go through a next round. Gut feeling is not the worst way to prioritize. The factors in the algorithm are nothing else then making gut feeling transparent and understood by others.
  • Normalization of factors supports a more stable algorithm compared to absolute factors.
There are more findings and benefits we discovered after establishing the prioritization system based on WSJF for quite a while – but this is subject of my next blog.

Summary of this blog

As examples and good practices in literature and on the web are rare, we decided to define Cost of Delay at Digitec Galaxus AG based on normalized and quantified factors that represent the components in a Cost of Delay calculation.
We specified the calculation algorithm for Cost of Delay and WSJF based on feedback of prioritization experiments done by experts in our company and aligned to our company strategy.
The result of the WSJF calculation for an item to prioritization is a number between 0.4 and 40. Higher numbers represent higher priority. The absolute number itself does not say anything about priority of an item. The number are relevant only in a relative comparison of items against each other.
Never ever rank items in your portfolio strictly based on the results of any WSJF calculation algorithm. The results shall be used as one information unit out of a set of information units that influence the prioritization of an items in your portfolio against other items.
And to keep you curious ;-)  I will address somewhat unexpected positive results of the WSJF prioritization schema in my next blog.

Wednesday, May 11, 2016

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

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 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, 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:
Weighted Shortest Job First (WSJF) concept
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.


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.

Saturday, March 12, 2016

Lean PPM – step 14: The concept and tools used for an agile documentation @ Digitec Galaxus

Over the last fifteen months we changed our documentation structure concept at digitec Galaxus a few times. Every change incorporated a newly discovered aspect as discussed in my previous blogs.

The tools used at Digitec Galaxus AG

The tools we use for documentation are Jira, Confluence, Signavio and our development environment (Microsoft.NET). Basically Jira is an issue tracking system, Confluence a wiki and Signavio a BPMN tool. We try to avoid file based tools like Office (Word, Powerpoint, Excel, …). Actually Powerpoint is treated as enemy. Excel is used in case we need data analysis. In this case Excel files are kept as attachments in Confluence.

All these tools offer a versioning or history concept, even for attachments. Confluence misses the concept of releases and configurations, but at least is works with a history, versions for attachments and some small idea of an archive.

I need to supply some more information for the tools so that you understand our documentation structure concept.

Jira as issue tracking tool offers the feature to change the meta model. This allows to establish new issue types and new link types between issues. With this you can model a hierarchy of issues and links between issues used for tracing. We use this feature to implement one part of our Lean Portfolio Management as discussed (see these blogs: the Kanban system step1 and step2; life cycle of an initiative). 

In short: the core is a four abstraction layers Kanban system with the abstraction layers 
  • Theme -> Initiative -> Epic -> User Story

following a SAFe alike concept (SAFe calls the layers Theme -> Epic -> Feature -> User Story). The elements of type Initiative, Epic and User Story are implemented as linked issues in Jira.

Confluence is a wiki and collaboration system. Confluence offers the “space” feature as extension to a plane wiki. A space is a closed wiki for its own purpose. With this Confluence is a tool where you can create as many independent wiki instances as you like. You can even create wiki instance templates, i.e. if a user creates a new wiki already an initial set of pages with a predefined page structure is created and offered to the user, ready to start adding content. Confluence offers some means to navigate between spaces, so even cross-wiki collaboration can be established.

The core documentation structure concept

With all this in mind, our implementation of the documentation structure in these tool is as following

Implementation of the Digitec Galaxus concept for our documentation structure 
The documentation structure concept holds the following elements

The Confluence space “strategic themes”

In Confluence we created one special space named “strategic themes”. You may remember, our roadmap is a wall of sticky notes following Jeff Pattons story mapping approach (see Jeff Patton’s blog and his book). This space holds all the strategic themes of our sticky wall roadmap (read about our strategic roadmap), one wiki main page per strategic theme. This page (and its sub-pages) documents the business value of this theme and our idea how to realize it step by step. One step in the development of a strategic theme again is an initiative (see life cycle of an initiative). The development of a strategic theme actually is represented by a chain of initiatives. The wiki page just lists the chain of initiatives.

As an initiative is represented in our Lean PPM as an Jira issue, actually this list is a list of links to Jira issues. As we develop a strategic theme, we develop the chain of initiatives. i.e. new initiatives maybe added or the timeline of the whole chain may change. The information of an initiative is documented in the initiative itself plus one Confluence space per initiative (see below).

The Jira issue type “initiative”

An initiative is represented as a Jira issue in our Lean Portfolio Management Kanban board (see life cycle of an initiative) An initiative documents the information about goals, strategic alignment, the project lead responsible for the initiative’s life cycle, current status, a short progress tracking statement and so on. So this is exactly the documentation that is addressing the execute manager’s interests. We try to keep this amount of information (the description attribute of the Jira issue) down to one page to read.

Additionally, an initiative holds the list of links to the Epics that represent the program level in SAFe. So any person interested in more details of an initiative has the chance to drill down to Epics level or even down to User Stories level. Last but not lease the Jira issue of type initiative links to a Confluence space (see below).

The “initiative” Confluence spaces, one per initiative

There is one Confluence space linked to every initiative in Jira. This space is used for documentation and collaboration while realizing the initiative outcome. Classical you could say, this is the “project space”. This space holds all information required to develop the initiative – except for information kept in the other element of Epcis, User Stories and in BPMN models.

Concrete this space holds meeting minutes, decisions taken, alternatives and option under discussion, agreed upon requirements (on (SAFe) feature level), the links to the BPMN diagrams of the business processes we change in this initiative and so on. An initiative space typically is the working space for project leads, business analysts, subject matter experts, product owner (read more about how we deal with these term in my blog about “Probare’s”). We agreed upon a basic page structure for this page. This recommended page structure helps readers to find information. So all meeting minutes are under the main page “meeting minutes”, all requirements under the page “requirements” and so on. This helps persons to know where to expect what type of information.

Structure of a space for an initiative

As this space is the working space as long as the initiative is under development, there is no activity anymore as soon as the initiative is implemented, reviewed and closed. We then use the archive feature of Confluence to hide it. This helps to keep the working space small and clean. As we agreed to work on max 32 initiatives in parallel (our WIP limit in our Lean PPM Kanban board) there are max about 40 initiatives visible, all the other are archived.

If we start a new initiative in the chain of initiatives driving a strategic theme, we often need to remind ourselves on a previous decision or requirement. In this case we consult our strategic theme space. There we identify the initiative in the chain of initiatives. There we click the link to the Jira issue of this particular initiative we are interested in. This initiative again holds the link to the assigned Confluence space and we have at once access to all information we are searching for.

The Jira issue type “epic”

In deed the we used to epic layer rather for organizational reasons then to store many valuable information required for development. An initiative has a relationship to one or more epics. In SAFe the counterpart of an epic would be a feature to implement that in turn is realized by a set of user stories. Actually we use the epic level a bit more general.

As we use our Lean PPM for all type change activities, an initiative is not restricted to implementing software. An initiative can be as well the reorganization of a department, an employee development program, a refurnishing of a retail shop or the maturing of a promising idea for an innovation. An initiative can be a mix of organizational tasks, concept work, software development. Additionally, our idea is that an initiative is “done” only at that point in time, when the change is rolled out to the functional department, i.e. training of employees has taken place, software has been deployed, organizational procedure changes took place and show the expected results – whatever is required to meet the DoD for this initiative.

To cover all these steps and activities and tasks as well we use the construct of an epic. An initiative can for example can be decomposed to one epic for a prototype, two feature epics to implement the software, an epic to train employees of the department in use of the software, an epic to implement new BI features to track success of the initiative and a rollout-to-department epic.

But where to keep all the information required to drive this – for example the training material used to train the users in the department? We use exactly the Confluence space of the related initiative to hold this information. As well the feature to derive user stories from for software development are documented in this confluence space and not in each epic issue. Concrete the features are documented (if needed) under the requirements page in the initiative space.

We decided for this concept as it keeps all information for an initiative focused in one place instead of spreading it over many Jira issues. As we care for that our initiative are small the amount of information is naturally limited. A well we strive to document the minimum amount of information required. We care and invest to share knowledge through agile means such as the Scrum events, a release planning meeting as used in SAFe, the CCC (card, communication, conformation) approach. We are nearly paranoid to document to many information – rather we accept some gaps in documentation than document an additional page of waste.

I hope you got the message and our concept to deal with the epic level in Jira.

The Jira issue type “user story”

Well user stories are user stories. We strive to use user stories pretty close to what many intelligent and keen persons recommend to use user stories. There is enough literature and information in form of books, blogs, conferences around. There is nothing I can really add here. Point.

The Signavio BPMN system

An e-commerce company like digitec Galaxus is business process driven. Highly automated processes are a key to success. For example, the checkout process for a customer basket is a really complicated process with many alternative flows, options and business rules. We encountered that the archived information of an initiative often is not sufficient to satisfy the need to fully understand a specific process we want to change.

Adding a new delivery type such as delivery on Saturday is a good example. This implies writing some software – but this is only one part of the story. It implies as well changing organizational procedures in logistics and accounting. Quite a set of new alternative flows in the checkout process pop-up. All these processes have to be consistent and compliant. Business process description help to keep all this consistent and not to lose control.

This is the reason we decided to build up a business process model using a BPMD tool as Signavio. If you are interested why we decided to go for Signavio, please contact me. This is out of scope for this blog. Is it more interesting how we use a business process model and how it is integrated into our documentation structure.

Core decisions about building up our business process model are:
  • We do not strive to document all business processes down to all levels (one, two three). We document all business process on level one – but these are two diagrams and represents rather a table of content of our business processes then an extensive documentation.
  • We do not document our business processes upfront. If we touch a business process while working in the context of an initiative, we add the according BPMN diagrams into our model and extend the model. As well we decide upon the level of detail. Some business processes are documented down to level two only, some down to a detailed level three.
  • Changes of the business process model take place while working in the context of an initiative. Typically in the initiatives space (under the requirements page) the links to the changed or added BPMN diagrams are listed. This keeps requirements and models together, for example the business rules that apply within an activity of an business process model.
  • BPMN diagrams are a visualization only. We do not generate or orchestrate any software. BPMN diagrams are purely for documentation purpose only. The goals is to fast and easy find, read and understand the diagrams as starting point if we want to change the process any time in the future.

We invested quite some effort to agree about our BPMN “dialect”, i.e. what we treat as a healthy level three diagram, where to stop with details or how to design specific process aspects. We covered this by external and internal training sessions enhanced by review and feedback sessions based on created diagrams.

We did not yet reach a satisfying status. Building up a business processes model that really delivers value is not an easy task – even when used for documentation only and no for orchestration of an BPMN engine. We are still on the learning path, but there is light at the end of the tunnel. Hopefully I can write a blog about a value generating business process model any time in the near future.

What we do and what works is to offer two entry points into our business processes model. One entry point is top down, i.e. if somebody wants to know how a specific business process runs in our organization, she can start at the top level diagram and drill down as far as diagrams exists. As our model still has many holes, for most processes the drill down stop on level two.

The second entry point is from aside while working in the context of an initiative. This is done by following the links listed in the initiative’s Confluence space under the requirements page. By now this is the typical way used. It is a daily work environment for our business analysts.

Getting all together

This blog describes our concept to structure documentation. Reading this it sounds like we do a lot of documentation and we act anything but not agile. Does that really follow the agile manifesto “Working Software over Comprehensive Documentation”?

I will discuss this in my next blog talking about the reasonable behind this structure – the reasonable derived from the needs of the readers of the documentation.

Many contributors within digitec Galaxus, from CEO down to software engineer developed the structure through many small steps of a continuous improvement identified in reviews, retrospectives or in the coffee corner. The existing structure will change ongoing as we identify new aspects to incorporate or when discovering existing aspects as waste. So far we agree that this structure delivers a real great benefit to all of us. We own a specific for our needs built documentation and even more important collaboration platform to drive our change initiatives.

Additionally, this concept to structure documentation does not say anything about the amount of documentation. The amount of documentation always is subject of discussion. We strive to document the least amount only – but what “least” is, is very dependent of whom you ask. Some means in our structure support to limit the amount of documtation. The two most important ones are first the WIP limit if initiatives and second the principle to archive Confluence initiative spaces as soon as an initiative reaches its DoD. So the active size of documentation is limited to the Confluence space of strategic themes, the initiatives active worked on, the business process model in Signavio, the User Stories under development and the source code base of our software systems. I personally treat this as a fair amount of documentation, especially if we strive to share most information in our heads by communication, collaboration, confirmation and feedback – and not be sending links to Confluence page via email. 

Saturday, February 27, 2016

Die Durchsetzungsinitiative DSI – Ein Appell

Liebe Kollegen und Freunde

In der Öffentlichkeit bin ich eher politisch leise. Der Grund ist, dass ich als Gast in diesem schönen Land lebe. Daher achte und respektiere ich den Gastgeber, welcher aus guten Gründen seine eigene Meinung vertritt.

Die Durchsetzungsinitiative DSI jedoch geht über das für mich persönlich vertretbare Mass deutlich hinaus. Sie bewegt mich dazu, meine Meinung öffentlich bekannt zu machen. Ich würde mich freuen, wenn meine Kollegen und Freunde, die ich in den über elf Jahren hier gewinnen durfte, diese Meinung wahrnehmen und reflektieren.

Integration ja oder nein?

Liebe Kollegen und Freunde, die Durchsetzungsinitiative ( verstehe ich als eine Deklassierung meiner Person zu einem Mitglied 2. Klasse. Sie gefährdet meine Existenz, welche ich hier in der Schweiz sehe, welche aus meiner Wahrnehmung heraus vollkommen integriert ist und mitten im Leben steht. 

Gerne gebe ich Ihnen die Möglichkeit sich selbst ein Bild meiner Integration zu machen und nenne ein paar Punkte, die für mich wertvoll und wichtig dazu beitragen:
  • Im Berufsleben wirke ich seit Jahren im Kader von bekannten Schweizer Unternehmen, eine Zeit als Mitglied der Geschäftsleitung und Partner. Es ist eine Freude mit meinem Kollegen zusammen das Unternehmen zu entwickeln zu einem Top Unternehmen in der Schweiz und darüber hinaus.
  • Nebenberuflich engagiere ich mich an Fachhochschulen in der Schweiz. Ich unterrichte dort und betreue Masterarbeiten. Ausbildung sehe als einen Kernpunkt und Verpflichtung einer gesunden und leistungsfähigen Gesellschaft an – neben der persönlichen Freude meine berufliche Erfahrung an die jüngere Generation weiter zu geben.
  • In meiner Freizeit engagiere ich im Miliz System in der SAQ Schweizer Gesellschaft für Qualität. Über Jahre hinweg leitete ich den Lenkungsausschuss der Fachgruppe Informatik und organisiere nach wie vor Fachgruppen und Konferenzen mit dem Ziel Wissen zu verbreiten und Kompetenzen aufzubauen.
  • Mit der gleichen Leidenschaft für die Sache gründete ich mit Kollegen den Swiss Agile Leaders Circle, ebenfalls eine Community engagierter Personen mit dem Ziel Wissen und Kompetenzen über Unternehmensgrenzen hinweg zu teilen und zu verbreiten.
  • Privat sind meine Frau und ich eng mit Schweizer Familien befreundet. Wir verbringen Wochenenden zusammen im Ferienhaus, helfen uns gegenseitig, wenn Hilfe notwendig ist, treiben zusammen Sport und lieben es anschliessend abends ein Glas Rotwein zusammen zu geniessen. Meine Kinder – beide mittlerweile berufstätig – sind voll integriert hier, einschliesslich der perfekt gesprochenen Schyzerdütsch meines jüngeren Sohnes.
  • Meine Frau ist auf freiwilliger Basis engagiert in einem Kaffee einer altersgerechten Wohnstiftung und betreibt dieses zusammen mit weiteren Frauen und als sozialer Treffpunkt für die Bewohner.

Warum ich mich durch die DSI gefährdet fühle

Die DSI hebelt eine grundlegende Errungenschaft der Demokratie aus: Die Gewaltenteilung. Selbstverständlich ist das Volk der Souverän. Jedoch nicht in der Form, die Herr Blocher herausstreicht. Seine Interpretation ist, dass die Legislative die Überhand über die Judikative bekommt. Die Ausschaffung findet nach der Forderung der DSI zwingend und ohne juristische Überprüfung statt. Faktisch wird damit die Gewaltenteilung aufgehoben. Die Gesetzgebung dominiert die richterliche Überprüfung. Das mag nun sehr theoretisch klingen. Ich konstruiere im Folgenden einfach einmal ein mögliches Szenario gemäss der DSI.
  1. Im Jahr eins nach der Annahme der DSI werde ich an einer S-Bahn Haltestelle abends von zwei Personen tätlich angegriffen. Da ich fit und sportlich bin, ist es mir möglich einem der beiden Angreifer meine Faust in den Magen zu rennen, das Überraschungsmoment zu nutzen und davon zu rennen. Leider gereicht mit dieser Vorgang zum Nachteil. Da ich den Vorgang nicht beweisen kann und die Zeugen zwei zu eins gegen mich sind, werde ich nach Art. 123 StGB wegen einer einfachen Körperverletzung verurteilt.
  2. Im Jahr acht nach der Annahme der DSI hat meine Frau oder einer meiner Söhne einen folgenreichen Unfall. Ich werde angerufen. Emotional bewegt fahre ich viel zu schnell mit dem Auto in Richtung Krankenhaus und werde von der Polizei gestoppt. Aufgewühlt, wie ich bin reisse ich mich aus dem Griff eines Beamten, er stolpert und fällt zu Boden. Die Auslegung dieses Vorganges wird mir als Gewalt und Drohung gegen Behörden und Beamte (Art. 285 StGB) ausgelegt.

Diese beiden Vorgänge genügen. Die Folge ist (Zitat aus der DSI): «Die Landesverweisung ist durch die zuständige kantonale Behörde im Anschluss an die rechtskräftige Verurteilung beziehungsweise nach Verbüssung der Strafe unverzüglich zu vollziehen». Ganz offiziell stellt sich die DSI sogar über das Völkerrecht (Zitat): «Die Bestimmungen über die Landesverweisung und deren Vollzugsmodalitäten gehen dem nicht zwingenden Völkerrecht vor».

Meine gesamte Existenz wäre somit durch diese beiden Vorfälle vernichtet. Ich wäre gezwungen tatsächlich in die Fremde zu gehen – denn mein Lebensmittelpunkt ist hier, in diesem Land, in dieser Gesellschaft, hier bei meinen Kollegen und Freunden.
Liebe Kollegen und Freunde ich bitte euch zu reflektieren wie viele Personen Ihr kennt und sehr gut kennt, die seit Jahren mit euch zusammen hier wirken und leben und sich engagieren. Alle diese sind bei Annahme der DSI dieser Gefahr ausgesetzt sehen und als Bürger zweiter Klasse.

Die Verhältnismässigkeit ist nicht gegeben

Laut Statistik (Zahlen aus 2014) leben 1.9 Mio Ausländer in der Schweiz. 1.3 Mio aus der EU/EFTA, vorwiegend aus Deutschland, Frankreich und Italien.

Ist es wirklich verhältnismässig eine überwiegend stille, gut integrierte und ohne Unterschied zu einem Schweizer Bürger im gemeinsamen Wertesystem lebende Menge an Menschen zu deklassieren, um einem sorgfältig geschürten Angstszenario nachzugeben?

Ich würde es als einen tragischen Verlust für die gesamte Gesellschaft sehen, wenn es einem kleinen, wenn auch sehr lauten Teil der politisierenden Gesellschaft gelingt die Mehrheit dermassen schädlich zu beeinflussen: Das Völkerrecht als zweitrangig zu manifestieren, die Grundwerte der Demokratie auszuhebeln und 15% der Bevölkerung zu deklassieren und ihre Existenz potentiell zu gefährden.

Was sind die nächsten Schritte

Nicht nur die DSI sehe ich als einen ernsten Schritt an. Die sich aufzeigende von einigen wenigen voran getriebene Entwicklung an sich ist gefährdend. 

Wie geht diese Entwicklung weiter? 
Kommt als nächstes eine Initiative, welche auch Personen, die eingebürgert wurden, die Staatsbürgerschaft zwingend wieder aberkennt unter bestimmten Bedingungen? 
Und als dritter Schritt die zwingende Aberkennung der Schweizer Staatsbürgerschaft für jedermann, wenn eine gewisse staatsfeindliche Gesinnung nachgewiesen werden kann?

Solche schleichenden Schritte sind die typischen Anfänge einer unheilvollen Entwicklung. Morgen ist die erste Chance dieser Entwicklung Einhalt zu gebieten. Ich persönlich nehme die Schweizer Gesellschaft als eine Gesellschaft der Mitte wahr. Eine Gesellschaft mit einer mächtigen Kraft diese Mitte zu wahren und Extremen in jeder Form entschieden entgegen zu treten. Ich würde mir wünschen genau dies Morgen zu erkennen.

Rainer Grau, Bonstetten, Samstag der 27.02.2016

Saturday, February 20, 2016

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.

Sunday, February 14, 2016

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. 

Sunday, February 7, 2016

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.