Trust Is A Must

December 23, 2016

We all know that Agile is as buzzword-ridden as anything else that helps people generate an income. There are a lot of gems among the buzzwords associated with agile ways of working though but a lot of the time we tend to take them at face value and not look at where and how they fit in. I’ve been looking at some agile practices and tried to reason around the relationships between them and one of the things I realized was how essential Trust is in order for most of the other practices to work. You can fake a lot of things but if Trust is not truly there so many of the other things we try to do will not only fail, they might also make things worse.

trust-is-a-must-iiOne practice that has always been at the essence of agile is Transparency; we want everyone involved to have current and correct information. Adding a window to a solid brick wall won’t offer any Transparency though. We can’t buy Transparency in the form of a whiteboard. Worst case scenario, the whiteboard only serves as giving credibility to lies, useless data and wishful thinking. Transparency needs to be combined with, among other things, Trust and Autonomy to provide value. The “Transparency” offered when Trust is lacking will never be true Transparency. It will be a display of what the team believes that people around them want to see. It will be fidgeted numbers such as story point inflation, velocity boosting with “almost-done” stories and smokescreens hiding work performed under the radar. In short, any “Transparency” offered when we don’t have Trust or we suspect that we’re not Trusted will be a pile of lies.

So if we add Trust, will that transform Transparency to a valuable practice? I’d say no. Not unless we also add Autonomy to the equation. A team that is not Autonomous will always have dependencies to people and teams outside the own team in order to deliver any business value. When all a team can deliver are small parts without intrinsic value, the data that come out is mostly worthless. No true progress can be shown, only task completion. In any cases but the truly basic ones, task completion won’t give us much information regarding how close we are to realizing any true value. The complexity of what we do will hide a plethora of new challenges behind every completed task. Challenges that only surface towards what we thought would be the end, when we put everything together. In a similar way if we have an Autonomous team that lack Trust and/or Transparency, they are potentially a true danger to the organization. If they act without Trust, it will be a high stakes lottery ticket where there might be a brilliant idea in the jackpot but more likely the team will be a liability that acts without any information sharing with the rest of the company. Adding Trust could be a way to better the odds of something good coming out but without Transparency it will not be aligned with the rest of the company and its strategies.

Before adopting the next good practice, see where it fits in your context. Look for the untold prerequisites for the practice and consider if you fulfill them. Do you have the necessary mutual trust in your organization? And remember that trust ISN’T earned; it has to be offered in advance because people WILL act according to the expectations that are offered to them.

I think most of us agree today that learning is almost always a bottleneck for our development projects. When asking people after completing a project how long it would take them to do the same thing all over again, the answers usually range between 10-50% of the time it took the first time. The second time around all obstacles involving learning would be removed and everyone could focus on producing. This is where agile methods and practices come in; designed to facilitate fast feedback and fast learning cycles to improve on the lead times.

When it comes to new product development (NPD) most organizations that I’ve come in contact with have a tendency to lose severe amounts of calendar time before the actual development begins. When I started looking into the Fuzzy Front End (FFE – “the phase between first consideration of an opportunity and when it is judged ready to enter the structured development process”) of NPD with a colleague of mine to see if- and how agile ways of working could help during this phase I came to realize that even though learning is what we try to do at this point, the real bottleneck is usually decision-making. Many organizations don’t have a set of business rules to guide them during the decision process for new products and even people on CxO positions are often paralyzed by the Parmenides fallacy; action is more dangerous than inaction.


It doesn’t make sense for us to speed up the other activities of the FFE if the organization is going to waste that time on procrastinating on decision-making. So what can we do to speed things up a notch? It’s been argued that the FFE-part of NPD has an inherent uncertainty and ambiguity to it that makes it an ill fit for structured processes. Be as it may with this (I’m quite certain that we can do innovation and be creative within a framework as well though), the decision process that runs in parallel with the creative processes can definitely be sped up. With a good enough set of decision rules, any company can limit the impact of decision-making as a bottleneck.

When entering the NPD-process, we should frame the research within the limits of our corporate strategy. This will tell us what kind of opportunities to look for. Do we have a plethora of service- and product options to explore or should we stay focused on a given market segment and type of solutions? Are we Google or are we a cab company.

