Sorry, Agilists - your frameworks are a problem!

It’s 2019, a full generation since the Manifesto for Agile Software Development was compiled - and although “Agile” has become the norm, the Agile Community isn’t really going anywhere: What we see is a horde of trainers and consultants (nowadays called “coaches”) claiming that they have already found this “better way” - which can make us wonder: are the agile frameworks really better, and: compared to what? 

This article is a provocation. When I address “You”, that’s an oversimplification which does not apply to everyone in the agile community, and I am aware that there are indeed a few (unfortunately rare) exceptions that this article doesn’t address. As the old joke goes, “It’s 99.9% of lawyers that give the rest a bad name.” Is the Agile community any different? Should you think that any of my provocations below are made from ignorance or that the claims I have blatantly put in “Your” mouth are indeed true, you’re exacerbating the problem!

I won’t discriminate between the different frameworks out there and simply refer to “Your Agile Framework”. Feel free to insert your favorite flavour - my claims don’t change. The intent of this article is to highlight principles and not specifics of any one framework, otherwise this would be a book rather than a blog post. I have caught some assertions about your Agile Framework and propose a plausible counter hypothesis for each. Think about it!

1 - Your Agile Framework is missing the point

There’s so much more to running a successful business than your Agile Framework accounts for. Your Agile Framework doesn’t change anything in the big picture. Indeed, with increasing popularity, your Agile Framework is becoming a bigger problem!
You’re talking a lot about systems thinking, yet fail to realize that introducing a point-based structural change like your Agile Framework is ineffective. Systems thinking goes much further than structure and process!
Without a deep understanding of complex adaptive systems, you are of no help.

Your Agile Framework is not reliable.

You claim: “The utility of the Agile Framework is proven daily.”

People implement your Agile Framework perfectly and see no difference. Many use your Agile Framework exactly as it is described - and fail!
People who know what they’re doing and not using your Agile Framework will do better than those who don’t know what they’re doing and using your Agile Framework.

You selectively cherry-pick the few cases where people happened to both know what they’re doing and used your Agile Framework, then claim that this is proof that your Agile Framework is useful. This is just a placebo effect.

Your Agile Framework doesn’t lead to success.

You claim: “If you use the Agile Framework correctly, you will succeed” - and: “In all cases where people didn’t succeed, they didn’t use the Agile Framework correctly.”

Smart people working on great products fail miserably while using your Agile Framework exactly as intended. Even if you yourself succeeded repeatedly with your Agile Framework, your next endeavour could be your worst failure ever - and there’s nothing your Agile Framework will change about it!

Your Agile Framework doesn’t even contribute to success.

You claim: “The Agile Framework is being used for all kinds of work on all kinds of products and in all kinds of industries.”

Sorry, this has to be: “Blue shirts are being used for all kinds of work on all kinds of products and in all kinds of industries.” - what a heap of baloney!
There is no causal link between using your Agile Framework and success in any kind of work, in no industry. There’s not even a hint of a correlation. Any suggestion to the contrary relies on wishful thinking and confirmation bias.

Your Agile Framework might improve nothing.

You claim: “People who use the Agile Framework are more likely to succeed.”

Your Agile Framework is not better than what organizations that relentlessly Inspect and Adapt are already doing. While your Agile Framework may be a way to frame your problems differently, if you have no idea how to solve them, you will remain stuck. And if you don’t know how to structure your problems, your Agile Framework won’t even help there!

Your Agile Framework doesn’t deliver more value.

You claim: “The Agile Framework increases the value delivered.”

Any halfway decent Product Manager doesn’t need your Agile Framework to deliver maximum value. If organizations have no competent product management, your Agile Framework doesn’t help, either. What your Agile Framework has to say about determining Value is infantile, ignorant of the vast bodies of knowledge about value determination that are already available.

Your Agile Framework won’t make anything faster.

You claim: “The Agile Framework speeds up the delivery of value.”

