Not "Go And See": Come And Listen!

In the world of lean thinking there is a dose of healthy skepticism about numbers and reports. Taiichi Ohno, the most prominent of the creators of the Toyota Production System, was known to put the papers away and instead say: "Let's go and see for ourselves!"

Going down to the shop floor, the gemba, the place where value is created (and sometimes wasted), is to actually grasp the current situation and understand what is going on. Down there, anchored in reality, Ohno-san could tell the people what to do based on what he actually saw happening.

Now, where is the gemba in a knowledge factory, for instance a group who is developing changes in a digital service?

I have seen offices where "lean experts" from the factory floor has tried to apply the tools of the factory on what they believed was the knowledge factory gemba: the desks, the meeting rooms, the copier machines and office supplies.

That is of course ridiculous (and the result more so) since knowledge work isn't about shuffling papers around on a desk or having meetings. Knowledge work happen in and between people's brains. The gemba is the conversations between the people participating in the work of gaining mutual understanding of needs and how to meet them using digital tools.

We sometimes try to adopt the lean principle of visual management when we do service development. Scrum and other agile practices has borrowed the idea of the kan ban, visualizing the workflow maybe on a board so that we can see where we get stuck.

Sometimes managers, in the spirit of Toyota, wants to go and see what is happening on the "factory floor". If there is a kanban-board available, there is where they naturally will go. And sometimes ask: "What does the board tell us?" "Why can't people create visualizations of their so called 'work' so that we understand?" "We need to tell them what to visualize!"

The thing is that the kanban board, or any other visualization tool such as Jira or Trello, is not the gemba!. It is not the place where work happen!

The work happens in people's brains when they have a productive exchange of thoughts. In the conversations. The visual aids we might use are just aids for better conversations and collaborations.

So, if you are a manager assigned to help people doing knowledge work, please understand this:

It is NOT about "go and see"!

It is all about come and listen!

And share. And participate.

Scrum Hack: Rolling Wave Instead of Sprint

As those of you who have attended my workshop in agile planning know, you can talk about planning in two dimensions:

1. The percentage of your capacity you want to allocate to planned work.
2. The planning horizon: how far ahead in time you want to allocate that capacity.

The Scrum Guide implies that a team of developers will allocate 100 percent of its capacity to planned work, divided between implementation of backlog items that the team thinks are ready for development, and refinement activities where the team makes sure that the upcoming backlog items will be ready for development in the future. The planning horizon is a sprint: a regular period of at most one month.

However: the nemesis of all planning is that pesky little thing called reality. During a four week sprint, there are many things that can (and will) happen, so many teams feel that they have to shorten that time. Sprints that are two weeks long have therefore become popular even if it is hard for many to actually deliver value in such short time.

But since reality happens even during two weeks, you might feel the need to replan in the middle of the sprint. And this is where the rolling wave can start to happen if you let it.

When mid-sprint replanning becomes a regular necessity due to circumstances beyond people's control you may ask yourself what planning horizon you should have. Of course you need to replan the rest of the sprint (the last week), but can we say something about the future? The coming sprint?

(The replanning is by the way often conducted directly after daily stand-up monday morning in the second week of a two week sprint.)

The last week we learned that it wasn't wise to allocate 100 percent of our capacity to planned work. Maybe 80 percent is more realistic, so let us do that for this week too. And what do we know about the coming sprint? Maybe we can see the need for like 50 percent? At least for the first week, we know actually very little about the second week of next sprint. Maybe we for the second week of the next sprint can think of work worth about 20 percent of our capacity.

The week passes and it is time for sprint planning for the next sprint. We have already planned for 50 percent of the first week of the next sprint, and 20 percent of the second week. Let's just add some more insights to that plan so that the first week of the sprint becomes planned to 80 percent and the second is filled to 50 percent. (And maybe also look ahead for the coming two weeks after that but not more than like 20 percent of the first week and 10 percent of the second.)

Shouldn't we aim for filling both weeks of the sprint to 80 percent at sprint planning? No, we can't predict the future anyway. Let's keep it planned to 50 percent. We know that we will have a replanning event in a week anyway.

TADAA! The rolling wave is formed. Sprint planning becomes basically an adjustment of the rolling four week forecast that we polish continuously. We can still have our reviews and retrospectives every second, third or fourth week if we want to, but we have a more flexible planning practice in place that in many cases can accommodate the natural variation of development better.

Scrum Hacks: Scrum Buts or Scrum Ands?

There is a tension between the need for adapting a known and proven collaboration framework, and the need for said framework to be allowed to do its job.

I have during my ten years of agile, the last five years as a full time mentor and coach, seen countless of "Scrum" implementations where they had removed everything they found difficult and hard, and therefore didn't achieve what they wanted to achieve.

On the other hand: I have also seen numerous agile collaborations where they applied just the tools they needed at the time, tools that also can be found in different frameworks such as Scrum, but together with other tools and ways of working. And it has been working just fine.