We should decide beforehand on the level of risk that we’re willing to accept. Are we willing to explore completely new products? Are we prepared to explore new technologies? Are we willing to create new markets? Or should we perhaps stick with extended product capabilities?

What level of organizational change are we willing to accept in order to develop and/or produce new products or services? Can we kill an entire production unit and build a new service organization? Or do we have difficulty even to introduce a new role to our organization?

How much are we willing to invest in exploring new opportunities? What payback time do we expect?

Most of us aren’t working for companies like Gore, Google or 3M. We might like to believe that we have the freedom to explore all kind of opportunities but if we snap out of this dream before we act on it, we can become a lot faster at following up on new ideas. What we need at the beginning of our NPD process is to:

  • Make all constraints explicit
  • Decide what data is needed to make a decision
  • Commit to innovation within these constraints

And don’t forget to combine fast decision-making with validated learning and agile practices to minimize the impact of poor choices, because the decisions will not always be perfect. But then again, neither were the decisions that used to slow us down.

Have you ever experienced working in- or with “teams” that never seem to get to a state of working together as a team? I put the word teams within quotation marks since these aren’t really teams, they’re just administrative units. This has happened to me a couple of times and no matter how much we struggled with trying to get everyone on the same page through working with visualization, teambuilding, meeting formats, goal setting, work spaces etc, everyone would go back to their desks and continue to work as fractions. I’ve gone through several phases of explanations and rationalizations in my attempts to explain to myself why we had these problems. A while back Esther Derby introduced me to Glenda Eoyang’s work describing the effects of containers on systems and that really put the spotlight on some of the driving forces behind our problems.


Basically a container is something that bounds one part of the system from another and constitutes a difference. Containers can be:

  • something physical such as walls, desks or cubicles that separate people or unite people.
  • of organizational nature; people reporting to different managers, belonging to different departments or being hired consultants as opposed to employees.
  • something conceptual such as purpose or rules.
  • behavioural, e.g culture or family situation.

The effects of these containers will greatly affect how people are going to work together. Some of them will work in favour of collaboration while others will drive a wedge between people. When I began to model the containers that I could identify within the troubled teams it was really easy to see how many things were pulling people apart instead of holding them together.

People may have been assigned to the “team” and in best case even be co-located. We might have a unifying goal of delivering a product or service but that’s where the positive forces ended. Then people would be experts belonging to different organizational units. They would be reporting to different managers. They could get input to their work from different sources. They would be seated together with a few people with the same kind of expertise. They belonged to different budgets. Their personal goals were set with different managers and not aligned. They belonged to different subteams. They would have to work on other projects outside of the dedicated “team”. Etc. Etc. Etc.

Seeing all these forces working against us made it clear that we had a snowball’s chance in hell of building teams that would actually work as teams. For every action we took to align the team members there would be ten other actions around us that pulled us apart. My guess is that if we would have come much further if we would have focused more of our energy on identifying and redesigning the root causes of the forces pulling people away from each other instead of performing a tug of war with these forces.


Some time ago I was asked to work with a “team” that “had problems delivering” and “the few things that did come out of the team was of poor quality” and as if that wasn’t enough, “people were generally not happy about working in the team”.

The “team” – it turned out, consisted of a handful of developers. They got their work from a couple of different business analysts in different parts of the organization and when they were done coding, assigned the work to some testers in another part of the organization. Before taking on the assignment I made one request and that was to get to work with all three disciplines as one team; requirements, development and test. We did a lot of different things together in order to overcome the challenges but the one thing that made it at all possible for us to create a high performing team was the tearing down of old containers and building a new one around the team.

I’m sad to say that the reason I’m so certain about the power of the containers in this case was that as it turned out, the company structure wouldn’t allow for this organization in the long run. Soon after I left the team, group managers once again split the team into three parts; requirements, development and test, each group with their own team lead. None of the other practices we had put in place were strong enough to withstand this break-up and pretty soon everything was back to square one again.

My lesson from working with this team was that it’s not enough to learn to see these invisible structures, we also need to see the incentive systems that put them in place. But I’ll save that for a later post.


The Need to be Needed

