Sunday, July 14, 2019

When will the Agile Project be done?

"When will the project be done?" - or: "We need this project to be finished by (this deadline). Can you do this?" are typical questions which senior managers expect project managers to be able to answer. And the answer to this question will not go away in an agile environment - because other initiatives may be linked to the project. When there is no project manager, the team (and in a Scrum text, the Product Owner) should still be able to provide an answer.

Bad answers

"We're Agile. We don't do Projects any more."

Ha ha ha. Very funny. There will still be projects, although they will be within a different context. Instead of pulling up random groups of people to deliver a prepackaged bunch of work, we rely on dedicated teams with a clearly delineated responsibility for products, components or features. These agile teams will take those work packages called "projects" and deliver them.

A "Project", in an agile context, is nothing more than a label attached to a number of backlog items.
The project begins when we pull the first backlog item and ends when we complete the last.
If you so like, you might put the entire project into a single backlog item of pretty big size, something many teams call "Epic" and the result is often referred to as a "(Major) Release".

"We're Agile. We don't know"

What could be a better way to brush up a manager (and/or customer) the wrong way? Imagine if you were a developer and would order a new server and asked the admins and/or web host "When can we have this server?" or "Can we have this server by next Friday?" - would you consider this as a satisfactory answer? If not, you can probably empathize with a sales manager or customer for not being satisfied with this answer, either.

While there is definitely some truth that there are things we don't know, there are also things that we do know, and we are well able to give information based on the best information we have today.

And here is how you can do that:

A satisfactory answer

Based on the size of your project in the backlog and your velocity, we can make a forecast.
To keep things simple, we will use the term "Velocity" in a very generic way to mean "Work Done within an Iteration", without reference to any specific estimation method. We will also use "Iteration" to mean "A specific amount of time", regardless of whether that amount is a week, a calendar month or a Scrum Sprint. Even outside a Scrum context, we can still figure out how many days elapse over a fixed amount of time.

If we have an existing agile team, we should have completed some work already. As soon as we have delivered something, we can make forecasts, which we shall focus on in this article.

Disclaimer: This article does NOT address sophisticated estimation methods, statistical models for forecasting and/or progress reporting. It discusses principles only. It is easily possible to increase the level of sophistication where this is desired, needed and helpful. Information on these topic can be found on Google by searching for "Monte Carlo Method", "Agile Roadmap Planning" and "Agile Reporting".
For those interested in a mathematically more in-depth follow-up, please take a look at this post by William Davis.

We need some data

Maybe we haven't delivered anything yet, and then it's all guesswork.
In this case, the best thing we can do is spend a few weeks and get things done. Let us collect data and make a forecast from there, so that we get data to build our forecast upon it.

What would be the alternative? Any forecast not based on factual evidence is pure guesswork.
The more time we spend without delivering value, the later our project will be.

We can make a forecast

We can use our historic data to make various types of forecasts.
The most relevant management forecasts are the date and scope forecast, which will also allow us to make a risk forecast. We will first examine the date forecast.

Let's take an example project:
  • Our project requires 200 points.
  • Our Velocity over the last 5 Sprints has been 8,6,20,7,9. 
Management Questions:
  • Can it be delivered in 22 Iterations? (Due Date Status)
  • When will it be delivered? (ETA)
  • What will be delivered in 22 Iterations? (Project Scope)
Let's look at a schematic diagram based on Cumulative Flow, and then examine the individual forecasting lines in more detail below:

Fig. 1: A schematic overview how we can forecast dates and risks for Agile Projects

Averaged Completion

Probably the most common way to make a forecast is to average the velocity over the last few intervals and build the forecast from there. The good thing about this "average forecast" is that it's so simple.

Our example gives us an Average Velocity of 10.
Our forecast would be:
  • Due Date Status: Green.
  • ETA: 20 Iterations.
  • Project Scope: 100%
The consequence will be that the team will be given 20 Iterations for completion.
The big issue of Average Completion is that any small change or unpredicted event will devastate the forecast.

How to use Average Completion

Average Completion is possible based on historic data. The Average Date would be the earliest suggested ETA date that you may want to communicate to the outside world. The Averaged Scope would be the corresponding committable scope on the Due Date - you have a 50% probability to make it!

How not to use Average Completion

The Average Completion Date will likely shift with every Iteration, and as soon as we fall behind plan, there's a significant risk that we won't catch up, because the future isn't guaranteed to become more favorable just because the past hasn't been favorable. As soon as our Velocity is lower than average, we're going to report Amber or Red and must reduce scope.
Management will have to expect these bad news on every single Iteration Review.
This puts our team between a rock and a hard place, becoming known as a constant bringer of bad news, so you may prefer to not rely on the averaged completion date.

Minimal Completion

We can also take the best velocity achieved over a single Iteration and forecast the future from there. It gives us - at least - an earliest possible delivery date for the project. It's purely hypothetical, but it allows us to draw a boundary.

Our example would give us a Maximum Velocity of 20.
Our forecast would be:
  • Due Date Status: Green.
  • ETA: 10 Iterations.
  • Project Scope: 100%

How to use Minimal Completion Dates

The "Minimal Completion Date" is a kind of reality check. If management would expect the project to be delivered in 8 Iterations, and your Earliest Forecast already says 10, you don't even have the potential means to succeed. 
Every date suggested before the Minimal Completion Date is wishful thinking, and you're well advised to communicate Status: Red as soon as this becomes visible.

How not to use Minimal Completion Date

Some organizations like best case forecasts and then make plans based on these. 
I don't need to go into the madness of building our finance forecast on winning the lottery 20 times straight in a row - and using best cases is exactly this kind of madness.
You will fail if you plan for earliest completion date.

Expected Completion

The best way to use our historic velocity is by removing statistical outliers. Unusually large amounts of work completion are normally based on "spill-over", that is, work that wasn't finished before and therefore wasn't really done within the iteration period. Alternatively, they might have been the result of work items being unusually fast to complete, and common sense dictates to not consider unusual events to be usual. Therefore, we create a purified average eliminating unusually high figures.

Our example would give us an Expected Velocity of 7.5.
Our forecast would be:
  • Due Date Status: Amber.
  • Earliest ETA: 27 Iterations.
  • Project Scope: 80%
This means that we can commit to delivering either 80% of the scope by the due date, or that we need to move the Due Date by 5 Iterations to deliver the 100% of the scope. This creates options and opens room for negotiation.

How to use Expected Completion

The realistic completion date is what we can communicate to the outside world with a decent amount of confidence. Unpredicted events that are not too far out of the norm should not affect our plan.
While many stakeholders would try to haggle around the Expected Completion Date in order to get an earlier commitment, we have to state clearly that every calendar day earlier than forecasted increases the risk of not meeting expectations.
We can indeed reduce the project's scope in order to arrive at an earlier date, and if there is a hard deadline, we can also slice the project into two portions: "Committed until Due" and "May be delivered after Due".
The good news is that in most contexts, this will satisfy all stakeholders.
The bad news is that Part 2 will usually be descoped shortly after the Due Date, so any remaining technical debt spilled over from Part 1 is going to be a recipe for disaster.

How not to use Expected Completion

Some organizations think that the interval between average and expected completion date is the negotiation period and if the due date is between these dates, they will call it a match.
I would rephrase this interval to be the "period that will predictably be overrun".

Worst Case Completion

The absolute worst case is that no more gets finished than we have today - so the more we get done, the more value is guaranteed, but let's ignore this scenario for the moment.

It's realistic to assume that the future could be no better than the worst thing which happens in the past. We would therefore assume the worst case completion to be based on the minimal velocity in our observation period.

Our example would give us a Minimum Velocity of 6.
Our forecast would be:
  • Due Date Status: Red.
  • Earliest ETA: 34 Iterations.
  • Project Scope: 60%

How to use Worst Case Completion

The Worst Case scenario is the risk that people have to take based on what we know today.

Especially in environments where teams tend to get interrupted with "other important work", receive changing priorities or suffer from technical debt, it may be wise to calculate a worst case scenario based on minimum velocity in the observation period.