I have during these same years only seen Scrum being run by the book (The Scrum Guide) once. Most of my clients work in environments where the implicit preconditions of Scrum doesn't really apply. So they have to adapt in order to get work done.

Adaptions of Scrum are sometimes called "Scrum Buts" since they are described with the words "We work with Scrum, but...". I think that's appropriate for cases where the organization takes away the things that drive good change and thus never achieves what they have set out to achieve.

I suggest the term "Scrum Ands" for the cases where your situation calls for a slightly different set of tools than what is provided in the Scrum Guide. For when you inspect and adapt the framework, in a way that gives you better outcome than the alternative.

The result of your toolset hacking will not be Scrum, of course. Scrum is defined in the Scrum Guide. Any deviations might be useful, but it will not be Scrum.

However, since Scrum contains most of the elements you need in order to make your collaborations more agile (organizational capability to prioritize, collaborate on value creation in self organizing teams, daily synchronization between people, clarity on what is ready for implementation and what is done, continuous improvement etc.), and since the framework is pretty well known, it can be a good idea to present your ways of working as your own twists to Scrum.

I call them Scrum Hacks. Distinct ways of collaborating that replace or complements existing ways of working in the framework. Like the idea of having retrospectives either more frequent or less frequent than each sprint. Or the idea to plan only one week at a time. Or having an ongoing Scrum meeting in digital channels instead of the daily fifteen minutes standing in front of the sprint backlog.

As soon as you start experimenting with Scrum Hacks, the result isn't Scrum. It can make your outcome worse. But it can also make it better. Reflect on why, and share your favorite hacks with your friends in the community. Let's build a catalog of proven Scrum Hacks that explains under what circumstances they have improved our lives.

What do you think?

Nimble Works!

I have started a separate blog for my posts written in English. Read about Scrum Hacks there:

Scrum Hacks: Scrum Buts or Scrum Ands?

The Benefit of Management by Fear

In general, the possibility to avoid threats and pain is a stronger motivator than the possibility to gain something pleasant. This is true for most organisms where you can talk about motivation at all. Responding to threats with fear and avoidance is apparently a good survival tactic.

And like all creatures that are dependent on groups to survive, we are particularly fearful of rejection, that the group will reject us and leave us alone in the wild. Which the group will do if the most influential individual in the group tells it to.

This is why management by fear is such an effective strategy for motivating people to work. If you have the mandate to reject people and make their peers reject them as well, you can make them do anything.

Or, not really. There are a few things that the fearful brain is incapable of doing. So if you are planning to use management by fear there are a couple of things you need to be prepared to handle yourself.

You need to define the tasks for your subordinates since their fearful brains won't be able to come up with the tasks themselves.

The tasks need to be perfectly thought out because your people will perform them even though everyone can see that the result is flawed. A fearful brain doesn't dare to criticize your orders.

You need to increase the checks and controls. If subordinates fears showing you mistakes that has been made you need to find other ways bringing them into the light.

(Extensive checks are also important for linking the necessary punishment to bad behaviour. A small part of uncertainty whether or not you will be punished will strengthen the fear, but uncertainty is a strong demotivator. Most punishment should come as a logical consequence of past outcome.)

The responsibility for planning and follow-up if things are going according to plan or not from now resides with you.

You must handle all the external relations. Fearful brains will focus on pleasing you and not your customers.

From now on you have to do all innovation. A fearful brain is incapable of experimenting.

Given that you are willing to assume these responsibilities, management by fear can be a great tool for your organization. The alternative is to create an organization of customer-focused, innovative responsible adults that can manage their own work according to the goals you set together. That will also require a lot from you as their manager, but it is a different set of tools.

When you can't iNvEsT

In agile development we have a backlog: a list of needs that we want to fulfill in a certain order. We also try to have a cross functional small team that take care of meeting the needs without having to handover stuff that must happen to other people. In certain agile frameworks (such as Scrum) the team shouldn't even have to interact with others when meeting the need so that they are able to independently take responsibility for a couple of weeks worth of work.

That means that each work item that meets a need (is valuable) also has to be small. We also want each item to be independent of the others so that we can give our primary stakeholder (for example the Product Owner role in Scrum) the opportunity to pick and choose any of the items in the backlog to be fulfilled.