January 10, 2014

“A bee is never as busy as it seems; it’s just that it can’t buzz any slower.” – Kin Hubbard

A while back I was coaching a project that was to a large extent staffed by people being experts in narrow fields of expertise that also had other commitments outside of the project preventing them from having any slack time what-so-ever. This constituted quite a big challenge because they all took turns to act as bottlenecks in the process so I decided to run a retrospective focused entirely on how we could free up more of their time in order to improve the flow of work.

The initial reaction I got was almost enough to give up on the idea entirely. Almost everyone started moaning about management and the organization being the problem.
“Tell them to not dump all this work on us.”
“As long as we have to do projects as well as maintenance this will always be a problem.”
“I have to support so many projects that I’ll never be able to set aside any slack time.”

With the support of the project manager though, I decided to run the retrospective despite the chorus of geese shaking off the water. The setup was quite simple; we divided into groups of three and I asked each group to work according to the Iroquois “Rule of Six” to come up with at least six plausible reasons for why key people in the project were constantly overloaded with work. I asked them to specifically look for reasons that were in our reach to act upon. The result was amazing. All groups managed to present at least a handful of reasons showing how we all were responsible of creating this problem.
“I say yes to almost anything.”
“I don’t trust other people to do a good job.”
“I ask other people to help me with stuff without checking if it’s prioritized.”
“I don’t prioritize the work that comes in.”
“I create work that has not been asked for.”

I was overwhelmed with the candidness and maturity in the answers. This was great; we had found so many things that we would be able to act on in order to ease up on our own as well as our peer’s workloads. With this smörgåsbord of possible actions I didn’t want to do a prioritization to select one or two to implement during the upcoming sprint. Instead I asked if we could take as homework to do a daily act of kindness to ourselves and someone else. Could we at least once a day stop to think if we were about to act according to one of the patterns that we had found and instead take another road?

This is where things started to get interesting again. Amidst the nods and yesses I detected some hesitation as well. The hesitation wasn’t spoken out loud in any way but it was in the air so I asked for a fist of five. Could everyone on the count of three please raise a hand showing their commitment to this homework by showing any number of fingers between one and five?

  • Five fingers being “YES! I’m really committed to this, count on me.”
  • One finger might as well be the middle one; “There’s no way in hell that I’m doing this.”

All people raised four or five fingers except the three persons being the most overburdened, they only held up one or two fingers.

When I asked what made them hesitant about doing this daily act of saying no to another task or not handing unprioritized work over to a fellow project member, they all fell back to the initial reaction of pointing outside their own sphere of control: “It’s not possible to say no.”
“If there’s a production problem it has to be done.”
“We have to do this even if it’s not prioritized.”
“Quality will suffer if we don’t do this.”

I’m not entirely sure if the conclusion I came to after this meeting was correct or not but I suspect that these people thrive on being busy. It could be external factors such as explicit or implicit rewards and/or threats that make people act in ways that puts them in the center of everything but having seen the same people end up in these situations time after time in different positions at different companies make me think that the problem often is self constructed. Some internal belief system or internal reward system make some people act in ways that is hazardous to not only their own health but also the productivity of the team that they work with. I don’t have a turnkey solution for this problem but I would ask everyone to consider this possibility before going about redesigning the organization or taking any other measures on the system.

The problem might not be that we force people to work too much, it could very well be that we allow them to work too much.

– It’s 42 boss.
– …
– Yes boss, that’s higher than the 5 bugs we had a couple of sprints back.
– …
– No boss, that was the sprint when we spent the majority of the effort implementing the configurable splash screen and the easter egg TicTacToe-game. The features that you predicted would triple our sales.
– …
– Yes boss, it is also lower than the 50 bugs we had last sprint.
– …
– Yes boss, last sprint. You know, the one when you hade us work overtime every second day in order to fulfill our customer’s demands of removing the configurable splash screen and the easter egg TicTacToe-game. Remember how they said that the features lowered the productivity for their employees?
– …
– No boss, it’s still 42 this sprint. However, we’re only on week three of our two week sprint that you’ve prolonged to four weeks in order to fit some extra functionality in. So I guess the number might still go up.
– …
– Boss, I think I’m actually beginning to see the value in counting bugs. These numbers seem to have a strong correlation to the decisions you’ve made. We can probably learn a lot from them.
– …
– What the hell was it you wanted to know boss?
– …