Worst Case Completion normally results in shock and disbelief, which can be a trigger for wider systemic change: The easiest way to get away from worst case completion dates is by providing a sustainable team environment, clear focus and unchanging priorities.

How not to use Worst Case Completion

If you commit only to Worst Case Date and Scope, you're playing it safe, but you're damaging your business. You will lose your team's credibility and trust within the organization and may even spark the question whether the value generated by your team warrants the cost of the team, so you risk your job.

Quantifying risks

You can derive data as follows from the dates and numbers you have:

  • The expected completion date is when the project will likely delivered as scoped.
  • We have an predictable overrun my the duration which the average date moves past the due date.
  • The predictable scope risk by the due date is the full scope minus the expected scope.
  • The maximum project risk is the full scope minus worst case scope.
  • The maximum project delay is the diration which the worst case date is beyond the due date.

Managing risks

We can manage the different types of risks by:
  • We increase confidence in our plan by working towards the Expected Date and Expected Scope.
  • We reduce date overruns by adjusting our Due Date towards Expected Date.
  • We reduce scope risks by adjusting project scope towards Expected Scope on Due Date.
  • We reduce project cost by reducing project scope.
  • We reduce project duration by reducing project scope.

Dealing with moving targets

Changes to the project are very easy to manage when we know our project backlog and velocity:
  • The addition of backlog items:
    • moves our date forecast further to the right,
    • reduces the % scope on a fixed date,
    • increases scope risk and overrun risk.
  • The removal of backlog items:
    • moves our date forecast further to the left,
    • increases the % scope on a fixed date,
    • decreases scope risk and overrun risk.

Agile Project Reporting

Based on the above information, you can communicate the current and forecasted project status in an easy matrix form, just taking this one as an example:

DescriptorDateScope on Due DateStatus
Due DateDecember 2020100%
Change PeriodJune 2019+5%
Expected Date March 2021
( +3 months)
Worst CaseDecember 2021
(+12 months)
Known Risks 3 months overrun20-40% missing
Fig. 2: An example status report for Agile Projects

This gives stakeholders high confidence that you know what you're doing and provides the aforementioned options of moving the project back to "Status: Green" by moving the Due Date or by reducing scope, or a combination thereof.

Since you have access to your backlog, you can even propose a number of feasible suggestions proactively, for example:

Option 1
1. Accept moderate likelihood of running late.
2. Ensure continued Project funding until completion.

Consequence: Due Date December 2019 might overrun up to 3 months.
Option 2
1. Add Project Phase 2 from January 2020 to March 2020
2. Move Backlog Items #122 - #143 into Phase 2
3. Provide Project funding for Phase 2.

Result 1: Due Date December 2019 met.
Result 2: 100% planned Scope delivered by March 2020.
Option 3
1. Descope Backlog Items #122 - #143

Result: 100% reduced Scope delivered in December 2020.
Fig. 3: An example risk mitigation proposal for Agile Projects

Most likely, stakeholders will swiftly agree to the second or third proposal and you can resume working as you always did.

Outcome Reporting

The above ideas simply rely on reporting numbers on the "Iron Triangle", and in some cases, executive managers ask for this. In an agile environment, we would prefer to report outcomes in terms of obtained value and business growth.

Even when such numbers as above are required, it's a good idea to spice up the report by providing quantified results such as "X amount of new users", "Y amount of business transactions", "Z dollars earned" wherever possible. This will help us drive the culture change we need to succeed.

Closing Remarks

As mentioned in the initial disclaimer, this article is merely an introduction to things you can try, pragmatically, and then Inspect+Adapt from there until you have found the thing which works best from there.

The suggested forecasting method, risk management and status reports are primitive on purpose. I will not claim that they result in an accurate forecast, because the biggest risk is in the Unknown of our plan: We could be working towards a wrong goal, the known backlog items could be missing the point or the backlog items could be insufficient to meet the project target.

It's much more important to clarify the Unknowns than to build a better crystal ball around huge unknowns, and I believe that it's better to keep estimation and forecasts as simple and effortless as possible, and spend more effort into eliminating the Unknowns.

The best possible agile project delivery strategy relies on the early and frequent delivery of value to eliminate critical Unknowns and maximize the probability of a positive outcome.

Frankly, it doesn't matter how long a project takes or whether the initial objective has been met when every Iteration has a positive Return on Invest - and neither does it matter that a project's initial objectives were met when it's a negative overall Return on Invest.

Thursday, July 4, 2019

Classifying value by importance

As Product Owner, your responsibility is to order the Product Backlog by Value.
This may be really difficult when you're dealing with many different stakeholders who all consider their own few backlog items to be of utmost importance.

This simple model can guide your questions:

Three Importance Dimensions

The three dimensions Need, Want and Lack are all gradual - yet, for simplicity purposes, we'll just simplify them as "Strong" (inside the dotted circle), "Relevant" (within the dimension circle, but outside the dotted circle) and "Weak" (outside the dimension's circle). We'll leave it up to common sense how to interpret these terms. 
As a nuance, you can rank-order them by proximity to the center.

How strong is the need?

Based on Maslow's Hierarchy of Needs, some features meet existential needs, others provide comfort or enjoyment. Arguably, you need to be in a pretty comfortable positon to value convenience.

Key questions
Which basic needs gets addressed?
What happens when no solution is provided?
Will there be loss of life, damage, squandered opportunity or merely inconvenience?

The bigger the need, the closer you would move to the center inersection.

How wanted is the feature?

Many features are highly wanted for a really short time, but like a snowflake, the demand melts off as fast as it appeared.

Key questions
Is the request just a spontaneous idea?
Has it been thoroughly pondered?
How much would you be willing to sacrifice to get it?

When customers are unwilling to sacrifice anything, not even a single cent, then it's not wanted - and if they'd sacrifice everything else get it, then it's really wanted.

How big is the lack?

Supply creates its own demand, but scarcity rules price.
As the old joke goes, a great salesman could sell sand in the desert - but that would be an utter waste of sales talent.

Key questions
How is the situation currently addressed?
Is a feasible solution already available?
How much better would that which we could provide be than status quo?

The more plentiful and cheaper available alternatives are, the smaller the lack - and the more costly an alternative is, the bigger the lack.

Ordering the backlog

The position of these items in our diagram can then be used to determine how we would arrange our backlog:

  1. Items in the central intersect of the diagram have highest importance and should come first. In this case, the exact order might be determined by other factors, such as WSJF or feasiblity.
  2. Items in dual intersects within the dotted circle will end up near the top of the backlog.
  3. Items in dual intersects outside the dotted circle will end up somewhere in the middle of the backlog.
  4. Items which are only in one circle can be deferred and moved to the bottom of the backlog.
  5. Items placed outside all circles warrant no further consideration and can be safely discarded.

Standard relevance

"But ... what about items with relevant need, lack and want, where neither is strong? They fit nowhere in the diagram"

Yes, the model doesn't really allow you to place them properly.
Just ignore the "Want" dimension and put them into a suitable dual intersect. It doesn't matter - because these items won't be on the top of the backlog, and the exact order of backlog items that won't be touched within the next couple of months is fairly irrelevant.

Wednesday, July 3, 2019

What to do with A-Players?

There is a weird notion in the industry that A-Players are a problem for a team, and is it really a good idea to eliminate them so others can grow? Let us make the case.

Defining the A-Player

Before we can determine what to do, we need to be clear on what an A-Player is, and what they are not.

There are many sources on the Internet defining an A-Player by their attributes, and I will collect just some:

Steve Job on A-Players

"For most things in life, the range between best and average is 30% or so. The best airplane flight, the best meal, they may be 30% better than your average one. What I saw with Woz was somebody who was fifty times better than the average engineer. He could have meetings in his head. The Mac team was an attempt to build a whole team like that, A players. People said they wouldn’t get along, they’d hate working with each other. But I realized that A players like to work with A players, they just didn’t like working with C players. At Pixar, it was a whole company of A players. When I got back to Apple, that’s what I decided to try to do. You need to have a collaborative hiring process. When we hire someone, even if they’re going to be in marketing, I will have them talk to the design folks and the engineers." - Steve Jobs

