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 8: about project leads and business analysts...

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

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

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

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

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

The core responsibilities of a business analyst are:

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

The core responsibilities of project leads are:

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

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

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

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

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

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

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

Lean PPM step 7: The relevance of slack time

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

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

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

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

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

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

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

Engineering Capacitiy Consumption

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

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

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

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

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

The life cycle of an initiative – step 4

In my last blog I introduced you to the roadmap as seeding mechanism for our portfolio management. In this blog I want to explain how the initiatives are derived and managed in our Atlassian Jira system.

As you might imagine, at any time there are initiatives on different maturity level. Maturity spans from very vague und unclear ideas to well know initiatives with clear defined goals. Initiatives below a certain maturity level we call ideas. Ideas often are specified by a few phrases about what the outcome and the benefit for our customers and/or us might be. Ideas are the start of the value stream related with initiatives.

Ideas at Digitec / Galaxus basically are born at two different places in our organization. One place is a department like marketing, supply chain management, retail or engineering. The other place is the executive team.

The challenge is to create a Kanban system with simple and understood communication channels that route the ideas well prioritized through their life cycle. Quite a number of our ideas end up in our icebox, the icebox (actual the “on Hold” status in our Kanban system) holds potential initiatives for unfreezing any time in the future. The very creative teams in your company always generate many more ideas as can be realized with limited resources. Important is to communicate this aligned to our strategy and to make it transparent and understood.

Many ideas are tiny things a department can realize on its own. These ideas directly are handled by the department. This is part of the daily work of an department.

Many ideas do have the character of small enhancements that require limited engineering resources to be implemented.  These ideas we run through a fastlane mechanism I will talk about in detail later. So far it is only of interest that the fastlane mechanism is a specific very lightweight input queue of low bureaucracy to engineering.

Only very few ideas are potential initiatives. These are the ones that span over departments, are more complicated and/or require a certain extend of resources to be realized. These ideas we mature towards initiatives that we run through our company wide initiative Kanban system. To manage this stage in the life cycle of an initiative – from first idea status to the “pretty sure that this is a real initiative” status, we introduced a lightweight innovation process in the departments. I will talk about that in as well in a future post, but actually this innovation process is following the “Stars to Road” concept of idea maturity. This stage in the life cycle of an initiative looks as following:

Ideas move from departments into the (one and only strategic) company wide Kanban board 

As you see, actually we established two processes in our organization that work hand in hand. The innovation process that generates ideas and develop potential initiatives towards the company wide initiative Kanban board; and as the second stage in the life cycle of an initiative the portfolio process that matures and drives an initiative from proposal to closure. 

Formally we identified a well-defined set of states in the life cycle of an initiative from idea to closure. States of an initiative while living in the innovation process in the context of a department are:

• Initiative idea new: An idea comes into existence 
• Initiative idea approval required: The idea is proposed to the company wide initiative Kanban board
• Initiative idea approved: The idea is accepted by the innovation board that manages the company wide initiative Kanban board

In Jira we implemented initiatives living in the innovation process as issues of a new created issue type idea. Every department works with its own Kanban board for ideas. The Kanban board exists as a real physical white board working with sticky notes. Additionally every department owns a Kanban board in Jira managing ideas and normal tasks. The physical white boards are used as communication and collaboration medium. The Jira Kanban board holds a subset of the white board “cards”.

An initiative in the status “Initiative idea approved” will be moved from the department (Kanban board) to the company wide initiative Kanban board. In Jira this is a move of an idea issue from the department board into the company wide initiative Kanban board . With this step the department has to write a vision what the outcome of the initiative most probably shall be. The vision is a much focused description that shall not exceed two screen pages. In our tool setup an initiative is a Jira issue of type “initiative” (we created as well this issue type). The vision is stored in the description attribute of the issue and follows a template structure as following:

Vision template for an initiative proposal

This template guides a department to write a focused vision statement. On request a department gets support from the business development team in writing the vision statement. 

States of an initiative while living in the portfolio process in the context of the company wide initiative Kanban board are:

• Initiative new: the executive team proposes a new initiative. This is the input channel for the executive committee into the company wide initiative Kanban board. 
• Initiative approval required: the innovation board (this is our decision panel about initiatives) decides about initiatives in this status. The result is that the proposal is either approved, declined or set to on hold (stored in our initiatives icebox)
• Initiative approved: the innovation board accepted the initiative. In this status we invest more effort to develop the initiative (kind of backlog refinement) so it can be realized.
• Initiative on hold: the innovation board accepted the initiative. Nevertheless because of strategic reasons the innovation board decided not to invest effort now. The initiative is iceboxed. This status represents the icebox status of good ideas. The innovation board justifies why the initiative is iceboxed and gives feedback back to the source department
• Initiative declined: the innovation board decided that this proposal is never ever of any value. The innovation board justifies why and gives feedback back to the source department.
• Initiative in Process: we work on the initiative with the goal to create the outcome as fast as possible. 
• Initiative in Review: the outcome is realized. Now we review the outcome with all stakeholders before we move the responsibility to work with the results back into the departments. 
• Initiative closed: All stakeholders agree that the outcome is satisfying.