There’s an old saying that a lazy programmer is a good programmer. I’ve never heard an old saying about a lazy manager being a good manager but yet there are all too many of them out there.  Not the good kind of lazy manager who is willing to delegate work and to let people do what they’re good at without micromanagement. No, we get the other kind of lazy manager – the Panacea Manager – who is constantly looking for a shortcut.

The Panacea Manager will measure the organization on what he can count on his fingers and toes because words bore him, unless of course they’re his own. The Panacea Manager will ask for bug count, lines of code, number of test cases etc.

What do you think the Panacea Manager will receive when asking for these numbers?
Is it hard for a developer to produce a lot of code if that is what she is being measured on?
Is it hard for a tester to produce a lot of test cases if that is what he is being measured on?
Will the number of bugs found tell you anything about the quality of the software after they’ve been corrected?

Do our customers care about the bug count or LOC or number of test cases? I don’t think so. Bug count and most other numbers that we collect are just proxy variables for quality as we think our customers perceive it. Measuring quality and productivity via proxy variables might very well result in quite the opposite of what we’re trying to achieve.

How about if the Panacea Manager took a long look at the system he has built or inherited and started making deliberate decisions based on how he actually wanted the system to work? What if he stopped measuring bug count and lines of code and began asking the customers for what really matters to them? Would it make his job harder if he tried to compare customer satisfaction over time instead of employee hours spent in the work place? It probably would to some degree but it would also mean that he actually began doing his job.

So what should we measure then? I’ve learnt that many people itch to ask that question after listening to my arguments. Please don’t! That means I’ve failed at getting my point across and I’ll loose even more hair on my head. Begin with asking yourself; what decision do I want to make and what do I need to know in order to make that a good decision? THAT is what you should measure.

As a leader – or team member as well for that matter, you are faced with a big problem every time you try to implement some sort of a change in your organization.
No, that’s not true. You face a lot of big problems, but one of the bigger ones is … you.

You are trying to interfere with a system without being able to see the entire system. You need to get a helicopter view of the landscape while at the same time being grounded as an important part of the very same landscape.

Most of us don’t understand how much we affect a system that we are a part of, and more importantly; we don’t understand in what ways we affect that system.
Our presence in a meeting can set the entire tone of it without us doing anything in particular. Likewise, we can also affect the outcome of a meeting just by being absent from it.

How do we interact with our systems? What messages do we send to them? Do you have a total coherence between your thoughts, your words and your actions? If not, what parts of your intentions and your communication are getting across? Vice versa; what parts of your coworkers’ true intentions get across to you.
How can we possibly know how a system will react to a particular change if we can’t see the entire system?

Being a lean/agile coach, I’d like to suggest that you get yourself a new set of eyes and ears. As a leader or team member, it’s your duty to be a part of the landscape. You must be the intricate part of the machinery that you are. I, as a coach on the other hand can reserve the right to stay outside your particular system. I can put my stethoscope to the heart of your organization and listen without the distorting filters of preconceptions and interfering echoes of my own actions.
(… at least for a while. Sooner or later we all get biased.)

There are also tools like the left hand column exercise and Virginia Satir’s interaction model that can help us learn to see how our own behaviors affect those around us. If we accept the help and take the time to study ourselves, we can begin to move out of our own blind spots and get our helicopters in the air.

Problem – the perceived difference between a current state and a desired state.

In my last post I discussed assumptions as a good starting point when looking for initial causes in a root cause analysis. Today, I will look at one more practical way of finding these hidden assumptions. I will make an assumption myself here and that is that you are already familiar with basic root cause analysis and know what an Ishikawa (or fishbone) diagram is. If my assumption is wrong you can find some good basics at Wikipedia before continuing.

I find that using brainstorming techniques such as working with Ishikawa diagrams in order to find starting points for causes, have a hard time bringing out unspoken assumptions and prerequisites. Usually the brainstorming is done first and then the results are mapped to the categories in the fishbone diagram or the brainstorming is done with respect to each category, but if we instead start by asking questions that combine the different categories in our Ishikawa diagram, we can find several of the failed assumptions. This can be done as a complement to what is normally done and should not be seen as an either or.