It’s possible to streamline delivery without using your Agile Framework, and even people using your Agile Framework as prescribed may have horrible Time-to-Market. Your Agile Framework doesn’t replace a thorough Lead Time Analysis with consequential removal of inventory waste. An organization that has already optimized their delivery process will not become any faster by adopting your Agile Framework.

Your Agile Framework doesn’t increase customer satisfaction.

You claim: “The Agile Framework improves customer satisfaction.”

The standards defined in your Agile Framework you might actually cause a decrease in customer interactions in highly customer-centric environments. Are you even aware that your Agile Framework was explicitly designed to shield developers from customers? Your Agile Framework provides a mantle that can be used to reduce customer transparency and decrease the customer’s trust in your development.

Your Agile Framework itself isn't agile.

You claim: “The Agile Framework enhances the team’s flexibility”

Your Agile Framework relies on dogmatic rules that can’t be bent or violated. You will even go as far as claiming that breaking these rules is the cause for failure, when breaking these rules may indeed be maximizing the odds of succeeding. Those who understand the rules of your Agile Framework don’t need them - and vice versa. Your framework does very little to remedy this situation, so a vast majority of people use your Agile Framework without understanding what they’re even doing.

Your Agile Framework doesn’t reduce IT cost.

You claim: “The Agile Framework reduces costs.”

Unless you plan on firing people, IT cost will not go down. In all likelihood, your Agile Framework will require a significantly increased IT budget!
A developer’s paycheck won’t magically decrease by using your Agile Framework.
Servers and infrastructure cost also won’t go down because of your Agile Framework, either. As agile ways of working spread, additional hardware - and therefore, additional cost, becomes inevitable.
And if there’s no bucket for coaching or training, your Agile Framework will fail.

Your Agile Framework isn’t worth investing into.

You claim: “The Agile Framework investment will pay for itself.”

There are better ways to invest the money than into your Agile Framework. You may say that the investment into training or consulting services will be a positive business case, but wouldn’t be willing to operate on a profit share model. You well know that you’d work for free if you got paid according to the tangible benefits generated by your Agile Framework.

2 - Your Agile Framework is a threat!

The Manifesto for Agile Software Development was written by people who were seeking for “better ways” for software development, yet what people have turned it into is a cultic religion that spreads like rabies across the world. It benefits a select few on top of the food chain, while exploiting and victimizing hordes of noble truth seekers who aren’t in it for the money, but for a better world.
Your Agile Framework damages individuals, endangering organizations and impedes the progress of society!

Your Agile Framework exploits a predicament.

You claim: “The Agile Framework should be introduced enterprise-wide.”

The importance of software in business increases daily. Managers who find themselves missing a way to reliably succeed in this domain will grasp for straws. In their ignorance, they turn to anyone who promises to increase their odds of succeeding. Just like the quacks who sell miracle pills to make a quick buck out of other people’s predicament, you market your Agile Framework as though it solved this problem. Once the special effects show is over, the client lost precious time and money to the quack, while the real problem never got addressed.
Such exploitation is banned in socially advanced societies, because it replaces choices from free will with the imposition of severe harm.

Your Agile Framework equivocates software development and business development.

You claim: “The Agile Framework enables Business Agility.”

Your Agile Framework doesn’t even address any business challenges in a meaningful way. You don’t even realize that your Agile Framework wasn’t designed in an attempt to address business challenges - it was designed to help people develop software better. In management, the idea of “agile enterprise” has an entirely different meaning than in IT, and you play on this equivocation fallacy to increase the audience for your Agile Framework. Assuming that your Agile Framework can be equally used in areas it was never meant for is horrible advice.

Your Agile Framework is a strategic nightmare.

You claim: “The Agile Framework keeps all the work in a prioritized backlog”

Your Agile Framework operates with a myopic and limited understanding of importance. Urgency trumps foresight. Your Agile Framework's focus on short-term product value in the next Increment undermines and damages strategic enterprise development. Your ignorance in dealing with market forces pushes your product - and your company - to the verge of extinction.

Your Agile Framework breeds mediocrity.