In 2003 Bill Wake suggested that these three characteristics (I for "independent", V for "valuable" and S for "small") of a good product backlog item should be combined with the characteristics negotiable (in agile, a requirement is the starting point of a conversation and not the end of a discussion), estimable (just enough so that stakeholders can decide if it is worth it), and testable (if we can't test if a need is fulfilled or not, the need was probably not expressed clearly enough). And thus the acronym INVEST (independent, negotiable, valuable, estimable, small and testable) was born.

Now, while INVEST can be an ideal (since if we manage to make all of our items on the list INVEST compliant it is really easy to increase the agility in our development) many have found it hard, if not impossible, to achieve. So what should we do then? Abandon the whole idea? No. But think a bit. And know how to work with it.

The thing is that three of the letters in the acronym has everything to do with the organization. Why isn't the items negotiable? Why can't you reach a consensus on them? There is almost always a destructive power game present when people doesn't understand why the items on the backlog isn't the last word on how to meet a need or what the need is about.

Why isn't the item estimable? Are there hidden complexities that you haven't explored yet? Don't you have sound practices around refinement so that you know what it would take? And why isn't the item testable? Haven't you had all the required conversations yet? Doesn't people know what they want? Do you let people who know how to test things step up and participate in the item generation?

The N, the E, and the T are typically things that an agile transformation address, and it goes typically very well. It isn't that hard to create an environment where we collaborate on the items, negotiates what we would like to see done, make forecasts, and thinking about their testability. The problem usually resides with the other three.

Things can be cut into small partial targets. But in many environments, they are not valuable. Due to inherited complexity in the technical environment things cannot be small and valuable at the same time. They might be able to, later on, but not now. So we might have to slice down a valuable feature into smaller pieces, starting with a primitive version of the feature and improving it over the course of a few sprints. In the same manner, features may be dependent of each other and implemented and released in a certain order within a releasable package.

It is for circumstances like these a backlog split in three levels, as Dean Leffingwell suggests, is constructed. Closest to the team are the sprintable items that they can plan for and implement. A group such of sprintables is needed to implement a feature (the second level), and packages of related features that are needed together in order to generate business value (Leffingwell calls these packages Business Epics) constitutes the third.

The three tier backlog has its place when the items cannot be small, valuable and independent at the same time. It has been criticized for introducing complexity, but the idea is not to introduce complexity but to mirror the actual complexity we actually have to deal with. Then we can start to manage the complexity and hopefully work in order to reduce it.

Related: The SMIDIGT! module about the three tier backlog: documentation-the-backlog.pdf

Satisficing

I am reading up on Satisficing, a decision making strategy that aims at satisfying a need but just sufficiently. It seems like we, when making decisions, often go through a list of options until we see one that we believe meets our needs, given our mental models about needs and how the options will work out. We simply tend pick the first match.

Evaluation of options is hard mental work, and making decisions takes a toll on our psychological motivation. Therefore there will be fewer people who opt for trying to analyze all available options before making a decision (as a believer of rational choice theory would assume they do), and more people who are seeking an easier way out by evaluating as few options as possible (a behavior more in line with what proponents of choice theories of psychological realism believe).

We also have the systemic effect of weeding out those who tries to analyze every option when there is no complete list of options to choose from. They will never be included in the count of decision makers since they are stuck with analyzing. So when we are dependent on other people making a decision, we can expect that they for the most part are using a satisficing strategy.

What does that teach us?

First of all the importance of mental models when understanding your own needs and how they might be met. People will pick the first option that they believe will fix things according to their understanding of the situation. The way we talk about things, frame situations, use illustrations and parables will totally determine what options we pick. Make sure that the mental models reflect the actual situation.

Then that the order of presentation is very important. Any option higher up in the list will have a higher chance of being chosen, regardless of its effectiveness compared to the other options further down. So if we want to increase the chance of picking an effective solution to a problem we have, we should first try to quantify, or at least rank, the effectiveness of them before picking one.

And last but not least: since we use this and other decision making strategies that works against making optional choices, we can assume that our decisions will be bad. We can try to become better at it, but we must realize that we will make the wrong choices from time to time. So we have to employ strategies that reduce the bad consequences of a bad decision.

Here the preferences from agile decision making comes handy!

In agile, we try to make it small before making it big. Everything should be seen as an experiment that we run for a limited time, and then we can make a better decision whether we should continue or not. Is this good enough for now, and is it safe enough to try?

We will also try to optimize for options when we decide. Given two paths, if we chose the one that has many branches ahead we can always change course as we learn more about our goal and how the reality works. Making definitive decisions early on when we have access to very little information may sound cool and you feel like a Powerful Leader when you do it, but it isn't really the most effective thing to do. Maintain your flexibility at all times.

The journey to value creation is a journey of insights. What we grow together is the body of knowledge. When we investigate our options we should look out for the options that gives us the most learning opportunities. If it is impossible to be sure that we have picked the right option, it becomes very important to quickly learn if our chosen path was the wrong one to take. That will increase the chance of making the next step on the journey better.

And when evaluating and learning, remember the words of Deming: "Without data you're just another person with an opinion". But also from the same man: "The most important things cannot be measured", and "The most important figures that one needs for management are unknown or unknowable".

Happy decision making!

Agile is no joke

Agile methods are sometimes perceived as something less serious than the alternatives. Especially by those who have very little experience in using them. A vague understanding of early texts on agile methods such as "The Agile Manifesto" leads people to think that it is all about ditching methods, tools, documentations, contracts, and plans, and nothing more. An unstructured dream for the immature, a nightmare for the rest of us.

But it couldn't be further from the truth.

Emphasis on using structured tools that support changing circumstances comes from hard evidence showing us that it is impossible to create strict plans for product development and expect them to hold. Predictability is not an option, regardless of the method used. Therefore we use methods for planning and forecasting that takes variability into account. Inherent variability doesn't go away by pretending that it doesn't exist. Instead: ignoring it exposes you to a tremendous risk, as available data on expensive IT failures show us.

Building the capability to handle variation in plans caused by unforeseen events gives us the benefit of being able to handle actual changing requirements continuously, even late in the process. While changing requirements could be a side-effect of an organization that doesn't understand what they need, it is more often caused by the growing body of facts about the problem and its possible solutions.

We all know that our body of knowledge about the situation is small early in the process and larger as time goes on. All decisions should be made in the last responsible moment if we want them grounded in facts rather than guesses. By using methods for continuous risk management and prioritization based on optimizing for options, this discovery process becomes more painless than being forced to stick to misguided decisions made way too early.

With a method that can incorporate newly found insights on the needs of the users and the market, we increase the chance that what we build will be effective. Agility isn't about efficiently creating everything that random people in the organization ask for, but being precise in meeting the actual needs of the most valuable users. It is about quickly investigating large sections of the solution space and focus on the most beneficial ones, both cost and value wise. The number of changing requirements is not a negative KPI but a metric of increased knowledge.

In order to achieve this, we can never be in debt. Our product must be ready to meet the current reality. No waiting for tests, for more documentation, for productivity enhancing refactoring, or for improved usability. When we are done with a small increment (which we should be regularly) and have deployed it into production, we are done. Our product is usable. Ready to generate value. Our quality assurance strategy are therefore way better than in the older methods, or else we couldn't have this. Modern proven testing strategies and a lot of automation is at the core.

The way we make these things a reality is by extensive amounts of teamwork where organizational borders are crossed (or crushed) and lots of delegated mandates where the teams has a growing amount of decision making power. Delegation is not about letting things go, but about building capability for self-leadership and responsibility in the collaborations of the organizations.

All this isn't possible if we don't choose to use management principles grounded in modern psychological and mathematical science. The foundations for making these things work have been known since at least the 40s-50s, and today our knowledge in both psychology and systems thinking is way better. It is therefore no joke or hippie dogma when we ask management to update its principles on how value is measured or on how governance and leadership is supposed to be done in an organization.

Agile is no joke. It is for real, it is grounded in solid principles and hard evidence, and if you want it you need to really consider what it requires from you and your organization.

The Appreciation of a System

It is not the parts you should look at, but their interactions. Observing the parts will not reveal the pattern they create together and can cause you to make faulty assumptions about the performance of the whole. You may also be tempted to influence the parts in ways that isn't helpful when you don't consider the total effect of your influence.

Observing and trying to understand the elements as isolated units is suboptimal if you want to manage the system that they are a part of.

The understanding of what it means to be a system is one of the four pillars of William Deming's System of profound knowledge, a set of insights regarding management in complex environments that even though being more than 30 years old has become increasingly important in the age of digitalization, disruptive innovation, and organizational agility.

Deming made a point by addressing top management and trying to get them to understand the importance of systems thinking. He realized that if the top management didn't get it, they would never be able to create an environment where the performance of the whole was improved. Everyone would be stuck in their compartments making sub optimizations to the detriment of all. And while it is still true that a top management who lacks understanding of system behavior will ruin it, organizational agility also demands that that every person in the collaboration share these insights.

It seems like the human mind has some difficulty grasping aspects of systems behavior. We tend to believe that the outcome directly reflects the behavior of the parts, or the intentions of the people acting in the system. Instead it is perfectly possible and actually quite common that smart and kind people cooperate in ways that makes the system become like it was run by an evil super genius or an infinitely stupid autocrat. We assume that low performance of the system is a function of low performance of its parts and fail to understand why the system actually performs worse when we force the people in it to work harder.

I believe that it is of utmost importance that we all improve in our systems thinking ability, especially if we are in a position where we design performance metrics or tries to govern system behavior. In my work helping organizations to increase their agility I have found that all four parts of doctor Deming's system of profound knowledge are essential for everyone, and that systems thinking is one of the hardest things to teach and learn.

As of now I am creating a course module that will cover the basics. The thing that I find being the most difficult is dividing the insights in easily digestible chunks. It kind of goes with the subject that understanding the parts of it doesn't necessarily help when understanding the whole!

I am really interested in what you think about this. What questions regarding systems thinking would you be interested in? What is it that you feel is the most difficult things to understand about the subject? I would very much appreciate if you would take the time to reflect a bit about that and maybe share some of your thoughts with me.

Flow is the general concept

One thing I often hear when I talk about creating effective service delivery or development and mentions its root in the Toyota Production System is that it would be a bad thing to use insights from manufacturing in other domains. There seems to be a fear that using ways of thinking from a production system automatically will make one treat everything and everyone as things to produce or cogs in a machinery. Seldom that criticism comes from people who has knowledge of what the thinking from Toyota actually says, though.

While it is true that some of the techniques that Toyota invented in the 50s and the 60s are only applicable in a manufacturing context, most of them are about general human concepts such as leadership, human collaboration, improvement of quality, and last but not least: flow.

Value is about meeting human needs. A value stream is what we call the organisation around the sum of all things that is done to capture and understand that need, and to finally meet it with a delivery of some sort. A smooth and fast slow is what we aim for since that would increase the value output per time unit.

Henry Ford optimized for flow when he designed the Highland Park factory that opened in 1912. Frederick Winslow Taylor optimized for flow when he wrote The Principles of Scientific Management in 1911. But even if the methods these persons enforced to increase flow such as predefined work divided into repetitive moments isn't suitable in any context outside of manufacturing (and maybe not even there), the aim for a steady output of value was not wrong but something that increased the income so much that they could pay the workers way more than the workers in other factories.

Flow has always been a core factor in successful service delivery: how do we handle a huge variation in demand and still provide adequate value to recipients? And what is true for service delivery tends to be true for product and service development as well. The Wright brothers solved the problems of creating a propelled heavier-than-air flying machine by a steady series of many experiments, and so has effective development work been conducted ever since, including within Toyota.

Lean thinking has from the beginning been about general concepts such as mathematical facts about collaboration systems in general and psychological facts about the human nature. The two pillars of lean is the continuous improvement of the flow, and respect for the fact that we people are as we are. William Deming's system of profound knowledge is based on the same two fundaments: flow (understanding systems and variation), and psychology (understanding knowledge and the human mind and behaviour).

If you are interested in general lean concepts I recommend This Is Lean, The Machine That Changed The World, Gemba Walks, Lean Thinking, and Toyota Kata. If you are interested in lean service delivery I recommend that you look at Vanguard by John Seddon. And if you want to implement lean thinking in knowledge work, I recommend that you check out Lean Software Development by Mary and Tom Poppendieck. For a thorough walkthrough of several economic principles that apply to product development using lean thinking, I recommend Flow by Don Reinertsen.

It s all about flow, not about factories and manufacturing.

How long should I have to wait?

After being asked to explain why I and others don't believe that a project is the best way to organize development of services that involves digital assets, I thought that I should try to do that. But I am not interested in bashing projects, but explain what requirements digital service development has on its control structure.

What would a reasonable control structure for development of digital services, a "project method" if you want to call it that, look like?

Services are about meeting human needs, and the question we have is how we can organize a collaboration, a system of people, to be able to meet those needs. As anyone who has had a need knows, one of the most important metric in service delivery from a recipient point of view is the "cycle time": How long should I have to wait from the moment someone has discovered my need until it is either met or rejected?

There are other metrics that are important as well, but the cycle time is special since it both has a strong economic impact and is an indicator of many other things in the system. The value of a delivered service can be translated into a cost of not having it delivered, a cost of delay, so it is fair to say that a suitable project method need to make it possible to optimize for short cycle times.

There are luckily a lot of ways discovered how to reduce cycle time, many that have been discovered by japanese industries in the 50s and 60s. One of the most important ways is to reduce the batch size of everything. Small work packages will flow faster through the system, while large batches increase the variation within the system and cause the system to underperform. So the project method should be able to handle several small batches of changes to the service in parallel rather than focusing on larger change.

The value is created when we meet human needs. It is not created when we spend time on activities. Activities are costs, while meeting needs is valuable. What activities that in the end will lead to value creation is something that unfolds during development of a service. It is impossible to say in a complex environment that we now know what sequence of activities that will lead to value creation in the end. We can guess, and at some point in time create a plan out of our guesswork, but the risk is high that the sequence of activities in our plan needs to be modified as more information unfolds during execution.

So what we need is a project method that allows for continuous replanning of the needed activities. The method needs to keep track how far we are from the goal of value creation, allow for continuous discovery of the best path to the goal, and helping the particiants in doing constant evaluation, discovery of needs and paths, and creation of new plans and forecasts, in a coordinated way.

Good coordination between people is hard to achieve. It takes time. Luckily, while the different changes we want to implement in our service really are separate pieces of work, the very domain where the value creation takes place stays the same. So it is possible to form stable collaborations of people who knows the domain both in a business sense and in a technical sense, and help them making their joint work effective. So the project method needs to support stable organizations and avoid temporary ones.

The discovery of needs within a domain often has a pretty stable rate. Especially when you are going digital. Most services need continuous development in order to stay fit for purpose and be competitive, so there is really no end state here. We will probably always find new needs to meet and will always need to find new ways of meeting them. So the project method should be able to go on forever. Managing constant funding and value generation.

Now, constant work in a constant organization doing continuous small batches of changes in order to meet a need in an exploratory fashion isn't what most project methods are designed for. There is in fact already a name for what I have described here: service life cycle management around value streams. That is a model for development that suits digitalization pretty well and gives the business the agility to experiment with fast feedback loops.

I don't suggest that we abandon projects, but that we realize that they are best suited for large changes that requires a temporary organization and where we actually can create those detailed project plans (often broken down into who should do what activities and exactly when) that the project methods prescribe. For going digital, I instead suggest what I have mentioned above.

ALMA - Sponsorship

We have an intuitive notion about leadership and dominance that affects how organizations traditionally have been governed. While coordination is necessary when many people want to be productive together, relying on our primitive intuitions are in many cases not the most effective way. The issue of governance and management need to be addressed in a more thoughtful manner.

In ALMA we regard governance and management just as a bunch of Capabilities (realized by Processes). Since the Capabilities needed for good governance have a special impact when it comes to the design and the performance of the organization, we consider them with extra care and group them under the overarching theme of sponsorship.

Under the umbrella of sponsorship we group all Capabilities (and Processes) that provides

Direction — Saying that we should meet the needs of people is a no-brainer. Saying what needs to meet is something that requires a thoughtful decision. Pointing out the purpose of the collaboration and in what direction everyone should go is part of the sponsorship.

Prioritization — If you are experiencing conflicting priorities, for instance if you have encountered a bottleneck in the organization's ability to deliver, you need clear direction on how to prioritize. Either directly where you bring up the issue to a board or an individual, or indirectly via rules - general or more specific - that you can rely on.

Approval — If you aren't sure that an agreement is within the line of what the organization needs, or if you feel that an agreement between parties isn't being upheld, you need to escalate this to someone who can take a look at the whole and decide what to do, from a holistic point of view.

Resource allocation — In order to do something you need tools, time, and friends. In an organization, these three have a cost (at least the cost of not being used elsewhere), so there is a need for a mechanism that can make these kind of allocation decisions in a fruitful way.

The responsibility of the Functions that provides sponsorship Capabilities is to guarantee that what they do is in line with the purpose and limits of the whole organization. Functions that provides sponsorship Capabilities should be aware that when they are needed, they are needed quickly because something that no one else can solve is currently blocking the value creation. This is why many lean and agile organizations tries to distribute the sponsorship Capabilities to many Functions by extensive delegation. It is also why many of them also have instituted rules that states that no issue can be lying unsolved more than 24-48 hours before it is escalated to the next higher hierarchical level.

A common way of organizing this in effective operations that handle life-and-death situations (like in the military or at hospitals) is to always have an appointed person in charge of sponsorship decisions at all times, and make sure that this person has the necessary backup when needed.

Remember that no matter if you are a private or public company, or if you are a governmental or non-governmental non-profit, there is always an underlying power structure! Things and time are owned by people, as individuals or in a collaboration, and law-makers have connected certain responsibilities and rights to this ownership. ALMA opens up for delegation, collective decision making, and other forms of distributed responsibility. Note that this is done in order to create effective power structures, not to ignore the issue of power!

A "manager" in a more traditional sense would be a Function consisting of a single individual who are responsible of providing all these sponsorship Capabilities. It is an observation that in a complex environment the burden of all the sponsorship responsibilities is too heavy for a single individual to carry. The processes need expertise knowledge in many areas. By regarding them as Capabilities that can be provided by many Functions, where each Function is made uf of many individuals, ALMA opens up for the possibility to create a more effective leadership that won't burn out people.

There are reasons to abandon the concept of "managers", but management will always be needed!

ALMA - Services, Functions, Processes and Capabilities

The distinction between services, functions, capabilities and processes is borrowed into ALMA from other service management frameworks, but with an agile and lean twist. The insight that capabilities of the different collaborations in the organization are central are borrowed from the emergent practices of capability mapping and agile enterprise architecture.

A Service is something that a person would happily use if we were to offer it on its own. "Fork Delivery" could be a Service on its own, but in the context of a lunch restaurant people wouldn't be happy if they didn't also get the plate, the food, spoons and knives and chop sticks when needed, and so on. "Fork Delivery" is therefore more likely a part of the Service "Lunch Delivery", and not something valuable on its own. A Service meets a human need all the way from the notion of the need to delivery.

A Process is the actual way of providing the part of a Service. When we perform our Processes and measure them and design improvements for them, it is important that we consider the whole Service and the human need it is supposed to meet. Else we run into a huge risk for sub-optimization which breaks the principle of flow.

A Capability is what a part of an organization needs to have in order to provide their part of the Service. It is distinct from Processes in that a Process defines exactly how a part of a Service should be done. But defining a Service in terms of exactly how it is delivered will be against the root principle of improvement. We need to be able to investigate different ways of providing a Service, and as long as we provide the needed Capability, we should be free to experiment how to do it.

"Fork Delivery" would be a Capability needed to provide the Service "Lunch Delivery", and we can experiment how to optimize the fork delivery in numerous ways. The larger investigation whether we actually need forks at all must also be possible to do in the name of improvement, but that would require that many more people would be involved in the experiment. In the small, within the limits of a Capability, people should be free to experiment without having to ask.

A Function is an organizational entity: a group of people who work together performing one or more Processes. An individual can be a part of several Functions but be aware that this can lead to priority conflicts within the individual, unevenness in their work, and overburden. People need to have a home. It is better for one person to belong to a single Function.

A Function can be represented in another Function. People from one Function then participates in the other Function's work. This is great for Sponsorship Functions (management and governance) where limited resources have to be distributed and priorities be made. By forming the governance Function by asking the Functions that are closer to the gemba for representatives, we ensure that the decisions made by the Sponsorship function is more in line with reality (the principle of empiricism at work).

By handling governance in this way we also combat the misconception of the organization as a hierarchy and lower the risk that it will be misused as an arena for persons to play games of political power. There is a power structure in place that should be recognized and designed in an effective way, but the presence of a power structure doesn't mean that forming hierarchies is a good way of governing it.

A Function may handle one or many Processes. A Service may be delivered by using only one Capacity, performing only one Process. But it is more common that the Service will require many Capablities, and therefore potentially many Functions in collaboration. They really must cooperate well in both designing and operating the Service, defining the Capabilities and their interaction.

It is often efficient when a Service is delivered by Capabilities and Processes that all can be performed within one Function. The Function can then experiment with improving the whole Service. It is resilient if many Functions can deliver the same Service in parallel so that more needs can be met faster. It is seldom efficient but brittle if a Function consists of only one person. Dependency on single individuals make the organization vulnerable. People need to have peers.

ALMA -The Core Principles

The core principles of ALMA are

Sustainability. As long as a service is useful it should sustain. That means that everybody involved in the service needs to continuously improve its sustainability. This includes being sustainable environmentally, mechanically, economically, and humane in respecting the limits of people. This combats the disease of overburden (muri), which is a source of much waste but often disguised as value ("Come on, of course you can push it a little harder!").

Flow. Smooth out unevenness, batches, variations, waiting, where it can be done without breaking the first principle. Unnecessary variation that can be removed without making the service less valuable should be removed by clever inventions. Variation that is caused by the inherent variability in the human nature shouldn't be removed but handled, by clever inventions. This combats the disease of unevenness (mura).

Effectiveness. Do the right thing. Don't do the wrong thing or the useless thing. Don't try to make more of what is not the right thing. What is good enough for now and safe enough to try? Do that and proceed. This combats the disease of wasteful actions (muda). Remove waste, but not so that you introduce unnecessary unevenness or overburden.

These three principles will result in a truly efficient flow, but efficiency is not a core principle of ASLA. This is because when you aim for efficiency, you often fall in the trap of suboptimization by trying to maximize resource utilization in all parts of the flow. This causes overburden on people and tools, work waiting in queues which is a terrible waste, overproduction in parts of the flow which makes other parts of the flow instable, and in numerous other ways worsening the output while increasing the cost per item.

In order to sustain an effective flow, you need to build upon the foundation of the gemba, the floor, the place where value is created and waste is discovered and removed. The foundation is created as we saw in the section about the gemba from two other principles:

Transparency. Overburden, unevenness, and waste always hides. By making things visible, we enable action built upon empiricism (real data and true understanding), and so supports

Empowerment. It is the people who are doing the work that should decide on how the work is done. This means that they need to be enabled, not only by transparency, but also by given the tools and abilities to act in a fruitful way, and given the permission to do so.

So: try to improve the flow in a sustainable way by looking at the whole, work together with who you are and what you have got, stop doing what is not valuable, and respect the principle of the gemba: make everything transparent and empower people to act for the better upon what they see.

ALMA - Gemba World View

The Agile Lifecycle Management Anatomy borrows an important concept from the thinking behind effective management in Japan: The primary point of view should be the view from the gemba. "Gemba" is a Japanese word that means something along the lines of "the place where the action is". A TV reporter from a crime scene would say: "I am standing here right at the gemba...", and when Toyota's Taiichi Ohno went down to the factory floor to see for himself what was actually happening, he would say: "Let's go to the gemba!"

The "gemba" is the place where the value is created. Everything important in the organization depends on what happens on the gemba. This world view has some implications:

Transparency - Everyone needs to see reality as it is. This trumps people's wish for controlling information in their part of the organization (unless secrecy is motivated by the work where it must be clearly stated and regulated by transparent principles). Transparency is the nervous system of the organization, and must be supported by the tools and the ways of working. This enables all decisions being made based on empiricism: data and validated hypotheses.

Empowerment - If the value is created on the gemba it is important that the people working closest to the value creation are empowered to also control it. Like in all collaborations, the control is always bounded: the direction you as an organization is heading must be agreed upon, and you must know the limits for what you can do without asking anybody else.

You need mandate in order to be empowered. But you also need the resources: time, tools, and abilities (which can be provided to you by friends). Without the resources it is not possible to do anything useful of your mandate. Everybody in the organization needs to be embedded in a governance structure that can provide guidance on direction and limits, as well as the time and the tools and the other resources. This governance structure can be flat or hierarchical, based on individuals or on teams, and delegate much or little decision power.

Experience has shown that hierarchies based on individuals that perform top-down management is superior to having no management, but that flat team-based organizations where people have a lot of decision power is superior to top-down hierarchical management when there is competence to act in that environment.

An agile environment often falls somewhere in between while aiming to continuously become more team based, flat and empowered.

ALMA - Core Processes

Borrowing from a popular framework for managing IT services, ALMA defines three core processes:

Operation, which is when we deliver the service.

Design, which is when we think about how the service should evolve in order to meet human needs better.

Transition, which is when we make the new design become the new normal.

Each of these processes has their own focuses:

Operation is about consistency within the limits the service is designed for. Manufacturing operation often try to minimize variation in order to produce consistent products. Personal assistants often try to maximize the ability to handle variation in order to meet different needs. Most operations are somewhere in between. We try to optimize the allowed variation. The thing is that everyone involved in a service should know what they provide and under what conditions, and what to do when the the conditions doesn't apply such as when the limits of acceptable variation are violated.

Design is about being sensitive about needs not currently met properly by the service, and inventive about possibilities to meet those needs. This is an ongoing process that involves everyone. The collection of ideas and the possibility to try them out should be built into the daily operations process.

Transition is about being gentle when changing. We avoid scary big bang changes and instead aim for continuous evolution. Services are constructed by different kinds of parts: humans in functions, digital components, infrastructure, facilities, other assets etc, and each part requires a certain kind of care when changing.

There are other processes as well, but these three are the main ones and many of the tools and techniques in ALMA are meant to be used within one of them.

ALMA - The Service Perspective

ALMA is not centered around projects. Not even around products. In ALMA the focus is around services. What is a service? A famous IT service model defines a service as:

a means of delivering value to customers
by facilitating outcomes customers want to achieve
without the ownership of specific costs and risks

A core assumption in ALMA is that anything worth doing in organizations can be seen as either providing a service or making an existing service better. This is in line with this definition of what a service is. Let's have a look at some central themes:

Delivering value. If we are not generating value, the effort is worthless. Value is about meeting human needs. The human can be a paying customer, or otherwise in the position of receiving the great things we provide. The service perspective is equally valid whether we work in a private enterprise or are parts of a non-profit or an organization within the public sector or the government.

Facilitating outcomes. In order to be valuable you need to make a difference. Being just a hand in the middle is waste. We contribute by facilitating outcomes, that is making a certain outcome more probable than otherwise. We matter!

Without the ownership. We own the service. The receiver of our delivery may or may not own the result of our service. But even if we are creating and delivering physical products, what we provide (product development, manufacturing, and shipment) are services to the customer who doesn't have to take the risk of development and manufacturing themselves. They may own the result, but our organization owns the process.

This service perspective, focused on meeting human needs, is crucial for making ALMA work. Everybody needs to lift their eyes and focus on the purpose of why we collaborate. This little meditation may help:

Instead of work, think project. It is not about the effort but about the outcome.

Instead of project, think product. Projects are temporary, we need to focus on continuity.

Instead of product, think service. Products are just, at best, containers of value.

Instead of service, think needs. Our service may shift, but meeting needs is the eternal purpose.

ALMA - Agile Lifecycle Management Anatomy

So, I will try to collect and present what has been written by me here on the blog and elsewhere on how to achieve organizational agility by practicing agile life-cycle management of services and products. An agile organization is like a fit body, and here is a description of its anatomy.

The anatomy points at a structure. There are certain functions you need to have in place in order to make the body move, and it might be that your current organization need to adjust a bit in order to make it work, but it is not an organizational chart per se. You can make it work in a lot of different organizational structures.

The anatomy is founded on a certain set of lean and agile values and principles. Body structure is one thing, it is how you decide to move the body that will make it fit. And decisions on action comes from what you, as a group, value and what guiding principles you are used to.

Organizational agility has during history been improved in lots of environments, using many different techniques. Some of the techniques are very domain specific, such as extreme reducing of variation in a manufacturing environment, while others, such as self organized teams, can be applied almost anywhere. Agile life-cycle management is therefore not one single set of techniques, but rather a toolbox, used within a context of agile thinking around value, service, and product. The anatomy and the values and principles gives the people guidance on when and where one should use a particular tool.

I would like to describe how to make this work, and I hope that you can find guidance on how to transform a bit of your world into becoming more agile.

Infographic: Kanban Board

Next infographic from the SMIDIGT! modules: suggestions how to set up and handle a kanban board in order to track your work and improve the flow.

Download the infographic here: infographic-kanban-board.pdf

Infographic: Scrum Board

The updating of the SMIDIGT! course and coaching material continues. Here is an infographic from the course module "The Daily Meeting": a collection of facts and suggestions regarding how to use and set up a scrum board.

Download the infographic here: infographic-scrum-board.pdf