Let’s say we’re working with the 4, 6 or 8 M’s (Machine, Method, Material, Man Power, Measurement, Management etc). Try to combine the categories in questions that are relevant to your situation, e.g.:

  • What training will our Man Power need in order to understand our Method?
  • What limitations do we have on our Material considering the Machines we’re using?
  • What support will Management need in order to make good Measurements?
  • When will we need our Material if we’re going to follow the new Method?
  • What is required from Management for our Man Power to get the Machines or tools they need?

Doing this we might come up with a list of prerequisites or assumptions that were never made explicit at the outset:

  • If we assumed that everyone on the project was familiar with some basic technology, compare this assumption to reality.
  • If we assumed that our target audience belonged to a certain demographic group, compare this to our true audience.
  • If we assumed that people in adjoining departments would communicate with each other, check if this actually happened.
  • If we assumed that our instructions would be read by everyone, check if everyone actually read the instructions.
  • If we assumed that everyone knew where to find the background documents, see if everyone actually knows how to find them.
  • If we assumed that a new hire would be brought up to speed by the team within two months, check if that was the case.

If any of our key assumptions or prerequisites turn out to be false, investigate their impact on the process and problem statement and continue the root cause analysis from there.

As I mentioned in my previous post; validating assumptions is something that should be done all the time and preferably at the beginning of a new project or endeavor of some kind. Using the technique described above does not have to be limited to root cause analysis when the problem is already a fact. Perform this exercise or whatever works for you at the outset  of any new project, change program or other activity where you’ll be working according to a new process.

Problemthe perceived difference between the current state and a desired state.

At times when we find ourselves in the need of performing a root cause analysis (RCA) we have usually ended up at a current state that differs significantly from our desired state. When we embarked on the endeavor of trying to reach our desired state, we probably had a plan or process that we expected would help us get there. Now, most of us design our processes very carefully but we also often implement them on top of a number of loosely made assumptions that are more error prone than anything else in our process.

Depending on our selection of method for RCA we might or might not have the tools for looking at our new process in order to find flaws in it. My suggestion is that you select a method that will help you analyze your process, but that is not what this post is supposed to be about. What I find most methods for root cause analysis seem to lack, is a way to look at the assumptions that we base our process on.

Every problem solving approach that I’ve come across so far has followed a similar pattern of:

  1. Identify problem
  2. Find cause
  3. Find and implement solution
  4. Check result

There are methods for problem solving and RCA that are a lot more refined and give the user good help on how to move between the different steps but the “find cause”-step is often left to more ad hoc techniques such as brainstorming. I think most methods miss out on one good starting point when looking for the causes; our assumptions.

The old saying that assumption is the mother of all f…ups holds true quite often. Validating assumptions should always be done, but if you missed doing this validation earlier, at least do it during the root cause analysis. You will stand a good chance of finding some problem causes in this group.

I want to suggest an approach where our assumptions are made explicit and are compared to history and facts as a first step to identify possible causes. After a problem statement has been properly identified and expressed, try to list any key assumptions or prerequisites that would have been necessary to hold true in order for your process to be valid and for you to reach your desired state. These assumptions might have looked more or less obvious at the outset and thus taken for granted, but that is not the same as them being true. Compare these assumptions to history for fulfillment to see if we actually had everything in place in order for our process to work.

If any of our key assumptions or prerequisites turn out to be false, investigate their impact on the process and problem statement and continue the root cause analysis from there. Remember that these are probably only immediate causes and not our system causes.

In part 2, we’ll look at one way of bringing these assumptions out into the light.

On a roll without a role

December 9, 2010

Like actors we all play several different roles in our lives because the roles help ourselves and others in our interactions. The roles set the expectations for how we should behave and interact.

At work we assume roles such as tester, developer, project manager etc. These roles also set the expectations for what we should do and know, with whom we should interact and how we should do it.

According to Merriam-Webster a role is “a socially expected behavior pattern usually determined by an individual’s status in a particular society.