You claim: “The Agile Framework treats everyone equal”

Progress isn’t made by making everyone equal - it’s made by bringing forth the talent in bright people. Your Agile Frameworks’ promotion of collaboration has turned into a disdain for individualism. “Swarm Intelligence” is just a euphemism for “groupthink” - where radical, innovative ideas have no place and “vastly different” is considered a threat, not an opportunity.
What really brought society forward were always the people who just didn’t fit in. Outsiders like Alan Turing would have no place in the society you promote. Your Agile Framework would have lost the British World War II - aren’t we glad they didn’t know about it yet?

Your Agile Framework impedes learning.

You claim: “The Agile Framework broadens horizons.”

Your Agile Framework is limiting your horizon. It ignores a vast ocean of available knowledge. You are happy to float in your little bubble where the easy answer for every question is, “You have to find out”, although the research has already been done outside your bubble. Hence, you’re going around in circles, re-inventing the wheel. That’s also why you turn people into celebrities who have just “discovered” things that people outside your Agile Framework Community have already understood, published and applied decades ago.

Your Agile Framework Community is an Echo Chamber.

You claim: “We have a vast community for learning from others.”

You have chosen to put yourself into an echo chamber where you constantly get bombarded with reaffirming messages. You enjoy hearing yet another person affirming what you already know. You limit your professional interactions to supporters of your Agile Framework. People who disagree with your perspective are no longer welcome. You stigmatize and label dissent as “unenlightened” and use terms like, “not teachable” or “not coachable” and attribute this to an “unwillingness to learn”.
You can’t entertaining the thought that you could be wrong, and that makes you totalitarian!

Your Agile Framework exploits problems without fixing them.

You claim: “Certified Practitioners are an advantage for companies”

Hordes of Agile Framework certification holders suggest to companies that the certificates are important. Companies can’t discern whether people who hold that certificate know what they’re talking about. Certificate holders think they know what they’re talking about, although many of them will cause more harm than help. And uncertified practitioners, although highly adept, are coerced to waste time and money on a meaningless certificate to avoid being sorted out by automatic filters.

Your Agile Framework operates on a ponzi scheme.

You claim: “The Agile Framework creates a better world.”

Your Agile Framework exhibits all the signs of a ponzi scheme with an immutable hierarchy that has only one purpose: provide easy money and reputation to those at the top.
You have the founders, you have the trainers, you have a mass of certified people - and uncertified practitioners. Everyone is welcome to become a paying member, but only those who will help those already in the scheme earn more money are welcome to rise in rank. FOMO (Fear Of Missing Out) keeps people paying those subscription fees, although the vast majority of certified people gain no benefit in return. And no, a monthly newsletter doesn’t count - their work, life or understanding doesn’t improve.

Your Agile Framework blocks actual progress.

You claim: “The Agile Framework dissolves hierarchies.”

If you want to make progress in the hierarchy of your Agile Framework, you’d better be a sycophant who praises every word of those whose approval is required for promotion. You won’t make progress by innovating or trying to improve things. It’s not desired, because it would reveal the incompetence of those above you. Improvements must always come from the top. And the longer your Agile Framework hierarchy is established, the less significant the changes within your Agile Framework become. Do you really believe that you have already reached the peak of human potential?

3 - You can’t refute my claims

Agilists don’t seem to get that there is, at best, very weak evidence for their claims. There is no sound chain of reasoning to bring us from what you believe to what is actually happening.
I can hear you crying foul now, because there’s a plethora of success stories, many even written by organizations and/or individuals that adopted your Agile Framework. All of this is fallacious.

Your Agile Framework hurls us back to the Middle Ages

In the Middle Ages, life worked like this: You tried something, and if you observe something even remotely related to a positive result, you could claim that the action caused the effect.
For example, some wise person might claim that by following a certain medical treatment, we can cure some sickness. Since my neighbor did it and got better, I would accept that treatment as the cure. Today, we call this “confirmation bias”, and have long since rejected the notion.