Extreme technical aptitudeCan get by technically
Superior intellectHighly specialized
Broad horizonShutter vision
Likes working with smart people     Doesn't like working with others

This short list alone should already clarify some misconceptions on what many people call A-Players. Let's continue.

The War For Talent

Steven Hankin (McKinsey) used the term A-Player in "The War for Talent" in reference to in talent management.
They came up with the items below:

A-Player AttributeInterpretation
Strong Intrinsic SkillsHas both extremely strong skills and desire to use them to achieve something
WinnerHas both extreme ability and desire to achieve something
Great CommunicatorConfident, charismatic and eloquent. Can equally convince and attentively listen.
PassionateIdentifies with a vision and is dedicated to move it forward.
Tacit KnowledgeCan manage themselves and others well.
Growth MindsetDriven by a desire to grow themselves and others.

Jack Welch's Vitality Curve

In his 2001 book Jack: Straight from the Gut, Welch classifies executives into A, B and C Players.
These were the traits describing the "A"-Players:
  • Filled with passion
  • Committed to "making things happen"
  • Open to ideas from anywhere
  • Blessed with lots of "runway" ahead of them
  • Possess charisma, the ability to energize themselves and others
  • Can make business productive and enjoyable at the same time
  • Exhibit the "four Es" of leadership:
    • Very high Energy levels
    • Can Energize others around common goals
    • The "Edge" to make difficult decisions
    • The ability to consistently Execute
While "B" players may not be visionary or the most driven, they are "vital" because they are the majority. The label "C" players was reserved for people who were pretty much the opposite of "A" Players. This coincides well with Steve Job's assessment that A players dislike working with C-Players.

Peter Baskerville's A-Player

Baskerville argues that every employee brings a mix of both hard and soft skills that will help a company achieve their vision. These combine with the Three C's - Coachable, Collegial and Committed. An A-Player would be exceptional in all of these dimensions:
A-Player AttributeInterpretation
Skills & KnowledgeHas the hard skills and factual knowledge to excel.
Behaviour & AttitudePositive conduct, feelings and expression towards others.
CoachableReceptive to feedback, appreciative of input. Happy to be corrected. Efficient and effective learners.
CollegialOperates effectively in a team. Caring. Respectful. Approachable. Asks, "How can I help?"
CommittedCommitted to the enterprise, their life, their relationships. Take ownership and responsibility. Will find solutions where none exists.

When combining the key points from all of the definitions above, we realize quickly that the quest for an A-Player is the strife to find a unicorn.

Sometimes, they manage to actually find one of those unicorns, but they aren't prepared, because they are not experienced in dealing with unicorns. How can this end well?

The Dark Side

Consolidating all of the above definitions, there should be little to no issue with A-Players. But ... there can be. If the system isn't supportive, in the best case, the A-Player will bolt for the door, never to be seen again. In some cases, the basic need for money to afford their living forces them to stick around and compromize on who and what they are.

Pet peeves

The virtues of the A-Players mean that they also tend to exhibit pet peeves, that is, they will feel violated when forced to work with people, attitudes and behaviours that are in direct conflict with their virtues.

VirtuePet Peeve
Technical aptitudePeople who don't know, don't ask, don't learn and don't care to do things right.
Passionate, courageous, committedNine-Through-Five attitude.
Social, communicative, supportiveBackhanded politics, backstabbing, Fact twisting, information hiding.
Energetic, energizing, edge and executingEnergy drains, complaining, naysaying, bureaucracy.
Swift learner, coachable, openPutdowns, humiliation, disrespect.
Superior intellect, broad horizonMental shutters, narrow-mindedness, prejudices.
Sense of ownership and responsibility"Below the Line" behaviour: Shaming, blaming, justification,  denial.
High moral standardsUnethical and antisocial behaviours

While an A-Player also exhibits the grit to to with exceptional events, if the system constantly pushes their hot buttons, they might use their talent in order to survive rather than thrive.

The fastest way to demotivate and break an A-Player is by putting them on a team with people who constantly exhibit a large portion of the pet peeves

The Negative A-Player

As hinted above, A-Players who have a choice will leave an unsupportive environment as soon as the opportunity arises. When they do not have a choice, their positive traits will gradually turn into negatives to minimize their own pain, eventually adapting to the surrounding system and becoming the very people displaying the things which used to be their own pet peeves - and being bright, they excel at this, too.

Depending on how the company culture has affected them, they may retain some of their positive characteristics, shut down others and adapt within those who have the most conflict.

Dealing with Negative A-Players

While some people advise to outright fire them, as these people can singlehandedly block change, this is not a fix to the problem, as the root cause is of systemic nature.

The first step would be to validate whether the person is still coachable. However, if they smell that "coaching" is intended to manipulate them into compliance, there is no basis for change. Coaching A-Players requires discovering what they truly want, how they truly want to be - what is stopping them from achieving this and potentially even setting the right levers within the organization to make this possible.

In an agile working enviromnent, teamwork is essential, and team dysfunctions are the first things that are hurled at A-Players, the standard narrative is "A-Players are not team players, they keep down the team, that's why we need to get rid of them!"
As a first disclaimer: Some people are antisocial by nature and can not enjoy being on a team. These would, by definition, not be A-Players. Before we talk about the empty set, let's stick to A-Players.

I will take three examples, without a claim that any of them is fully representative of all cases in this category.

The A-Player who doesn't want to be on a team

I will refer to a personal conversations here from coaching one such case. This case is by no means representative, but it will show why addressing the person is by far not as important as fixing the system.

A recurrent statement this person made in many coaching sessions was, "I can not do everything alone. This thing is bigger than what I alone can do. I need others who are willing and able to take their portion. BUT - these guys are not just not pulling their weight, they are dumping their weight on my shoulders, too and then blame ME when I am not getting THEIR things done!"

It turned out that management was overly swift in assigning work to people whom they believed could solve the problem without relieving these people of their other responsibilities. When someone was overburdened, the quick fix was to reassign their tasks to someone who could do it. As such, management had created an environment where it was in every person's self-interest to be perceived as a low-performer who couldn't take further responsibility, while high-performers got ground to dust.

The A-Player who suppresses self-organization

I used to coach for a team had one outstanding person who had more ability, more knowledge and more grit - who had gotten into management spotlight for blocking self-organization.

What had happened? The company held team leads accountable for the performance of the entire team on a stack ranking system. The organization had taught him over a decade that permitting self-organization could get him fired and had never openly communicated that this had now changed. And yet, they expected him to change his behaviour.

We had a management failure to set, communicate and verify proper incentives.

The A-Player who takes the spotlight

I was coaching an A-Player who would ensure that every meeting drove home the point that she was pulling the main weight, that others were helpless without her - and that her suggestions needs to be followed.

Long story short: Another management failure.
She was definitely the brightest bulb in the lamp, but she suffered massive discrimination: Statements like "She's just a junior!", "Women in engineering!", "Do Africans even know what servers are?" were commonplace. Management not just tolerated, but even perpetuated these statements. She fought tooth and nails to prove her competence.
It was management that turned out to be uncoachable, not willing to see why their behaviour, both in action and inaction, created the problem they wanted her to stop.
I advised her to leave. She did.

Fixing the System

In each of these cases, what would have been achieved by firing the individual who was pushed into a their rather unfortunate position by their management?

As an economic principle states, "People respond to incentives". It is madness to assume bright people will change the very behaviours that the organization incentivizes.

What makes A-Players A-Players is their ability to comprehend the system, the impact of the system upon them, and their impact on the system in a very short time. They will adopt exactly those behaviours that will maximize whatever they currently optimize for. As such, they can be great in showing what the flaws in the current system are and how the system needs to be changed in order to improve performance of the entire system.

I firmly believe that "firing the A-Players" is an easy cop-out that excuses managers of their own failure to set up a system which brings out the best in A-Players to propel the company to new heights.