Our company wide initiative Kanban board  acts as following:

Concept of our initiative life cycle or value stream for change

Jira experts will encounter that such a board cannot be implemented as a single Kanban board in Jira. Actually our implementation offers two views. The first view implements the lower swimlane for evaluating a deciding about ideas, the second view implements the upper swimlane used in the portfolio management of initiatives.

Another challenging task in portfolio management is the demand – capacity balance. A lean portfolio management system is built on a pull system instead of a push system. Teams working with the Kanban system pull work as represented and prioritized on the Kanban boards. Once priority is defined, the speed items develop to the next status and finally to done depends on the resources made available. The goal of a lean portfolio management is to create the maximum outcome with a given capacity. What “given capacity” is depends on the investment management is willing to invest.

The demand is represented by the initiatives in our Kanban system. The capacity is limited by our workforce in the departments and engineering. One key resource and always a bottleneck for sure are our engineering resources, i.e. our software development department including business analysts, software engineers, business intelligence experts and (yes you may wonder, but I discuss this later on) project managers. The reason is obvious: we always have more ideas what we could realize compared to the affordable resources.

Well – I will talk about our ideas of demand – capacity balance in an upcoming blog (I see there are some upcoming blogs I have to write J). As well prioritization of initiatives is a very interesting topic I will address any time in the future. So stay tuned. 

Innovation Arena: Get-together, pre-selection

I, my last blog entry was in January this year. I am sorry and apologize in case you have been waiting. I had some exciting projects and learned a lot. Now I start again to give back to the community.
So I continue with Innovation Arena and the agenda of an Innovation arena run.

The get-together

The room is prepared and the experts dropped in. Now it is you term to introduce into the ceremony of Innovation Arena. If Innovation Arena is well known to most of the experts, you might decide to shorten this step. In case of new externals as invited experts, I recommend do introduce in full length. External experts need to understand what is expected and to feel welcome and comfortable.

As moderator explain the overall objectives and every single workshop steps. It is important to highlight the collaborative nature of the workshop. All participants act on eye level. All participants have the chance and are expected to give feedback. Transport the idea that Innovation Arena is a positive meeting, so participants shall focus on adding and improving ideas instead of critics and risks.

It is very important to explain:

• the way pre-selection of ideas is done (if used)
• how to use the prioritization criteria
• how the rating is executed
• how the results will be determined
• what the next steps are, when this Innovation Arena run is closed

Now all experts are prepared and hopefully in the mind set to drive the ideas of your organization with motivation and creativity.

The pre-selection of ideas 

In Innovation Arena, the crowd of experts shall concentrate on a restricted set of ideas. We recommend taking 5 to 15 ideas into one run.

For sure this is an option to play with. Some organizations use two full days on a similar type of workshop and take a hundred ideas of potential features of future development into one run. If you act more local and internal, a higher frequency, but shorter timeframe (as proposed in this blog) typically is preferable because of faster feedback cycles and reflection. If you are more globally and distributed, with many externals like key customers representatives, a lower frequency with longer time boxes might better suit the constraints of distribution. Play with these options and you will find the best fit for your organization.

Even this pre-selection step is optional. I recommend a pre-selection only in case you run Innovation Arena in higher frequency in your organization, with a more local setup, and based on an already established shared understanding of the ideas. With this setup pre-selection is easy. The majority of experts already know the ideas presented on the pinboards.

Image 1: How to arrange ideas pinboards in an Innovation Arena run

If the pinboards are placed as in the image, a collaborative and self-organizing way of pre-selection is to please the participants to place themselves in front of this one pinboard with the most promising ideas in this workshop run from their very personal view. Explain that we will work in this Innovation Arena run with about five ideas pre-selected by the most experts in front of the representing pinboard. This way of pre-selection fosters collaboration, movement and a positive start.

If you run Innovation Arena regularly in your organization, the experts understand the criteria “the most promising ideas in this workshop run from your personal view”. If the experts do not understand, this is a signal that you have to work on this shared understanding. This shared understanding under the experts in your organization reflects the alignment with strategic objectives. But that is a different story and maybe some time a blog on its own.

This pre-selection works better with more experts in the room than pinboards. Ideal you have at least twice the number of experts than pinboards. And you should have at least twice the number of experts than pinboards. Otherwise the group of experts is restricted to the idea owners and this is for sure a sub-optimal setup.

Be flexible in applying this pre-selection step. But I am sure you got the idea and see options how to play with this.

Next Blog will be about pitching ideas and probably the most important step: the rating...