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

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

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

Our starting situation in prioritization

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

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

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

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

To summarize our current state:

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

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

The Digitec Galaxus basics of prioritization

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

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

Image 1: Weighted Shortest Job First (WSJF) concept

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

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

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

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

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

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

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

Summary

I want to summarize the findings in this blog

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

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 (https://www.admin.ch/ch/d/pore/vi/vis433t.html) 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

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

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

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

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

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

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

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

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

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

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

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

Naturally the requirements of Prolbares for documentation are magnifold:

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

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

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

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

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

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

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

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

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

---Discussion about executive managers and locking systems

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

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

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

So the requirements of executive managers regarding documentation are:

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

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

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

Lean PPM – step 10: Consumers of documentation and their needs

In my last blog I pointed out why there is a need for documentation. What we at digitec Galaxus figured out during the last year working with our Lean PPM system was:

• Who concrete are the target reader of a type of information
• What abstraction level and format does a target reader prefer to use
• What tools and environment does a target reader prefer to use
• What tools and elements do we already use in our Lean PPM that offer options for documentation

Based in these findings we now agreed to establish some rules how we want to deal with the topic documentation. I guess in many organizations the situation is similar, so hopefully my blogs about documentation are useful.

At this point I have to say this is nothing new about documentation in any way. Already before agile and lean these findings were well known. The very basic concepts of documentation are:

• Create a documentation only if there is a consumer that gets value out it
• The documentation must meet the needs of a consumer in respect of amount and abstraction level of information, the format and the tool to use
• If a user searches an information within the documentation, the documentation must support a structure and search so that the consumer will find the information easy and fast.

Sources that address these basic concepts are for example the International Requirements Engineering Board IREB e.V. in its foundation certification, the International Institute for Business Analysis IIBA with its BaBOK, or the differentiation between a product repository and a project repository as recommended by the International Software Product Association ISPMA.

Instead of listening to the needs and requirements of the human sources and sinks of documentation many organizations instead go primarily for standardization and the satisfaction of compliance constraints. From my experience organization should care to develop good documentation practices for the workforce with first priority and with second priority to be compliant to external constraints. In my experience it is always possible to transfer a documentation that follows good documentation practices into a format that as well satisfies external compliance constraints.

Funny that so many organizations and companies disregard the basic concepts as listed above. From my experience the overwhelming compulsion to create standards and satisfy compliance constraints outreaches the objective consideration that an unbalanced harmonization ends up in more drawbacks than benefits. Especially the demonic one-fits-all thinking that still creeps through the management floors – as well in respect of documentation…

A year before today we created documentation at digitec Galaxus following good practices only partially. We used epics and user stories in software development, we tried to avoid exhausting documentation in the requirements and design phase – but we did not follow good practices that support all types of consumers of our documentation. In the last year while establishing our Lean PPM, we discovered basically three different types of consumers. I use the terminology of digitec Galaxus as described my blogs “The value stream of the digitec lean portfolio Kanban system”, “The life cycle of an initiative” and “about project leads and business analysts...”. There is one blog dedicated to every consumer type. 

Lean PPM step 9: Working Software over Comprehensive Documentation

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

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

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

Agile Manifesto

• Working software over comprehensive documentation

Twelve Principles of Agile Software

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

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

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

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

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

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

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

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

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

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