I would seriously question the advice propagated by many of "agile gurus" that getting rid of the A-Players will allow the teams to flourish. This advice is myopic and misguided. It betrays poor systems thinking and a perverted sense of management responsibility.

Weeding out the A-Players sets the stage for mediocrity, and inhibits innovation. This is not just not an option - it's economic suicide!

Let's not confuse attention whores with A-Players. A-Players are the most valuable asset you have. They need to be protected at any cost.

Sunday, June 30, 2019

What is "Value"

In the book, The Professional Product Owner (which by the way I recommend each Product Owner and Scrum Master to read) the authors Don McGreal and Ralph Jocham, under the heading "Value Defined" (pg56) discriminate "Value" into three different categories:

Types of Value

The italic quotes in this section are verbatim quotes, and I will comment on them below:

Personal Value = Personal happiness

 As people, anything we consider to be of value ultimately comes down to one elusive element: Happiness. Is money valuable? Only if it makes you happy. More time with your family? Only if it makes you happy ... Time, money, good job, these are only circumstantial evidence of value. We assume having more of them will make us happy.

Business Value = Money

 As companies, anything they consider to be of value ultimately comes down to one elusive element: money. Are happy customers valuable? Only if they pay for your product. Is a good culture valuable? Only if it reduces the cost of attracting and retaining employees. Happy customers, good culture, steamlined processes; these are only circumstantial evidence of value. We assume having more of them will make (and save) us more money.

Nonprofit Value = Improving Society

 An obvious exception is nonprofit organizations (...) where value is about improving society. For nonprofits, money is circumstantial. In fact, revenue while not positively impacting society would be considered negative value.

A myopic definition of Value

The short form would be: "People see value in happiness, businesses in money and nonprofits in improving society."
Personally, I disagree. All three of these statements are myopic. And here are my cases for ponderance:

Basic human needs

Why do people see a doctor? Is it to get well, or is it to be happy?
While there are indeed certain pills that "make people happy", most people would agree that health is a value in and of itself, regardless of whether it's connected to happiness.

The entire Maslow "Hierarchy of Needs" doesn't even contain the term "happiness", and there's a reason. When people's basic needs, such as food, shelter and safety are unmet, happiness is irrelevant. Likewise, it's entirely possible to have psychological needs met without seeing fulfilment - which meets the need, but doesn't result in happiness.

Therefore, people are looking for other things than happiness as well.

Emotional Compass

And finally, to put the nail into the coffin on the happiness argument:
Happiness is but one of many human emotions. When we study the Plutchik Wheel, we discover that there are eight base emotions, with different nuances on each, accompanied by different attitudes, and they can even combine to form yet other emotions. The mix of all of these is what makes us human, a biased pursuit to ultimately have only happiness makes us shallow.

And without going further into details, both Christian and Buddhist teachings contradict the idea that the pursuit of happiness leads to a fulfilled life.

Therefore, happiness is one, but definitely not the only, thing people strive for.

Online Games

Why are "free games" such powerful cash cows? Is it because everyone eventually pays? No!
One of the core tenets of Free-to-Play Games is that you need a massive player base in order to attract some so-called "Whales", that is, people with a high willingness to spend a high amount of money on games. Some games go as far as calculating that they need about ten free players to attract and retain just one paying customer, and maybe one in a hundred of those paying customers is a whale - so basically, your entire business model is built on the idea that 99% of your player base play at or below cost in order to rake in the cash from a few hundred!

Therefore, attracting and maintaining unpaying customers may be crucial to your business model!

Cross Service Subsidization

About a decade ago, Deutsche Bank chose to make their unprofitable private customer banking segment so unattractive that millions of customers simply left.
Too late did they realize that many individuals (myself included) are entrepreneurs who also have a company. And when your bank basically gives you, as a private person, the extended middle finger, you'll consider twice where you, as a businessperson, take your transactions.

The money of this segment wasn't what made this customer group valuable - their entire value was in enabling other business segments!

Therefore, eliminating unprofitable customer segments may be economic suicide!

Interests aren't Improvments

It's not necessary for a Non-Profit Organization to actually want to "improve society". Although a large number of NPO's are formed around a societal goal which they themselves consider an improvement based on their perspective, this isn't the only reason to have an NPO. Indeed, an NPO only means "Not for Profit", which only excludes profit as a motive. And this should also hint that there are indeed other motives which an organization could hold.
Also, according to Wikipedia's definition of an NPO, it's entirely possible for an NPO to further exclusively the self-interests of the organization.

Therefore, "improving society" is neither excluded from being valuable for a for-profit organization, nor is it necessarily valuable for a non-profit organization!

Other types of Value

Is money, or bottom line, the best measure for company value? I consider this view myopic.

"We're in business to earn money, and we build products to earn money, hence the best product is the one that earns most money." That's common thinking, but it's not that easy and probably the reason why so many companies get in trouble on a strategic level.

Personal Values

People value a whole range of things, and happiness is just one of them. There are a wide range of things people can value that neither directly nor indirectly translate to happiness. Instead, the validity of these values depends on a person's core belief system, which is not the same for every person.

Here are just a small number of things which people might value that have at best extremely fuzzy links to happiness:
  • Health
  • Life
  • Compassion
  • Kindness
  • Integrity
  • Respect
  • Religion
  • Patriotism
  • Environmentalism
I would like to argue, based on the standpoint of the authors, which shows the absurdity of the concept of taking individual happiness as ultimate measure: 
  • Is another person's life valuable, even if it doesn't make you happy?
  • Is respect towards other people valuable, even when they don't make you happy?
  • Should we do something about climate change, even if it means that you may have to stop doing something that currently makes you happy?
With the argument that "only what makes you happy has value", we create a corrupt, unsustainable society!
Although each person has their own set of core beliefs, I think I made the point that adopting the core belief of "do whatever makes you happy and ignore everything that doesn't" could lead to an entirely broken moral compass.

Strategic Values

When I was an inexperienced agile coach, I used to abide in the narrow definition of value that everything can ultimately be translated into fiscal value. I was quickly taught something else. Managers in organizations see a huge variety of "strategic values" that are extremely difficult to express in terms of money, just to list a few of them:
  • Brand
    • Reach
    • Dominance
    • Exclusivity
  • Publicity
    • Influence
    • Reputation
    • Visibility
  • Networks
    • Recommendations
    • Partnerships
    • Alliances
  • Capability
    • Scalability
    • Descalability
    • Flexibility
While some of those things could indeed translate to money in the long term, it's about impossible to relate a single backlog item's contribution to any of the above to a meaningful fiscal quantity.


Ultimately, if we stick to an overly narrow, dogmatic definition of "Value", we lose opportunities and might be acting against the best interests of ourselves, our organization, our society and eventually of humanity.

Instead, we might want to reflect on this one simple point and explore: "What do we consider valuable - and why?"
The answer will be different for different people, different teams and different organizations, and change over time.

Sunday, June 23, 2019

Coaching tool: The ORG team building model

How do you build high performing teams? In this article, I will describe the three-factor model which can help focus your attention.

The model is extremely simple to memorize, although it requires a lot of thought and attention to practice.

The model

Outcomes, Relationships and Growth are highly interrelated: Poor relationships lead to poor outcomes, whereas good outcomes bond the team, and growth is usually required to get the next great otucome.
It's impossible to separate the three, although managers often focus solely on process and outcome - a huge mistake!


Future outcomes are goals or side effects, and past outcomes would classify as achievements or failures.
With a new team, we have a couple goals. By turning them into results, we create a basis for inspection and adaption.

We can look at outcomes in many ways, just to name a few examples:
  1. Performance: Value, Customer Satisfaction, Quality, ROI
  2. Process: Behaviours, Practices, Tools, Flow
  3. People: Mindset, Expertise, Happiness, Teamwork, Relationships (there we go, recursion!)
One important side note on process outcomes: Dysfunctional behavior is most often an indicator of at least one dysfunctional relationship, which is why behaviour (both of the person and the system) is classified as an "outcome".


Relationships are the basis of every group effort. Healthy relationships propel performance, whereas unhealthy relationships constantly divert attention away from outcomes. Therefore, investing into healthy relationships both within and around the team is essential to success.

We can also look at relationships in different ways, here again some examples:

  1. Trust: Reliability, Confidence, Mutuality
  2. Psychological Safety: Addressing and resolving conflicts, allowing vulnerability, permitting mistakes
  3. Collaboration: Commitment, Teamwork, addressing weaknesses and being supportive
Creating and growing a base of trust can be done by setting common goals (ref. "Outcomes") and achieving them together. 


As a wise person once told me, "We are all where we are, who we are and what we are. Growth is a lifelong process, but not everybody grows. Wouldn't it be sad to stand in front of the grave of an 80-year-old person and the inscription read: No growth. This person hasn't grown in the last 50 years?"

Growth areas we can look into might be:

  1. Organizational: Team, Company, Market
  2. Personal: Skills, Understanding, Social
  3. Professional: Salary, networking (see - we have relationships again!), achievements (and there's outcomes!)

Healthy growth picks up people where they are, happens at a pace people can bear with, and helps them move into a direction they want to be.

Time orientation

The model is applied differently in past, present and future orientation.


Since a new team starts with a future, we'll look at the future first:

  1. What will be the desirable and probable outcomes of our actions?
  2. Which relationships would we want to have (within and outside the team)?
  3. In which areas do we want to grow?
Even this can be separated into subsets of Near Future, Mid-Term and Distant Future.


In the present, a possible set of questions would be:
  1. Which outcomes are we currently working towards and what are we getting?
  2. Which positive and negative aspects do our relationships have?
  3. In which direction are we growing and where should we be growing?


The past helps us understand why we are where we currently are:
  1. Which outcomes did we get, which were desirable and which not?
  2. Why are our relationships the way they are?
  3. Where did we grow and where didn't we?
Analyzing the past is about finding change potential to move into a better direction from now on, so while positive aspects help us identify drivers, negative aspects help us identify areas with need of attention.

How to use the ORG model

As a process

The meta process is quite simple and contains an infinite loop:
  1. OUTCOMES: Start by defining goals, i.e. "indended outcomes".
  2. Bring people together to achieve those goals (the team).
  3. RELATIONSHIPS: Let the people figure out how they want to achieve those goals.
  4. GROWTH: Observe where issues arise and work towards beneficial change.
  5. OUTCOMES: If goals change or new goals (e.g. growth or relationship goals) become necessary, set new goals.
  6. Repeat at 3.

In team building

When setting up a new team, remember: You have no outcomes, growth or relationships to build on yet.

  1. Define the long-term OUTCOMES for the team, i.e. "Why the team exists".
  2. Set clear, achievable short-term OUTCOMES to achieve in a short period of time.
  3. Bring the right people together and see which RELATIONSHIPS form.
    Strengthen desirable relationships.
  4. Generate team GROWTH while achieving these OUTCOMES.

I have seen great leaders define the main goal of a first iteration with a new team primarily as people outcomes: Build relationships, get to know each other and the product vision. Performance outcomes are still important, but achieving these can wait.

Inspect and Adapt

As mentioned in the "Time Dimension", we can constantly reflect on past-present and future ORG states, refocus and make adjustments as needed. A Scrum team might want to use ORG during Planning, Reviews and Retrospectives to determine a course of action, learn where they got and adjust course.


Your coaching effort can be distributed across the three different dimensions of ORG.
Ideally, you balance out all three dimensions, neglecting none.
In practice, this will be a pendulum swinging between all three, and the one with the least attention is the most likely to become your next problem.

As a coach, if you realize that you're neglecting one dimension, you can pro-actively plan your next steps to build a higher performing team.


Printable materials for ORG workshop facilitation can be found here: Download.

Thursday, June 20, 2019

Eight signs that your quality sucks

Sustainable high quality is essential for the success of your product. When I get hired as an Agile Coach, I often encounter that quality isn't at all where people think it is, and in this article, I'll expose some of the key clues that quality sucks and the product has a huge pile of technical debt attached.

To tell you how obvious problems can be, I will exclude the options of "looking at the product" and "looking at the code", because that would be too easy.

When I see these signs, I will immediately drill in and go for the root cause with just a handful of questions, because the symptoms are dead give-aways of poor quality.

If you see one of these symptoms, that might be coincidence. If you see two or more, there's something fishy. And if you see all of them and don't have quality issues, I would surely like to hear from you, because I'd really love to learn how that is possible.

So here's my list of hints that you need to work on your product quality:

Pseudo Done

When teams play ticket ping pong and spend large amounts of time "fixing" things after an allegedly "Done" feature goes into test (or: live) then I first ask about their Definition of Done. Usually, they either have none - or one they don't live by...

Sticking to Formalities

Sometimes, I see fake User Stories like, "As an API, I want to be informed about changes to the database so that I can process the new data." or lists of wishy-washy Acceptance Criteria like, "Buttons are implemented". When teams and/or organizations don't even understand the "Why" behind simple tools and practices, how can they understand what's value for the product?

Not Releasing

If you haven't released in months, you're stacking up assumptions until you get into dreamland. You assume that you understand what users want and users assume that everything is going to be great. The release will later bring you down to reality, often with sore disappointment, massive rework and a hard course correction.

Top-Down Process

When people who don't actually do the work define how, what or when work should be done, I don't need further evidence. I'll need just a handful of "Why" and "How" questions that will make it glaringly obvious to everyone that things haven't been thought through and the outcome isn't going to be what it was supposed to be.

Snooze Refinement

When the only persons talking during Refinement are the Product Owner and the Lead Developer while everyone else remains silent and near motionless or no user joins the show, it's very likely that developers don't really understand what's the best way to translate demand into reults, and the outcome will be accordingly.


When your Reviews are a glamour show where only the sunny side of the product is presented, issues are masked or users don't get to actually touch the product until much later, you have no idea what quality level you're actually on. If you do indeed get feedback, but that has no effect on your backlog, you're closing your eyes to some very unpleasant facts.

Pointless Retrospectives

How can breakthrough improvement happen when by sticking to existing processes, tools and dogma? Many teams only do miniscule, cosmetic improvements without ever fundamentally questioning what they're doing or how they're doing it. If quality isn't increasing dramatically, it's declining in comparison to everything around - which, a few years down the line, will make a product obsolete.

Low Morale

Developers who do a great job and produce a great poduct tend to be proud of what they do. When most of what I hear boils down to complaints and frustration, I already know that the product sucks. Are developers forced to build the wrong thing, are they building it wrong, don't they understand what the right thing is? I don't know - but I know if they continue doing what they do, the product won't last long.

And then what?

What can you do if you observe any of these symptoms?
Ask yourself: "Why? Why do we have this situation, what causes it?"

The root cause isn't always the same, so a discovery journey is always in order - and then you get to decide what to do with the problem.

Friday, June 14, 2019

Don't get fooled by Fake Agile

Whichever consultancy sells this model, DO NOT let them anywhere near your IT!

So, I've come across this visual buzzword bingo in three major corporations already, and all of them believe that this is "how to do Agile". And all of them are looking for "Agile Coaches" to help them implement this garbage.

This is still the same old silo thinking that never worked.

There is so much wrong with this model that it would take an entire series of articles to explain.
Long story short: all the heavy buzzwords on this image merely relabel the same old dysfunctional Waterfall. In Bullet points:

  • "Design Thinking" isn't Design Thinking,
  • "Agile" isn't Agile,
  • "DevOps" isn't Devops. and 
  • Product Owners and Scrum Masters aren't, either.

Here is a video resource addressing this model:

I have no idea which consultancy is running around and selling this "Agile Factory Model" to corporations, but here's a piece of advice:
  • If someone is trying to sell you this thing to you as "Agile", do what HR always does: "Thank you very much for coming. We will call you, do not call us ..."
  • If someone within your organization is proposing to implement this model, send them to a Scrum - or preferably LeSS - training!
  • If someone is actually taking steps to "implement" this thing within your organization, put them on a more helpful project. Counting the holes in the ceiling, for example.

If this has just saved you a couple millions in consulting fees, you're welcome.

Tuesday, June 11, 2019

10 Bad reasons to choose Kanban over Scrum

"We're using Kanban instead of Scrum" - a common sentence, Especially since I do SAFe consulting, I hear this one quite frequently. Most reasons provided for this are anywhere between highly and extremely doubtful, and in many cases reveal ignorance both of Kanban and Scrum alike.

So here are my top 10 bad reasons for using Kanban instead of Scrum:

#1 - Our Consultant told us so

There's so much wrong with this sentence that it can't be fit into a single sentence.
First and foremost, if your consultant - after some short observations - knows your process better than you do, then you should seriously question what you're doing.
Also, a team should strive to be autonomous in decision making, and if your best reason for a decision is because someone else told you so, then you have absolutely no valid reason: you haven't understood what is best for your own good!

#2 - We had to choose

"Scrum or Kanban" is a false dichotomy. It's like saying, "Do you want a beverage or lunch?" - why not combine?
You can easily and very well combine Scrum with Kanban, as they address different problem domains. Whereas Scrum's primary concern is the nature of teamwork, Kanban focuses mainly on the flow of work. Especially has been investing significant effort in recent years to put together a "Professional Scrum with Kanban" curriculum which makes exactly this point.

#3 - 1 month is too short

A common argument I hear is that "we can't get anything Done in 4 weeks.
Sorry to say, if you're not getting anything Done in 4 weeks, chances are you're not doing Kanban either. Kanban is flow optimization, and if you sit back content with a cycle time of more than 30 days when other development professionals can easily do 1 week (or less), you're just being lazy. 
While some organizations are indeed so impedited that everything is moving slowly, working relentlessly to make the problems visible and finding creative solutions to make progress is essential to succeed in the long term.

#4 - Our work is too complex

"We do really complex stuff here, much more complex than anyone else!" - Every team which has ever mentioned this argument to me was applying a "special pleading" fallacy, usually oblivious of what other problem domains look like. 
I will admit that Logistics is complex. As is social media, telco, fintech and science. Scrum is specifically made for complex problem solving, so that's simply not a valid reason.

#5 - Our stories are too big

This argument translates to: "We set up a board and put a sticky on that won't be moving for a month and call this Kanban," Well, I hate to break the news: it isn't. Kanban is about managing the flow of work, and a Kanban board where nothing is moving hides transparency and makes optimization impossible.

I remember working with a corporation where team members adamantly insisted that stories estimated to take 4-6 months were already atomic and impossible to split any further. We took a few items from their backlog into a workshop and a 6-month user story was decomposed into almost 70 workable, individual slices of value. The biggest could be delivered in a few days, some within hours. Unsurprisingly, the entire package of all relevant items estimated to less than one month!

#6 - Requirements from all sides

If this is your reason for not using Scrum, you're defaulting! One of the main reasons for having a Product Owner in Scrum is to solve the problem that everyone thinks their specific problem is Priority 1. Where a requirement comes from doesn't matter - there's always one thing that is the best thing to do right now. Even in Kanban, an understanding of what is the most important thing is extremely helpful in order to "stop starting, start finishing". 

#7 - Maintenance is unplannable

Teams which operate on a live system oftentimes get exposed to unplanned work - bug fixes, support tickets, maintenance and whatever. My first question here is: "Why is maintenance so high?" Could taking time off the busywork treadmill help fix systemic issues reduce the amount of maintenance? I have seen such teams who purposely shifted towards Scrum and taking just a fraction of their capacity to address fundamental issues - they benefitted greatly!

#8 - Requirements change too fast

To me, this begs the question: "Are you getting things finished before the requirements change?"

Usually teams answer, "No", and then I seriously question why you're doing what you're doing. Scrum might help you sort out what's worth taking into account, trashing all whimsical ideas that are forgotten faster than they were proposed.
Just as an added side note, Scrum's sprint plan isn't immutable: There is nothing in Scrum which prevents you from integrating new information and opportunities as they arise.

#9 - Too many meetings

Scrum's events all serve a purpose of inspecting and adapting - not losing focus or track in a changing environment. There is no reason for Scrum events to fill their entire timebox and there's no need to do them in a specific way.
As long as you know why you're doing what, get frequent user feedback, improve your process and outcomes and keep the team synchronized, you're quite compatible with Scrum. If you are missing out on any of these items, your problem isn't the amount of meetings!

#10 - We don't do User Stories

I have no idea where the idea originates that Scrum teams must use User Stories, estimate in Story Points, create Burndown charts or whatnotever. When your reason against Scrum is a practice such as these, the short answer is that Scrum is neutral to practice. Scrum is merely mentioning "backlog items". These can be stories, requirements, bugs, defects, ideas or whatever else floats your boat.
Some teams find value in the User Story approach, others don't. Some estimate in Story Points, others in ideal days, yet others in amount of backlog items. All of these are valid from a Scrum perspective, although some may be more helpful than others.

Wrapping up

The discussion "Scrum or Kanban (or both)" is quite valuable for teams to determine how they want to organize themselves. Unfortunately, the discussion is often not factual and highly biased. It is often led with huge understanding deficits both regarding Kanban and Scrum.

There are a lot more bad reasons for preferring Kanban over Scrum than mentioned in this article, and there are also some good reasons for doing so. When your team mentions any of the items in this post, it's good to be suspicious and ask probing questions. Most likely you will uncover that Scrum is just a pretext and there is something else going on.

Expose the root cause and deal with it, because otherwise, critical problems might linger unaddressed.

Tuesday, June 4, 2019

Five sentences that will kill your Agile Transformation

There are some massive faux-pas statements with which senior management, potentially without even realizing, can kill an Agile Transformation within less than five seconds.

I normally avoid the term "Agile Transformation", because I think the idea itself is a dangerous suggestion that this is a time-limited process which can be completed to create a final stage, but let's look beyond that for a moment to focus on organizations who have explicitly started an Agile Transformation initiative.

While there are a near-infinite amount of ways to mess up something as complicated as Organizational Change Management, here are five sentences that can put an entire initiative to a screeching halt:

"Fund the change from your project budget"

There's no easier way to apply Larman's Laws than to apply existing accounting structures to an Agile Transformation. What do you think will be the outcome of such a transformation program, except an organization that still has the same line / project matrix organization which created the entire mess you're currently in?
And which project manager in their right mind would spend their project budget on necessary changes that will come into fruition much after the project deadline is reached?

The proper statement would be: "We have to re-examine our entire accounting structure in the mid term, and we will create a specific change fund for this initiative."

"Limit scope to IT"

Ignoring both the impact and consequence of an artificial limitation of scope fundamentally contradicts the concept of systems thinking, which relies on acknowleding both the implicit and explicit relationships of the whole system.
I always use the clockwork metaphor: If you try to speed up a single cog, there are three likely outcomes: The surrounding cogs will absorb the change, the watch will tick wrong, or the cog will break. IT is a cog of an organization, and the results will be accordingly.
If you have this approach in mind, either abandon the idea or the change altogether. It will save you a lot of pain later on.

The proper statement would be: "Start where you are, and when you hit an organizational boundary, pull in people as necessary."

"You can do this"

What sounds like a great motivational statement betrays yet another pillar of systems thinking: Management was responsible for creating the current status quo, and unless management actively contributes in changing this status quo, it will remain unchanged.
As long as management doesn't do their part, statements like "We trust you on this" are adding insult to injury, setting teams up for failure, creating negativity and bad blood in the long term.
If you're a manager and not going all-in, you are going to be an impediment!

I'll take it with Deming:
"Support of top management is not sufficient. It is not enough that top management commit themselves for life to quality and productivity. They must know what it is that they are committed to — that is, what they must do. These obligations can not be delegated. Support is not enough: action is required." - W.E. Deming
The proper statement would be: "We can do this."

"We're already good"

I am baffled when I ask managers what they expect from their agile transformation, and they limit their answer to this sentence: "We're already good, we're just looking for ways to become more efficient."

While I'm not going to argue whether they're indeed good, the attitude behind this sentence will make it extremely difficult to realize that an agile transformation is not needed if indicators like Customer Satisfaction, Time-To-Market and Product Viability are good. If these things are not good, then "getting more efficient" is entirely the wrong direction!

"This is not important"

It's a jaw-dropping moment to sit in a room with over one hundred developers, hearing a Senior Manager introduce the new way of working to the audience with the words, "SAFe is not important". Okay. SAFe is a placeholder, it could be any other framework as well.

Well, if it isn't, why did you opt to go this route for your agile transformation? Did you bother defining your organizational goals, current deficits, map them with the different frameworks and see which approach is most suitable to meet your needs?
If you didn't do that, you simply didn't do your homework, and you shouldn't have chosen a specific framework before doing that!
And if you did that, you might as well inspire people by giving them something to aspire, rather than planting a dismissive notion in their minds!

The proper statement would be: "We chose this framework as a basis to reach our goals - and we will relentlessly Inspect, Adapt and Improve to get better every day!"

In Summary

A Whole Systems Approach is fundamental to any organizational change initiative, be it Agile or otherwise. When managers reveal that they either haven't considered the systemic impact, or simply don't care, they give everyone a good reason to doubt the success of the change from Day One.

Monday, May 27, 2019

It's still about agile teams

With all the ranting around SAFe recently, I want to address one of the most common, and likewise most severe, dysfunctions in many SAFe implementations: The lack of a solid foundation in agility.

To make my point, I will take a heavily biased stance, and I am fully aware of the bias I present.

Cracking the crust paved by traditional organizational structure requires patience - and it's a slow process.

Why SAFe sucks

We start with a hierarchical organization that wouldn't know Agile if it slapped the CEO right in the face. Then, we bring in a swarm of consultants, do some Leadership training. Everyone's excited. Management huddles together and conceptualizes the new hierarchy, called "Large Solutions" and "Agile Release Trains".

When this is done, we select the members of the new hierarchy, called "Train Engineers", "Architects" and "Product/Solution Managers" and train them for their new role. All of them have been selected based on their importance in former power structures, giving each of them at least as much power as they had before.

Once that is done, we forcefully rearrange formerly functional teams in order to meet the new structure, which relabels "departments" to "value streams", "project managers" to "Product Owners" and "Team Leads" to "Scrum Masters". Off for another round of trainings, also including team members for two days and then ...

We do a PI Planning where the Waterfall Agenda is presented to the teams and then everyone has to created a detail upfront plan and commit to management's unrealistic expectations.

Done. Well, almost. Teams now report and get tracked against their 2-weeks micromanaged commitment until the next PI Planning, where the last plan is supposed to be finished.

That's the Real World!

It would be a lie to say I haven't seen this happen. The amount of dysfunctions in this approach are so numerable that it would take hours to list them all out.

Here are just the few biggest problems with the approach:
  1. SAFe is considered a management methodology, not a development approach.
  2. Management buys into something they didn't even understand.
  3. Developers were never asked for their opinion.
  4. SAFe was immediately adjusted to preserve the existing system.
  5. Mindset never changed.
  6. SAFe was introduced as a structural change, not as a way of changing how value is produced.
  7. No effort was made to even attempt and understand what "Agile" means.
Is this the fault of SAFe, neglect on management side, time pressure or some evil consultancy's attempt to screw over someone for a quick buck?
I don't know, and I will not argue, because the issues described are generic and root causes could be different in different places. 

The basis is still the Agile Team

What people forget: SAFe is quite clear that the basis of an Agile Release Train and the SAFe organization is still an Agile Team.
SAFe is the only agile framework which does acknowledge that Agile Teams can have their own, individual mode of working that may or may not coincide with Scrum, XP or Kanban - the only constraint is that the team needs to be agile!

Sadly, organizations do not invest into team level agility before pushing in SAFe. For whatever reason - SAFe oftentimes becomes a dysfunctional relabelling exercise because no effort has been taken to agilize teams.

The illusion of fast results

While Agile teams can deliver high quality Working Software in short cycles, the amount of effort required to bring a team to this level is immense. Many times, management just declares, "We are now Agile" without investing into team building, sustainable engineering practices and agile mindset.

This doesn't work and it will be a flash in the pan. Results will remain elusive, as the organization will effectively accumulate further organizational debt without addressing the underlying issues.

Teams do not become Agile by declaration, and they also do not become Agile by pushing a framework like Scrum or Kanban onto them.

Investing into Agile Teams

Agility is a slow, challenging process with a long and steep learning curve. A two-day training is not much more than waving the "Go" flag on a race track, and some organizations are even cutting corners there - thinking that "it's already enough when we sent Scrum Masters to training": NO!

To be agile, a team needs:

  • Operational Excellence
  • Technical Excellence
  • Drive (ref. Dan Pink)
Based on my experience, the willingness of organizations to invest time and money into these items decreases exponentially in descending order of the list, and it often starts at a staggering low.

Raising Agile Teams

Agile teams are in little need as by definition, they are already self-organized, understand their domain and deliver amazing results. When a team isn't described by these three attributes, they aren't agile to begin with and do not meet the minimum requirements for a SAFe organization!

Teams that are not on this level need a lot more care and support.
Some of this is achieved by management action: changing processes, structures and constraints in order to enable the teams to get there.
Another big enabler is coaching: working with the teams, helping them discover the necessary means  to take control of their work and adopt the practices which help them deliver excellent results.

Coaching is a slow process. It can't be done in a day or two, and workshop sessions - while indeed helpful for specific aspects - aren't sufficient to establish a new culture.

Unfortunately, many organizations invest insufficient time and budget into the necessary groundwork for raising agile teams. Is it suprising then that teams - and ultimately these organizations - struggle?

Sustaining Agile Teams

Agile teams stay (and grow more) agile when their environment supports agility. When an agile team is shoved into a non-agile box, the constraints will force the team to reduce their own level of agility to meet external constraints. 
When SAFe is adopted carelessly, imposing non-agile constraints on otherwise agile teams, the organization's overall level of agility will be limited accordingly. 

In order to get the most benefits out of SAFe, the question should be more along the lines of "Which organizational constraints become superfluous or redundant due to having a SAFe organization", rather than, "Which constraints do we need to add on top of a SAFe organization?"

When organizations abuse SAFe in order to introduce impediments to team-level agility, poor outcomes are the logical consequence.

Nurturing Agile Teams

Agile teams will find a supportive environment highly beneficial in order to deliver even higher business value. Where individual agile teams oftentimes struggle at arbitrary organizational boundaries - from fixed department structures to other "autonomous" agile teams - organizational change, overarching alignment and the occasional global optimization at the expense of local autonomy are indeed a benefit to systemic agility.

SAFe can then be used to provide minimal guiding structure to teams operating in larger environments, referring to common patterns addressing challenging systemic impediments.

The very reason for having experienced SPC's on board would be to both stop the people who lack agile experience from over-engineering upfront, and then pointing out exactly those SAFe patterns which can be considered when a systemic impediment becomes significant.

Unfortunately, we see too many organizations pre-conceiving "the perfect agile organization" as fast as possible and as closely as possible to the SAFe Big Picture - and then implementing it by following a plan without responding to change (which never works).
Managers are quick to proclaim that certain solutions are needed when no team has raised an impediment, and thus un-necessary structure is implemented on a whim.

Agile Management

You can't manage agile teams without being agile yourself. Before managers have changed their own mindset, attitude and understanding, they will not succeed at creating an agile organization at scale.
Most managers fail at the very simple exercise of becoming agile themselves in order to serve agile teams.

Management failure occurs at three levels:
  1. Thinking that "Agile" is for development teams only
  2. Limiting "Agile" to IT
  3. Not investing time into changing themselves
Until management comes to see their own role in the current system, and that change relies on them lifting their own anchoring of an old status quo, agility will remain a fluke.

Management philosophy and practice change is essential for SAFe to result in an Agile Organization.

My Advice

SAFe without a foundation of agile teams is madness.
SAFe driven by the organization without considering agile teams is pointless. 
SAFe imposed by management against the will of teams is craziness.

When an organization does these things, any SAFe initiative is pretty much doomed.

My advice is to take the following steps:
  1. Establish agile teams to begin with. If you can't do that, don't even think of SAFe.
  2. Invest as much into your agile teams as needed. If you aren't willing to do that, SAFe is waste.
  3. Create an environment where your agile teams can thrive. If you think you can't, SAFe isn't going to improve the situation.
  4. After you did 1-3, seriously consider which challenges you want to address and where your teams struggle. Do not introduce SAFe as a solution to problems you don't have!

Friday, May 17, 2019

Need Gap Reduction

Let's cut straight through the bullshit. You want to become agile and ask yourself, "How do we know if we're making progress?"
This one simple metric tells you if you're moving in the right direction.

If you're not reducing the Need Gap, you're doing it wrong!

The Need Gap

A "Need Gap" exists between the time when I, as a consumer, realize that I would need something - until the need is satisfied.

The difficulty of many classical projects is that the need may be satisfied in other ways outside the project's scope or it may completely disappear even before the project's outcomes are delivered.

Why not ...

There are other common metrics. Couldn't we also choose them?
Okay, I'm cheating a bit here. The "Need Gap" is two-dimensional, so it's actually two metrics, so I'm not ditching common agile


Time-To-Market is simply an incomplete metric. It doesn't account for the (potentially massive) time lapse between making the solution available and the solution achieving its purpose.


Value is related to wealth obtained by providing the solution, although the amount of wealth benefit that can be monetized depends on many factors. To avoid having to go into a full economics discourse on game theory, we can simplify this by saying that value is again an incomplete metric.


In a business context, "learning" is related to an unfocused metric that needs to have context. Things we might want to learn should ultimately lead to a bottom line.
For example, learning:
  • Expressed, unexpressed and upcoming needs
  • Better ways of meeting needs
  • Monetizing customer wealth gain
Ultimately, learning is an enabler to addressing the Need Gap.

The Need Gap

A need gap indicates both a delay in satisfaction and an impact on wealth.

Time to Satisfaction

The time to satisfaction is the lead time plus delivery time plus customer reception time, including any potential feedback cycles until the customer is happy with the outcome.

Impact on Wealth

Customer wealth is a function both of money and other factors. 
Cost reduces wealth - as does the unmet need itself, whereas the customer's own ROI increases their wealth.
Economic customers are looking to increase their wealth, so the cost spent on meeting the need should be lower than their loss of not having met the need.

Rising Need Gap

The need gap grows in multiple ways:
  • When the time between feeling a need and meeting its need, the need gap grows
  • When the customer's wealth is reduced
As the need gap grows, the customer's self-interest in discovering alternate solutions also grows. 

Reducing the Need Gap

Ideally, there is no "Need Gap" from a customer - by the time a customer realizes a need, they have their need met:

  • When the Need Gap is low, there is little customer benefit to making changes in the way of working.
  • When the Need Gap is high, the customer benefits from making changes that reduce this need gap.
  • When the Need Gap doesn't get reduced, then the customer has no benefit from any change made in the process.
A reduction of need gap implies the goal-focused
  • increase in customer value, 
  • reduction of processing time,
  • keeping of development cost to lower than the delivered benefit,
  • improvement of value management and discovery,
  • closure of feedback loops,
  • optimization of monetization

Measuring the Need Gap

The Need Gap is quite easy to measure - look at the time between when people first speak of a need until people stop talking about it and how (un-)happy customers are during that time.

Wednesday, May 15, 2019

There's no such thing as a DevOps Department

"Can we set up a DevOps Department, and if so: How do we proceed in doing this?"
As the title reads, my take is: No.

Recently, I was in a conversation with a middle manager, let's call him Terry, whose organization just recently started to move towards agility. He had a serious concern, and asked for help. The following conversation ensued - (with some creative license to protect privacy of the individual) :

The conversation

Terry: "I'm in charge of our upcoming DevOps department and have a question to you, as an experienced agile transformation expert: How big should the DevOps department be?"

Me: "I really don't know how to answer this, let me ask you some questions first."
Me: "What do you even mean by, 'DevOps Department'? What are they supposed to do?"

Terry: "You know, DevOps. Setting up dev tools, creating the CD pipeline, providing environments, deployment, monitoring. Regular DevOps tasks."

Me: "Why would you form a separate department for that and not let that be part of the Development teams?"

Terry: "Because if teams take care of their own tools and infrastructure, they will be using lots of different tools."

Me: "And that would be a problem, as in: how?"

Terry: "There would be lots of redundant instances of stuff like Jira and Sonar and we might be paying license fees multiple times."

Me: "And that would be a problem, as in: how?"

Terry: "Well, we need a DevOps department because otherwise, there will be lots of local optimization, extra expenses and confusion."

Me: "Do you actually observe any of these things on a significant scale?"

Terry: "Not yet, but there will be. But back to my question: How big should the department be, what's the best practice?"

Me: "Have you even researched the topic a little bit on the Internet yet?"

Terry: "I was looking how many percent of a project's budget should be assigned for the DevOps unit."
Terry: "And every resource I looked pretty much said the same thing, 'Don't do it.'.But that's not what I am looking for."

Me: "Sorry Terry, there is so much we need to clarify here that the only advice I can give you for the moment is to reflect WHY every internet resource you could find suggested to not do it."

Why not?

Maybe you are a Terry and looking for how to set up a DevOps department, so let me get into the reasons where I think Terry took a wrong turn.

  • Terry was still thinking in functional separation, classic Tayloristic Silo structures, and instead of researching what agile organizations actually look like, he was working with the assumption that agile structures are the same thing.
  • Terry fell into another trap: not even understanding what DevOps is, thinking it was only about tools and servers. Indeed, DevOps is nothing more than removing the separation between Dev and Ops - a DevOps is both Dev and Ops, not a separate department that does neither properly.
  • Terry presumed that "The Perfect DevOps toolbox" exists, whereas every system is different, every team is different, every customer is different. While certain tools are fairly wide-spread, it's up to the team to decide what they can work with best.
  • Terry presumed that it is by default centralization is an optimization. While indeed, both centralization and decentralization have trade-offs, centralization has a massive opportunity cost that needs to be warranted by a use case first!
  • Terry wanted to solve fictional problems. "Could, might, will" without observable evidence are probably the biggest reason for wasted company resources. Oddly enough, DevOps is all about data-driven decision makings and total, automated process control. A DevOps mindset would never permit major investments into undefined opportunities.
  • Terry was thinking in terms of classical project-based resource allocation and funding. Not even this premise makes sense in an agile organization, and it's a major impediment towards customer satisfaction and sustainable quality. DevOps is primarily a quality initiative, and when your basic organizational structure doesn't support quality, DevOps is just a buzzword.

Reasons for DevOps

Some more key problems that DevOps tries to address:
  • Organizational hoops required to get the tools developers need to do their job: Creating a different organizational hoop is just putting lipstick on a pig.
  • Developers don't know what's happening on Production: Any form of delegation doesn't solve the problem.
  • Handovers slowing down the process: It doesn't matter what the name of the handover party is, it's still a handover.
  • Manual activity and faulty documentation: Defects in the delivery chain are best prevented by making the people with an idea responsible for success. 
  • Lack of evidence: An organization with low traceability from cause to action will not improve this by further decoupling cause and action.

How-To: DevOps

  • If you have Dev and Ops, drop the labels and call all of them Developers. Oh - and don't replace it with the DevOps label, either!
  • Equip developers with the necessary knowledge to bear the responsibility of Operations activity.
  • Enable developers to use the required tools to bring every part of the environment fully under automated control,
  • Bring developers closer to the users, either by direct dialog or through data.
  • Move towards data-driven decision making on all levels: Task-wise, structurally, organizationally and strategically.

And that is my take on the subject of setting up a DevOps department.