Your Agile Framework hurls us right back to the Middle Ages: People claim that by observing the rules of your Agile Framework strictly, key strategic problems would get solved. And since it allegedly worked for the neighbor, the framework must be the cure. Is that even possible, though?

What brought us out of the Middle Ages is science: the relentless, scrupulous attempt to make sense of the world around us. Science relies on testable, verifiable, evidence. We replace fallacious post hoc, ergo propter hoc reasoning and cognitive biaseses with traceable chains of evidence.

Rational people reject claims contradicted by evidence and have no reason to accept claims without supporting evidence. And your Agile Framework doesn’t meet this standard. It would be irrational to accept your claims.

You don’t have evidence to support your Agile Framework!

Agilists don’t even bother to ponder what constitutes proper evidence. You bask in ignorance and rely on peer pressure to silence dissent. You make bold faced assertions, regurgitate mined quotes, appeal to authorities and spice it up with flawed anecdotes or analogies and think you made your point.
If our legal system would accept such “proof”, you could get convicted of a felony you never committed - fortunately, it doesn’t!

You don’t even use correct syllogisms!

While you see that “When it rains, the street gets wet. The street is wet, therefore it rained” is fallacious, you’re incapable of comprehending why “Performance improved after using our Agile Framework, therefore our Agile Framework improved performance” is a fallacy. And if anyone still doubts, you’ll just follow up with a classic argument from ignorance, "What else should have caused it?" - which isn’t helping your case, either.
You don't know how to make your point with appropriate syllogisms.

You don’t understand how evidence works!

You think that “Company X used this Agile Framework, and Company X is successful” is evidence for the benefits of your Agile Framework, yet you dismiss the idea that “Company Y used the same Agile Framework, Company Y failed miserably” could be evidence that the Agile Framework doesn’t deliver.  “5 is odd, and 5 is a prime number” is not evidence that odd numbers are prime numbers, and “9 is odd, and 9 is not a prime number” is fully sufficient evidence that the claim “odd numbers are prime numbers” is false. Is it a lack of intellectual capacity or integrity that you won’t accept this misuse of evidence?

Your reasoning is terrible!

You propose assertions that you expect others to accept, yet without proof. Indeed - you can’t even prove that the opposite isn’t true and ignore all the evidence pointing elsewhere. If your assertion were true, invalidating my proposed counter hypothesis should be child’s play. Until then, your assertions should be rejected. If you can’t invalidate any of my hypotheses, you’re holding a bottle of snake oil!

You use references that you don’t know!

Your argumentation is spiced up to the brim with fallacious appeals to authority. 

You do not know what Royce actually proposed when you refer to “Waterfall”, you have no idea what vision Taylor had for management. You refer to them in a condescending way,  when indeed they fought on the same side of the battle you claim to be fighting on!

Likewise, you quote Deming without ever having understood which Crisis we have to get out of, you quote Drucker without understanding the Organization of the Future, you quote Senge not even knowing the first four disciplines and you have no qualms to quote Taiichi Ohno without grasping even the main ideas of the Toyota System.

4 - Conclusion

This article is a bombardment of provocations, intended to strongly shake everything you might believe about agility.

I am challenging you for a thorough, profound rebuttal - a task that I believe very few would have the capacity for.

If you don't know how to refute my claims with sound reason and evidence, please go back and reconsider what you are doing.
You may be a part of the problem the Agile Industry is causing.

What's a Community of Practice?

Especially since SAFe is on the rise, companies are trying to establish "Communities of Practice" (CoP) and may not even be clear on what that is supposed to be. Some try to shoehorn their old line structure into CoPs, with meager results. Here are some comments from my own experience.

Defining a Community of Practice

A CoP is nothing more or less than a group of people with a shared purpose, as the Manifesto sfor Agile Software Development states, "uncovering better ways (...) by doing and helping others do it".
That means, communities typically consist of subject matter experts and/or those professing to become such.

Shared Purpose

Every Community needs a shared purpose, and that purpose can be whatever the community makes their purpose.
Very common types of communities I see in many organizations include:

• Testing / Quality
• Architecture
• DevOps
• Data Protection & Compliance
• User Experience

... you get the gist.

Sometimes, communities form around very specific organizational issues, such as "Customer Complaints" or "Return Shipments" - such communities tend to have the purpose of bringing themselves out of existence. This already hints that a community may also consist of non-technical people as well: Communities are not limited by department boundaries.

Voluntary Participation

Communities live from their members' participation. The best communities consist entirely of members who desire to be part of the community and have a personal interest in making their participation as useful as possible.

With such voluntarism, both attendance and non-attendance in community events are an indicator of the community's success. 

Organizational mechanic (process, decree etc.) mandating community participation will cause results and progress of communities to dwindle.

Openness

Communities are most effective when they are open to people from "outside" to bring in additional helpful ideas and carry their own results for others' benefit as well. Growing communities that have an appeal to a large audience, even many who only participate occasionally, have the biggest impact.
On the other hand, closing the community to an "elite" will limit their learning, impact and organizational acceptance.

Organizational Integration

Communities are workfloor-level organizational constructs. They consist of people who practice (hence their name), they are for people who do the work and they serve no purpose other than making the work better. As such, they do not need to be "managed", "controlled" or "reported".

Accountability

A community is a peer group built on trust, respect and growth. The community as a whole is accountable to the organization in terms of their purpose. Members are accountable to their peers in terms of whatever they decide to commit to. And finally, as community members have a "home" in a team, they are also accountable to their team to use their community time wisely and in the best interests of the team.

Management

A community of experts might have a line manager (e.g., "Head of Quality"), who may or may not be involved in the activities of the community itself.
Here is some personal advice based on my experience with managers and CoPs:

• the manager may encourage starting a CoP, but should not enlist one, and definitely not "manage" one.
• the manager should not attend unless invited and only speak once they have clearly understood the impact of their words and actions on the group.
• the manager can support their community by removing impediments that the community raised.

Reporting

Members who did do experiments may report their learnings back to the community in whatever form they consider appropriate.
The concept of traditional Reporting is out of place in communities. A community "reports" to nobody, as that destroys the entire point of being self-organised and brings in a lot of dangerous power dynamics which could invalidate the entire idea of forming a community.

Team alignment

Members of communities should feel free to do any of the following, at any time, in alignment with their team:

• Join one or more Communities
• Invest time and effort into community activity
• Discuss CoP topics with the team
• Withdraw from a CoP
• Participate as guest in other Communities

There is no obligation that every team must have one member in every community. Sometimes, half a team is already half the community - and often, many teams have no members in certain communities.

Leadership

Mature communities are peer groups that operate as a decentralized network. They do not rely on the concept of single person leadership, but rather on the concepts of personal responsibility and ownership.

Practice lead

Many Communities are led by a peer expert to keep the momentum up. Ideally, this is the person who cares most for making beneficial changes. The CoP lead is a "primus inter pares" who leads by competence and through action, not position.
As a note of caution: When "talkers, not doers" lead a Community, others' interest will wane quickly.

Coaching support

A coach can serve as facilitator to the help find out the current practices, discover levers for change, reach agreements on next steps and encouraging members to take action.
When a coach is required to keep the community alive - let it die!

Impermanence

The existence of communities should be linked to their importance. A community trying to improve the organization's biggest problem may need to be quite active, investing a significant portion of their time to make progress. When a community has no significant purpose, community activity is waste. 

Organizational Freedom

The organization should support their members to form communities at any point in time when people feel that they have an important purpose, and likewise encourage people to abandon the community when the purpose is longer important.

The organization itself should foster no form of "attachment" to specific communities.

How Agilists betray the very nature of Agility

Almost two decades ago, a handful of people started a joint journey of "uncovering better ways of developing software and helping others do it". The first value was "People and Interactions over Processes and tools". 

Scrum emphasizes the values of Openness and Respect. Coaches are expected to both exhibit and nurture a Growth Mindset.

And what to we do? The opposite!

Trigger Alert - this post will push a lot of hot buttons!

What have we become?

A large number of agilists get triggered really fast, really strong and really bad as soon as they read or hear certain terms. Why have the very people who proudly bear the labels of openness and respect, become so narrow-minded and show almost hostile reactions as soon as a few trigger words are uttered?

People who even dare to use certain words get stigmatized as "unenlightened" and "anti-agile" and are being told to "defend themselves" or apologize. This is neither open nor respectful towards the individual, much less towards their ideas.  Is this the type of interaction with people that agilists looking for?

When have we stopped thinking or asking, "What does the other person mean?" Why do agilists go into full confrontation mode as soon as these words are uttered? How is that behaviour different from a fascist regime where everyone who thinks different must either be converted or eliminated?

Creating taboos and instituting thought crimes fosters an environment where true agility becomes impossible. 

Trigger, trigger, trigger ...

It can be that you had bad experiences a hundred times and think you understand the antipatterns, but isn't it exactly what agile practitioners are trying to teach organizations - that past experiences  are not necessarily indicative of what is the most appropriate thing to do in the current situation?

Each person has their own understanding of reality, which is why communication is needed to collaborate better. Presumption doesn't get us anywhere. How about listening, before arguing? Why is it so hard to keep those guns down until the other person made their point? 

Now, let's see how much I can trigger you ...

Agile Project

Where do we start with an agile transformation? Let's start an Agile Project!

Ohh, I hear you shouting immediately, "There's no such thing as Agile Projects! You must do Product Development!" - can you even smell how dogmatic and close-minded this is? You're not inviting a discussion, you're ending it!

When an organization is operating in project mode, you must start somewhere, and starting with a single, decoupled project is significantly easier than starting by changing the entire organization's structure, management and process landscape. Starting with a single Agile Project allows you to separate concerns.

Fixed Scope

We need to fix the scope for our Agile Project.

Your answer is clear: "We're Agile! That's Big Upfront Design, Waterfall!" Proposing to make the scope known upfront is met with arrogance and disdain. You wouldn't even bother to ask,  "what do you mean by fixed scope", because fixed scope indicates that this person just doesn't get it.

Have you ever considered that self-organization happens within a context, and clear boundaries help teams to reach excellence?

Fixed scope doesn't mean writing a Detailed Specification Document. A team's scope is already fixed when the team is supposed to build spacecraft and not washing machines. Scope can be re-negotiated when it becomes a blocker, but operating within a fixed boundary enables teams to focus ... do you remember someplace where focus was acually considered a virtue? What do you focus on, when everything goes?

Milestone Date

Investors want to know when they can see something and want a roadmap with milestone dates. They expect a Return on Invest at some point. Within a corporation, senior management acts as an investor.

I know that you're going ballistic, "We can't know what or when!" - calling the request unreasonable and insisting on a free pass for the team. 

Oddly enough, I have never seen any agilist who would invest their own money into a business unwilling to commit to results, dates or ROI - everyone buys stock from companies that announce fiscal targets and product release dates ahead of time. Where does that hypocrisy come from?

Investors pay all the bills, including the team's salary. The answer, "We do frequent Reviews" is not helpful without a specific date when it's possible to make a decision on whether to pull the plug or to proceed.

Running this decision multiple times per month would put a tremendous amount of stress on the team and promote unsustainable behaviours. Quarterly milestones give the team sufficient room to breathe and allow the business to make wise investment decisions. 

After all, the business also wants to be agile - being able to spend the money on the most important initiatives, and not just let your team locally optimize what they build!

Product Roadmap

Our stakeholders want to know our product roadmap - what they can expect in the next year or two.

A roadmap instills confidence that you know what you're doing and aren't getting tossed about by every wind.

 "That's not Agile", I hear you scream!

We have a product vision and a product backlog. Some items in the backlog are keys to business growth, others are just work. Take the keys and arrange them on a probable timeline. There is your roadmap: Was that so hard?

Being agile doesn't mean you stop caring about where you're going- it means that you're ready to change direction as needed. And guess what - nobody cares whether or how often a roadmap changes, as long as the current version makes sense and points towards valuable goals!

Progress Report

The next "Agile Antipattern" is the Progress Report. "We have Reviews, and thus, progress reports are a waste". The mere suggestion of a progress report obviously means that the individual doesn't understand agility and the organization wants to preserve status quo.

While we can simply assert that it would be best for the team to operate in a vacuum  - they don't. They operate within a context, and that context won't magically go away just because we wish it were so.

An agile progress report generates transparency where teams face systemic impediments and where they are calling for help. An agile progress report allows senior managers to pull levers that teams currently can't pull.

Senior managers are third-row stakeholders for your team who are hardly involved. Their skin isn't within the game, but they can  initiate change, and when they're responsible for dozens of teams, they can't give half an hour to each, every week - because as unthinkable as it sounds, they also do things that have nothing to do with the team's problems.

Can you respect the responsibilities senior managers have and that they are trying to use their own time as effectively as possible?

Returning to Reason

You may still disagree with the explanations I have given, but hopefully you have realized, "Yes, there's some reason behind this, and the person isn't actually so insane that they need to be lobotomized on the spot."

Speaking about our perspective opens the door to a conversation. Reasonable people are willing and able to listen to reasonable arguments. Blame and accusation aren't reasonable. Attacking the individual who speaks their mind and tries to learn closes your own door towards learning and growth and betrays the idea behind agility.

A wise person once said, "We are all where we are.
A 3-year-old lives the life of a 3-year-old, an 18-year-old that of an 18-year old, and an 80-year-old that of an 80-year old.
We can not expect the 3-year-old to live the life of an 18-year-old with the wisdom of an 80-year-old.
When we look at a 3-year-old, we should enjoy that they can live the life of a 3-year-old. They will be 18 in fifteen years, so give them time.

Can we have this kind of respect towards people who are not where we deem ourselves to be?

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:

Descriptor	Date	Scope on Due Date	Status
Due Date	December 2020	100%	Amber
Change Period	June 2019	+5%	Amber
Expected Date	March 2021 ( +3 months)	80% (-20%)	Green
Worst Case	December 2021 (+12 months)	60% (-40%)	Green
Known Risks	3 months overrun	20-40% missing	Amber

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.

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.

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

A-Player	Non-A-Player
Extreme technical aptitude	Can get by technically
Superior intellect	Highly specialized
Broad horizon	Shutter 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 Attribute	Interpretation
Strong Intrinsic Skills	Has both extremely strong skills and desire to use them to achieve something
Winner	Has both extreme ability and desire to achieve something
Great Communicator	Confident, charismatic and eloquent. Can equally convince and attentively listen.
Passionate	Identifies with a vision and is dedicated to move it forward.
Tacit Knowledge	Can manage themselves and others well.
Growth Mindset	Driven 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 Attribute	Interpretation
Skills & Knowledge	Has the hard skills and factual knowledge to excel.
Behaviour & Attitude	Positive conduct, feelings and expression towards others.
Coachable	Receptive to feedback, appreciative of input. Happy to be corrected. Efficient and effective learners.
Collegial	Operates effectively in a team. Caring. Respectful. Approachable. Asks, "How can I help?"
Committed	Committed 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.

Virtue	Pet Peeve
Technical aptitude	People who don't know, don't ask, don't learn and don't care to do things right.
Passionate, courageous, committed	Nine-Through-Five attitude.
Social, communicative, supportive	Backhanded politics, backstabbing, Fact twisting, information hiding.
Energetic, energizing, edge and executing	Energy drains, complaining, naysaying, bureaucracy.
Swift learner, coachable, open	Putdowns, humiliation, disrespect.
Superior intellect, broad horizon	Mental shutters, narrow-mindedness, prejudices.
Sense of ownership and responsibility	"Below the Line" behaviour: Shaming, blaming, justification,  denial.
High moral standards	Unethical 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.