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 7: The relevance of slack time

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

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

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

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

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

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

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

Engineering Capacitiy Consumption

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

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

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

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

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

The value stream of the digitec lean portfolio Kanban system - step 3

It is one of the hardest things to understand the value stream of your organization. An essential element of Kanban is to visualize this value stream. Kanban is a “tool” to improve that by understanding the mechanisms and effects that occur in the system by working with and observing the system. This is not a blog about Kanban. Read the book Kanban by David J. Anderson and you know what I am talking about.

In this blog I talk about the implementation of our Kanban system around initiatives. Initiatives are the most abstract elements in our portfolio management that we manage in a Kanban way. We implement our strategy through theme related initiatives that realize the desired outcome.  See my previous blogs to understand what themes and initiatives represent in our portfolio management.

I do not talk about our strategy itself (if you are interested in the Digitec Galaxus strategy, go to one of our online shops following the links and try to figure out yourself ;-). 

Derived from the strategy we identify themes, initiatives, activities, milestones, decisions to be taken on that way that most probably will implement our strategy. We call this our roadmap. The roadmap has a real physical representation following the story mapping ideas of Jeff Patton (see Jeff Pattons blog and I recommend to read his book User Story Mapping). Actually our roadmap is a story map filling eight meters of a wall two meters high in our roadmap room. It is built out of about three hundred sticky notes in three colors, yellow for stories, blue for milestones and red for top level decisions taken by the executive team. 

An eight meter roadmap (sorry - cards are not able to be read ;-)

This roadmap wall is the idea generation engine, our seed feeding our innovation process. We identify themes, initiatives and dependencies standing in front of the roadmap and discussing about the next steps to go, about priorities, our capabilities, dependencies and time constraints. "We" is interesting. "We" are different groups of persons that walk by and reflect. So the wall gets its updates (...and there is still room to improve the update cycle) .

This is where the Kanban system starts: with ideas for themes and initiatives. As we identify a theme (could be one card in the roadmap), often very vague and unclear at start, it is decomposed into a first set of (one or two) initiatives with the goal to learn about the theme and to draw decisions about the further development (subsequent  initiatives) of the theme. During the life cycle of a theme there are seeding initiatives, more conceptual initiatives with or without prototypes and spikes, implementing initiatives – all in parallel and prioritized against each other.

Well I have to confess: With prototyping and spikes in conceptual initiatives we still struggle a bit. At the moment there is too much concept work done compared to prototypes or spikes that clarify and verify requirements, assumptions, technical risks and usability. At least we identified this impediment. So we have the chance to improve. You see - the second topic we do have room to improve. Things are continuously changing and improving :-) 

How we turn this story mapping wall into a Kanban System and how we implemented the Kanban System tool supported I will follow up in upcoming blogs.

A new start: As NewHire at digitec / Galaxus

In January 2015 I joined digitec Galaxus. This is one of the largest e-commerce companies in Switzerland and for sure the company with the fastest growth. digitec Galaxus is running the two online portals www.digitec.ch and www.Galaxus.ch.

But size is not the reason I hired. After ten years on the road as consultant supporting organizations in the transformation from classical behavior towards lean and agile, I had the strong need to finish something and to be responsible - not only giving good advices and acting a coach, mentor, mediator and lion tamer in a cage.

And well, there was another very essential reason I hired at digitec Galaxus. I had the chance to talk to the two Co-CEO's. These talks created the strong feeling and impression that the mindset at digitec Galaxus is tremendous positive in respect of an agile and lean organization - and that not only in software development.

digitec Galaxus was just finishing a hard period of work. They switched from an old technology to a new system, a complete new developed online-shop and erp-system (enterprise resource planning system). The development of a new system in parallel to the daily business implies:

• The speed of innovations slows down - a hard issue for an e-commerce company
• At deployment time, the new system for sure did not have all the features required - and some more complex processes behaved different in reality as expected in development
• A new system is always a new system. There is a part of the staff members that always remind how easy everything was in the good old times, thus leading to discussions.

But face the fact: In a very short transformation phase switching from the old system to the new system digitec Galaxus succeeded to overcome the most important issues and run a very successfully Christmas business without impact on growth. That is outstanding.

This was the situation when I joined. The CEO´s hired me to preserve and save the flexibility and the agile mindset while still growing. To stay lean, fast and innovative. Well, that is the job I dreamed of, so I signed. When do you get the chance to play an essential part in shaping a lean organization from bottom to top with support of top management for a top Swiss company!

....and yes... the strong feeling and impression that the mindset at digitec Galaxus is tremendous positive in respect of an agile and lean proved to be true :-)