Did you notice the word “status” in the previous paragraph? We tend to; implicitly or explicitly, associate our roles with some sort of status. Senior developers are better than their junior peers. Architects are better than developers of any rank. A test lead has to be better than a tester. A developer is either better or worse than a tester depending on if you’re a tester or a developer. A project manager outranks pretty much everyone.

For managers, these roles are a great way to put people in a box; to categorize people by the knowledge and experiences they are supposed to hold. Assigning someone a role also means that we can assign them responsibility, we know that the tester should do the testing, that the developer should do the developing and that the executive should do the executing (or whatever).

The concept of roles gives us predictability about people. And predictability is a good thing isn’t it?

Encyclopedia Britannica puts this predictability as: “… An individual may have a unique style, but this is exhibited within the boundaries of the expected behaviour.

But what if we act in a complex environment and want our teams to self-organize in order to cope with variability and complexity? Are the traits that I described above helpful in any way or would we be better off without the roles? My answer is that the traditional roles that we meet in our organizations are limiting our ability to self-organize.

Team members comfortable in a role usually won’t hesitate to assume the responsibilities associated with the role but … they also know where their responsibilities end. It is not when the problem is solved; it’s at the boundary with the next role. People who identify themselves with a role are often comfortable speaking with their peers but less so when it comes to communicating with other roles. If we have a perceived difference in status or rank it will drive the wedge even deeper.

A self-organizing team needs a number of different competencies to solve problems but it does not need these competencies to be locked inside roles. Communication among team members is the single most important factor for successful self-organization, but having preconceived expectations on who should communicate with whom is a limitation that we can do without.

Many organizations have templates for the parts needed in a project team. “We need one architect, two programmers, two testers, one test lead, a project manager and one project coordinator.” Really? Are you really sure that you need these roles? Could it be that you need a number of competencies that will ensure the structural integrity and the quality of the product. Perhaps you also need people who understand the importance of communicating with stakeholders and other teams.

I do believe that a team without assigned roles will become more fractal in the sense that each competence will be found in each of the team members (higher truck numbers). The team will be able to communicate between competencies. The team will share responsibility for delivering a high quality product without throwing work over the fence.

Doing away with roles also means that some managers will have to learn how to treat employees as individuals instead of as typecasted resources and throw away their old models for seniority and wage ladders and … and nevermind, I guess this might have been a naive daydream after all.

Are you familiar with any unwanted side effects in your organization? Are your people working too much overtime because work is being pushed to them? Are incentive systems being played by the employees to maximize their personal gains? Are your customers usually unhappy because they aren’t allowed to change their minds about what they want? Are people notoriously late for meetings in your department? Are you always finding out that tasks won’t be completed on time at the last minute?

Did you ever wonder why any of this is happening?

The people working for you are acting within a system that you are supposed to nurse. That system, if it is a stable one, is what will affect your results more than anything else. The system (that you should assume responsibility for), is delivering outputs, good as well as bad. And guess what, you can consider all of the above problems to be the main goals of your work system. This is what you’ve designed your system to do.

I think that John Sterman put it quite eloquently:
“There are no side effects — only effects. Those we thought of in advance, the ones we like, we call the main, or intended, effects, and take credit for them. The ones we didn’t anticipate, the ones that came around and bit us in the rear — those are the “side effects”. When we point to outside shocks and side effects to excuse the failure of our policies, we think we are describing a capricious and unpredictable reality. In fact, we are highlighting the limitations of our mental models.”

It really doesn’t matter what your intentions were when designing the work system. Your good intentions are history and there is a road to hell that is paved with them. You need to consider the unwanted effects of your system as primary goals of it if you’re going to address them properly.

This is also known as the POSIWID principle, a term coined by Stafford Beer – The Purpose Of a System Is What It Does. It might sound fatalistic but is quite the opposite. Yes, the output of a stable system is approaching deterministic and can’t be changed, but – the system itself can be redesigned to deliver very different results. As a manager, it is your job to do this design and redesign when needed.

The most important part of a manager’s job is to design purposeful work systems.

Do you have a part about designing work systems in your job description? Is that a part of your formal training? Did you even know that’s what you are doing, or are supposed to be doing?

%d bloggers like this: