Environmental influence on Planning

"How can we make an Iteration (Sprint) plan to deliver an Epic when we still have too many Unknowns?" - this question plagues many teams on their journey to agility. Let's explore!

Someone asked me this question, and I have observed a similar thing in other teams before. In a (formerly) Waterfall-Oriented environment, a developer claimed, "We can't tell you how much effort this is until we have the Specification document!" It's the same question, just in different form.

Environmental influence

There are so many environmental factors in here that contribute to the statement being a problem which needs to be solved that I am tempted to write an entire book about it. Without digging any deeper, here are just a few factors which hint that the initial question is merely the symptom of a more severe problem:

• Fear. For example, fearing the Unknown, fearing to not deliver, fearing to fail, fearing to disappoint - the stronger the fear element is, the more likely people will demand a reliable plan.
• Ambiguity intolerance. People or structures with low ambiguity tolerance prefer a bad plan, doing the wrong thing right over no plan and doing the right thing.
• Priority issues. If we're really working on the most important thing, the question isn't as much how long it takes as what is the best way forward.
• Alignment issues. An organization which expects teams to create reliable plans upfront, shouldn't be confronting developer teams with completely unknown topics just a few days before visible results are expected. 
• Slicing issues. There are always opportunities to deliver something based on an upfront plan and show some form of result, although the total amount of work required to get the expected final result doesn't decrease by putting more effort into creating thin slices.
• Scoping issues. An Epic that takes more than an Iteration can't be planned down to a Sprint. The best thing we can do is deliver a portion of the work.
• Push process. When stakeholders push work into the team and expect a specific result in a fixed time, we end up with the typical "Iron Triangle problem": Fixed time, fixed budget, fixed scope. What's left is a compromise on quality.

It should be the responsibility of management, ScrumMasters and coaches alike to create an organization where these issues aren't so relevant.

All that said, there's always the chance that something happened and we need a kind of solution quickly. In the first step, it's important to understand which of the above environmental constraints we have, and how strong or weak these are in relation to the team's work.

For example, if the fear factor is high on team side, we need to approach planning and delivery different from how we would if the main issue is unfamiliarity with slicing.

In my next article, I will explore some techniques in complete disregard of these external constraints that can help a team confronted with planning a completely unknown topic.

Want trust? Deal with fear!

"Fear is a bad advisor!" - proverb.
Positive working environments require trust. Trust can be given and earned - it can't be forced or demanded. Team building workshops often focus around building trust. Are they dealing with the symptom of distrust, though?

Here is a causal loop diagram modeling the relationship between trust and fear:

Red lines = dampening effect, blue line = strengthening effect. "=" sign = time delay

There is a direct relationship between trust and fear: Fearful people don't trust. Trustful people don't fear. Then, how do you get from A to B? It's not as easy as extending trust, although that helps.

The vicious circles

In the model, we see three different vicious circles which need to be broken almost simultaneously before trust can be established. I also hint a way to break these vicious circles.

Blame Games

Starting on the top left, the most visible fear cycle is related to Blame. Nobody likes to be blamed. Being afraid of blame, people hide their mistakes. in consequence either finding someone else to blame ("But you said ..." - "X told me...") or, when caught, receiving blame. Positive management must end blaming people. Blame helps nobody. Identifying someone responsible should never be aimed at having someone to blame, it should always be aimed at finding a way to change things for the better.
As coach, I have even resorted to the rather ridiculous tactic of saying "Ok, it's my fault. Now, how can you make sure it doesn't happen again?" - of course, it's ridiculous that it's my fault. That's not what matters. What matters is that the discussion about fault ends and we start talking change.

Coverups

The next vicious circle is related to information hiding. It's much harder to spot, as one can't know what one could know but doesn't know because it's being kept secret.
It takes a lot of sleuth work to put missing pieces together and discover where people are covering up inportant information revealing what is really going on. Why do people do this? Often, they either don't trust what will happen when uncomfortable facts are revealed - in which case it's a trust issue, or they know what will happen and don't like that - in which case it's a fear issue.
People wouldn't be afraid if failure was not perceived as a stigma with negative repercussions. Establishing a positive failure culture, "Hooray for failure" can go a long way. Just make sure that this Hooray is then hooked up with real learning and change - otherwise, a team member's trust in the team can turn into an outsider's distrust in the work of the team.

Choking Control

The third vicious circle is related to controls. Be that meetings, reports, supervision or checklists. While every single of these isn't necessarily bad, in sum, they can devastate people's ability to think, act and change. One control may be no issue, a hundred controls make it impossible to change anything - and simultaneously, often create a self-contradictory system where at least one control is always broken. People are constantly afraid of breaching control and spend more time on meeting control requirements than on doing actual work which helps the organization.
Managers stop trusting their employees when controls are broken, and employees stop trusting their managers when broken controls don't lead to more effective ways of working, but more controls. At worst, managers also stop trusting their controls when these prove ineffective and load yet more controls to control the controls.
Creating transparency what is truly going on and which processes are actually enforced by these controls can go a long way in abolishing their destructive force and minimizing control to truly helpful levels.

Conclusion

"Don't fear" or "We can trust one another" are hollow slogans. These don't help anything. "Building trust" without understanding the vicious circles and loopback dynamics leading to the low levels of trust we often observe in organizations.
The main lever for raising trust isn't simply building trust, but alleviating the fears which constantly chop at any small flower of trust sprouting up.

As coaches, we must understand both the fear dynamics and the fears driving people. Only then can we build the trustful environment needed to succeed.

Top 5 Ways Companies Hamstring their Development Process

Consulting with dozens of companies, I have come up with a list of the most common impediments that damage a company’s ability to generate maximal business value from development.

As profit goes down, companies are looking for ways to improve
- although the search is in vain unless root causes are dealt with!

“Business Value” is the positive business outcome of development (eg., Money earned, customer satisfaction, market share, conversion rate etc.), minus all costs of producing this outcome, including the delay incurred until gaining it, adverse side effects and opportunity cost of not doing something else instead. Or, in simpler terms, Business Value = success.

The following factors are commonplace, yet most companies are so oblivious to the damage these things cause that they might even be unwilling to deal with the issue:

#1 Communication

Regardless of whether it’s top/down, peer-to-peer, internal or customer facing - communication proves to be the #1 challenge in doing the most valuable thing.

Middle management filtering critical information, unsuitable use of media causes misunderstandings, waiting for responses causes unnecessary delay. Even then, not talking and acting upon assumptions often leads to the worst waste.

#2 Trust

Double-checking, approvals and permission processes as well as any other kind of control just keep people from doing that which helps the company most.

While something may always go wrong, a company built on the assumption that employees will purposely damage the business means you’ve lost already.

#3 Processes

Artificial process constraints lead to inefficiency in achieving results, oftentimes impose suboptimal solutions, are often associated with inherent waste, and might enforce unnecessary handovers.

Standardized processes are good for things where you don’t want to invest even a single minute into, yet development and its outcomes aren’t part of those.

#4 Structure

Inflexible organizational structures create indirection and dependencies, result in unavailability, reduce effectiveness, induce delays and limit the opportunities for value creation. Structural issues might reduce a developer's ability to deliver by a good 95%. As Deming said, "a bad system beats a good person 100% of the time".

#5 Saving money

Avoiding to spend money on that essential, "out of budget" component may result in a seemingly more inexpensive solution which may be a hundred times less efficient, potentially to the point where they might eat up the entire value proposal of the development effort.

Bottom line: money spent is irrelevant as long as that spending is below the value obtained. Keen spending goes a much longer way than vigilant budget maintenance.

Bonus: Consequences

#6 Artificial Dependencies

Closely related to communication, structure and trust, when people are forced to synchronize with others on topics they would have under control, the incurred communication overhead tranlates directly into reduced capacity, therefore a multiplicative factor in value reduction.
Such artificial dependencies might include non-value adding functions, such as reporting structures, centralized institutions such as "Enterprise Architecture", "Test Department" etc. As the proverb goes, "Make everything go over your desk and you are important."

#7 Lack of customer interaction

Low trust, bad communication or unsuitable processes, organizational distance etc result in an inability to deliver small increments. Every step taken without involving the customer directly is full risk of delivering zero value. This often produces a vicious circle where more and more risk is pushed downstream until all development happens without customer involvement, who is then usually disappointed to receive a worthless product.

Conclusion

Managers are continuously looking for better ways to get work done which allow them to keep the above things in place. Until we realize that the business relevant outcomes of the work are dependent on dealing with the above factors, all improvement initiatives will at best yield an efficiency increase without offering a better outcome.
Significant improvements in outcome fully depend on doing the right thing in the right way, and that means resolving the key issues around communication, trust, processes, structure and spending.