Developing Software Together

What does an Effort Estimate Mean?


When we give a size-, effort- or time estimate, like “5 Story Points”, “7 ideal engineering days”, “this will be finished before End of May”, what does that actually mean? And how useful is the number?

That depends on what question we are actually answering with that number…

But We’d have to Know the Future…

Some people argue that, in order to estimate accurately, you need a time machine: Only when you know the future, you will be able to make accurate descriptions.

But that’s a classic straw man: While the statement is true, it completely misses the point. The estimates are not supposed to predict the future accurately. They are meant to be another data point for our decisions.

Other Factors

Our estimates will always be “wrong”. No matter how much time we invest.

We can never fully anticipate all the things that might go wrong during development. Or how often we will be interrupted by more urgent stuff. Or how our software architecture and design will have changed when we start. Or how third party systems will behave.

When we get better at producing high-quality software - get better at “crafting software” - some of those factors get smaller. But they never go away.

But We’d have to Specify Exactly…

This is something I hear from teams a lot. “Let’s write down what we discussed before we estimate, so that later, we will implement exactly what we estimated”. So, the team here wants a very exact, detailed specification before giving an estimate, to make sure the number is as “accurate” as possible.

That behaviour comes from our own perfectionism and from fear of the consequences of wrong estimates. Both are very real, and both probably highlight some major cultural problems in this team and company.

Specifying, in great detail, when producing an estimate will prevent them from working in a truly agile way.

But can they even estimate, without knowing the future, without knowing everything that might go wrong, and without even knowing exactly what they’ll have to do?

Some Version of That Feature

Everything we do has an expected benefit for at least some of the stakeholders. Hopefully without annoying some others.

When there is so much uncertainty - no clear, exact specification, all the other factors - an estimate cannot mean “We will deliver exactly that feature within roughly that time frame”.

But it can mean “We are pretty confident that we can deliver some software that will bring most of the expected benefit within roughly that time frame”.

When we learn to create features iteratively, we will have a first version of the feature ready long before the time is up. And then we can focus on adding more and more of the expected benefit.

Are there Other Ways?

Our estimates will always be “wrong”. No matter how much time we invest. So, is it even worth creating them?

Also, when we use the definition “some software that will bring most of the benefit”, there is always the danger that some people “misunderstand” us (sometimes even deliberately) and turn our estimates into commitments.

And the usefulness of our estimates also depends on what kind of software we produce and where we are in the life cycle of the project.

But I will write about that later. Today, I want you to review what an estimate means in your team. And discuss whether this definition is useful within your context and what you can improve. And if you are allowed to, please tell me about it!

Planning Poker - What Could Go Wrong?


A lot, it turns out. Or, maybe, not “go wrong”… But the result you get might not be the result you expected.

This article is part of the series Planning Software Development.

Suppose your team must estimate the effort of the work packages (User Stories, …) it is supposed to work on.

I know, sometimes the estimates are not needed at all and sometimes the need for estimates hints some deeper dysfunctions. Let’s put that aside for now.

Your team must or wants to estimate, and you are doing “Planning Poker”.

Planning Poker

In Planning Poker, some person (often called the Product Owner) presents a user story to the whole team. Then, every team member (developers, testers, …) secretly select a “poker card” that shows an estimate. Everyone turns their card simultaneously. Then they discuss why the numbers differ so much. After that, they play another round.

Often, those poker cards do not contain all possible numbers, but some exponential sequence (Fibonacci, modified Fibonacci, power of two), so that for larger numbers, there will be more uncertainty.

The benefits of this method are that team members do not influence each other when picking a number (some agile consultants call it a Wideband Delphi Technique for this reason). And still the numbers will be more accurate, because everyone’s opinion was heared during the discussion. And the whole team will commit to the estimates, because they created them together.

Those good things are happening… In the very best case. Which is probably not happening in your team.

Bored People

The PO discusses the user story - It’s the tenth of today. Your have small stories, as you are supposed to. The Scrum Master says “Everyone select your card. And turn your cards in 3… 2… 1… Now!”

The cards show 2, 2, 3, 3, 3, 5, 5, 5.

Someone on the team says “Let’s just make it a five and move on”. And everyone agrees “Yes, this is definitely a five!”.

Doing planning poker for lots and lots of small stories can become boring for everyone involved. People just want to get done - Assign a number - any number - to those stories, and get back to work. So, they become sloppy, like in the example above.

But, on the other hand, you should have small stories that go into development. And, as we already have established, your team must or wants to estimate the work packages they will be developing.


Commitment to an estimate is a real problem.

I have listed it as a potential benefit above: When the estimates or deadlines come from outside the team, people will happily ignore them at best, or become very sarcastic and stubborn at worst. They will only do exactly what is instructed - even if it is stupid. So, the estimates must come from the team themselves.

But commitment to an estimate creates more problems than it solves. When people are committed to an estimate - instead of to an outcome - they will push back very hard against changes that would prove their initial assumptions wrong.

Yes, this is again a hint there might be a problem with the engineering culture of this team or organization. So, the problem is not only caused by planning poker.

But I have seen this in several teams that used planning poker, so it is a real danger. And this problem is caused, in part, by the team commitment that planning poker creates.

Power Dynamics

People always follow their leader. Even if they do not know it. So, if there is a leader, that person’s opinion will dominate the estimates.

And I am not talking about somebody with formal authority. Someone who forces their opinion on others. That would be a major dysfunction in an agile team - one that you should address.

I am also not talking about team members who think they have no authority at all, who think they should submit to the group opinion, who do not dare to speak out. This is also a dysfuntion in your team. It is harder to detect and address, and you must be careful when addressing it, but you should work on it.

I am talking about the person everyone trusts. The most senior or the most talented person on the team. The person who always helps and mentors others. Who is there for everyone else.

The cards show 2, 2, 3, 3, 3, 5, 5, 5. That person showed a 5.

There is a short discussion, where everyone is heared. Then there is a new round of estimating. Suddenly, all cards show 5.

If this happens once, it is OK. If this is happening often, examine your biases.

To Recap…

Planning Poker should, in theory, eliminate a lot of biases and make estimating quick an painless. But in reality, it often fails to achieve that.

The results that you are getting are probably not what you expected. They are often not an un-biased, thoughtful estimate where everybody’s voice was heared. And the shared commitment to the estimate - and not the outcome - creates its own problems.

I do not want to advise against Planning Poker. If you must estimate, it is still the most painless method that I know of. And it is easy to get started for unexperienced teams, so it moves one obstacle - “But we need numbers!” - out of your way quickly.

But after you did it for some time, examine the problems I have outlined above. If you have them, see if you can solve them (iteratively, over multiple sprints, in retrospectives). And also examine whether you can completely do without workpackage-level estimates.

Why We do not Want to Give an Answer


This article is part of the series Planning Software Development.

When we develop software, people often will ask us questions like:

  • When will it be done?
  • How long will it take?
  • How much will it cost?
  • What will be done by 2019-02-25?
  • Can [feature set] be done by 2019-02-25?
  • What can I get for 200 000€?
  • What team size do we need to finish before 2019-02-25?

Those are related but slightly different questions. And a good answer to them would be useful to some people, often even to the people on the development team - the people who should give the answer - themselves.

And we often do not want to answer those questions. And we have reasons.

Our Answers will not be “Good”

Or at least not good enough for our own standards.

There are some inherent difficulties in estimating software development: Things about our work, things happening in our teams, that make estimating hard. And by hard I mean that our estimates will be “inaccurate”.

That is not a problem per se: All estimates (and also all forecasts, which are a type of estimate) are inaccurate. The value is still useable and useful, because it is based on the best information we have available right now.

But we do not want uncertainty. We are humans, after all. So, we do not want to produce data where we know that it is “wrong” from the start.

Our Answers May not be Useful

Sometimes, we do not want to give an estimate because we know we cannot produce it to a degree of certainty that would be useful.

We may be reluctant to answer “How long will [feature X] take?”, because there are too many factors that influence this number.

We might be tempted to answer “How much work will [feature X] be?”, because under some conditions, this question is easier to answer. But we have to know beforehand what exactly “Feature X” means. So if we answer this question far ahead of starting to work on “Feature X”, this may impede our agility, if we are not careful.

We can often produce the most meaningful answers to “How many work items can be done within the next month”, because this is a capacity-based forecast. In a stable team that already has enough historical data to run some simulations, this number will be the most accurate of the three.

But we will be most reluctant to give an answer when we think that the person asking does not need it at all.

Our Answers are often Ignored

Somebody asks “us” - the development team - a question. We answer with an estimate. When we suspect that our answer does not and cannot change the outcome of some meaningful decsisions, we feel like we have wasted our time.

“Can [Release] be done before September 22nd?” - “No, probably not.” - “But sales promised that to one important customer. Try it anyway.”

“Please estimate those 20 user stories, so we can sequence and cut scope” - “OK, here are the estimates…” - And then nothing happens…

“Based on our estimates and acutals, we are way behind schedule. We should cut scope now so we do not face crunch time in two months.” - “No, cutting scope is not an option.”

I bet every developer, tester and other development team member knows situations like those. And after hearing something like that, they probably have been thinking: “Why am I even talking to you when you ignore me anyway?”…

Our Answers Might be Used Against Us

Whenever we give an estimate (or a forecast, which really is just a special kind of estimate), we risk that somebody thinks this is a promise. At least in dysfunctional organizations.

And it does not matter how much disclaimers we add.

“In the best case scenario…”, “Our simulation said the most likely release data is…”, “Measured in perfect engineering days…”, “…but you know that a story point is really a range.”

The micro-manager will not hear those. They will come back later, screaming “But you promised…” or “Why is our velocity down this sprint?”. If this is happening in your organization, you have some major cultural problems. You are seeing Agile Anti-Patterns. And in such a dysfunctional environment, we do not want to give any answers that might be used against us.

No Answers - The Solution?

For what it’s worth, do not answer questions when you do not need the answer. But…

I am talking about not wanting to give answers today. If we could give them, they might be useful. Even if they are not usefull all the time, they may be useful in some phases of software development. At least to some people, and at least in some situations.

Even though our answers may not be “perfect” or even good enough for us, there are situations / times where we are able to give better answers than in other situations.

And when the answers are ignored or used against you, you are seeing some severe dysfunction in your organization. In such a situation, you probably should not answer those questions - But you probably are also not allowed to deny an anser. So, now might be a good idea to look for “Agile Anti-Patterns” and to start addressing them - You have bigger problems than just giving “good estimates”.

Planning Software Development


I already wrote quite a few things about estimation in this blog. But this is only a part of the picture.

Now, I want to collect some thoughts about software development. This page collects all the blog posts in this category.

Here they are:

Iteration, Detours and Feedback


Throughout my career, I tried to create some products (Books, courses, video tutorials, software). Most of them failed, especially the ones in the early years. They failed in a really un-spectacular way: People were not even interested in them.

And I think the ones that failed, failed because I wanted to finish them before showing them to anybody.

Now, I have two products that people are interested in: They are downloading them and buying them. I do not make much money from them, but still… They are infinitely more successfult then the ofther ones.

Here’s what I did differently.


Over the last 11 years, I learned a lot about how to work in a software development team. And I tried to apply my learnings to my own way of working.

So, none of what you’ll read here is really new. You may have read it before, in a book or a blog.

But it was new to me at some time. And some of the things, I had to learn the hard way.


This was the most scary thing for me to try: You must get good feedback early.

And this means showing unfinished work to others - lots of others. But what if they don’t like it? What if their feedback is devestating? Obviously, they would like it more if I showed them the finished thing… If they saw the big picture.

Well, that “obviously” is not so obvious at all. In the past, I wasted a lot of time “finishing” stuff that, then, nobody would be interested in. Or not even finishing it, because at some point, I ran out of time.

With my React / Redux course (that later led to my React / Redux Book), I did it differently. I announced on Twitter that I would be giving a webinar (and recording it) without having any material prepared. As I went on, I was completely open about my progress and what would happen next. The webinar was sold-out, and the content I created later led to a published book.

I did something similar with my other book, Quick Glance At: Agile Anti-Patterns: I presented some ideas at a conference. The audience liked them, so I wrote them down.

I gave the very first draft (which was still quite rough around the edges) to almost 200 readers (and promised that they’d get the finished book for free). I got almost 20 emails and messages with valuable, thoughtful and respectful feedback. The finished book is now much better than anything I could have created completely on my own.

But beware: Releasing something unfinished to the public or some friendly users does not mean releasing low quality. In both cases, I tried to create a small slice of the final work in almost the final quality. Otherwise, I guess I would not have gotten good feedback - People would have only complained about the quality.


With both products, I tried to work in an iterative way, creating increments along the way.

For the Agile Anti-Patterns book, I did the following iterations, seeking feedback after each of them:

  • I presented a short list of anti-patterns in my keynote at the Lean - Agile - Scrum Conference Zürich
  • I created a draft ebook with those anti-patterns
  • I changed the structure and content based on feedback I got
  • I added more anti-patterns based on the feedback
  • I created a mobile-friendly, single-column version of the PDF
  • I published the final book on Amazon and Gumroad
  • I changed the distribution platform from Gumroad to Payhip after some problems
  • I added bonus material (Large Poster, small posters, illustrations, …)

After every iteration, I had some finished product that I could show to people and ask them what they think about it. And I proceeded based on their feedback.


What I wrote above is not entirely true: It just describes the happy path, for both products. I actually took some detours and saw some dead ends with both.

With the React / Redux book, for example, I took some detours and some dead-ends. Here is how the book came to be, and unsuccessful steps in between:

  • Successful: Host a webinar and record it. Attendees and some other people got the videos for free
  • Unsuccessful: Sell the videos
  • Unsuccessful: Give the first 5 videos to subscribers of a mailing list for free
  • Successful: Write a short ebook based on the 5 first videos, give it to subscribers of a mailing list for free
  • Successful: Write a longer ebook based on the whole course, sell it on Amazon and Gumroad
  • Unsuccessful: Up-sell from free ebook to complete ebook

…and some more mostly-unsuccessful things. So, only half of the things I tried were actually successful - and some of them only moderately or only on some metrics.

And I also had a large detour with the “Agile Anti-Patterns book”: Before I presented the anti-patterns at that conference, I had already a concept and almost 5 chapters for an “Agile Excellence” book, but I did not like them. So, after the positive feedback I got at the conference, I threw the 5 chapters away and started over.

The lesson here is: Be prepared to throw stuff away. Be prepared to go backwards when you face a dead end.

This was very hard for me to learn… I spent so much time on this thing, now I’m supposed to throw it away? I had to learn to overcome the Sunk Cost Fallacy.


So, I had to learn to stick to the main agile ideas.

  • Work together with your customers to create a product
  • Seek feedback early and often
  • Start small, iterate, and have a “working product” after every iteration
  • Take small steps

All four are scary. And just like when you are developing software in team that is part of a company, all four help you reduce risk and create a better product.

And I think I could do even better. I must learn to take even smaller steps, and seek feedback even more often.

Maybe next time…

Agile - Two Steps Back


At conferences (and when talking to others), I often hear discussions about specific agile methodologies.

About the relative merits of extreme programming vs Srcum. About how SAFe is not actually agile (or why it is agile). About whether Kanban is agile or lean or both or none of the above.

About how Sprints and standup meetings and the Scrum Master role and the backlog and other things cause problems and are responsible for dysfuntions. Or about how those things work really well when you use them as intended.

And all of those discussions have some merit. Just… I think sometimes, it would be necessary to take two steps back and reconsider why we are doing this in the first place - and what we expect to happen.

Here are some of my thoughts around this topic:

What is an Estimate, Part 2


Yesterday, I got dragged into a #NoEstimates discussion on Twitter again. It was a mistake: I really dislike how those discussions usually unfold. With all their half-truths and over-simplifications and attacking straw men and the passive-aggressiveness, most turn basically into a flame war. I think we need a more nuanced discussion, if we even need that discussion at all.

But I could not stop thinking about that discussion. So, here’s another blog about Estimates and other stuff…

Estimates and #NoEstimates

In What is an Estimate, Anyway?, I wrote how I dislike the only definition of “Estimate” that I found in the context of #NoEstimates. As a quick reminder, here it is:

Estimates, in the context of #NoEstimates, are all estimates that can be (on purpose, or by accident) turned into a commitment regarding project work that is not being worked on at the moment when the estimate is made.

Vasco Duarte

And now, I think I know why I dislike it so much. It is not only circular and unhelpful. It invites people to shout No True Scotsman!. And it invites other kinds of flame wars.

An Estimate can mean many different things. It can, for example, mean: “We are pretty confident that we can implement some version of that thing in roughly the same time as some version of that other thing”. As long as everybody involved knows that this is what you mean, everything is fine. As soon as somebody with power misunderstands what the estimate means, you have a problem!

But you have that same problem with any kind of estimate or forecast. And probably even when you don’t do estimates or forecasts at all.

Say you are doing capacity-based forecasts, like some proponents of #NoEstimates would suggest (and which I think are a good idea!). And then somebody misunderstands the forecast and turns it into a commitment. Now, somebody could shout: “No true scotsman! You were not doing proper #NoEstimate, because whatever you had was turned into a commitment, and thus was an estimate!”.

What Could We Do Differently?

Let’s look at the Wikipedia defintion of an estimate again:

An Estimate [is an] approximation, which is a value that is usable for some purpose even if input data may be incomplete, uncertain, or unstable. The value is nonetheless usable because it is derived from the best information available.

-- Wikipedia: "Estimation"

With this definition, we could acknowledge that we are using estimates, whether we estimate things or not. We are also using them when we forcast or “just work on the most valuable things first”.

Then we could talk about for which purposes those estimates are usable, and for which they are not. And we could have a discussion around that.

And if some people in our organization are turning those estimates into commitments, we could talk about how this is toxic for the team and the product. How we are facing the “Feature Factory” and the “Burnout by 1000 Baby Steps” Anti-Patterns in this team. When solving the problem, we may or may not end up with doing less estimation (the activity of estimating things). But there are still estimates.

If this was interesting to you, check out my book Quick Glance At: Anti-Patterns. There, I describe situations that go can go wrong in agile teams. And I am trying to help you find the root causes and start solving those problems.

Agile Anti-Patterns


Suddenly, in a large company that has been around for a very long time, the C-Level executives realize that something must change. Smaller, younger companies are out-competing them.

“Everyone else is doing this Agile thing. So we have to become agile too. From now on, we will all do Scrum!” (Or Kanban. Or SAFe. Whatever.)

They start a huge “Agile Trainsitioning” project. They hire expensive consultants. They re-name all roles. Everyone in the company gets two days of training.

And then they declare success: “We are agile now!”

But often, things did not work out exaclty how they would have liked. Here are some “Agile Antipatterns” that I saw at previous clients (expecially big companies), after they started to introduce “Agile” into their company.

This article is based on my keynote at the “Lean, Agile, Scrum 2017” conference in Zürich. In that keynote, I also talked about root causes and possible solutions. In this article, I’ll only describe the patterns.

Agile Theater

“We are agile now!” All the teams are doing their stand-ups and retrospectives and all the other little rituals. We celebrated our success. All the managers got their bonus for finishing the transition on time and within budget.

But if you look closely… Nothing has really changed. The company, as a whole, works like it did before. The rituals are just rituals, nothing more. There are no visible benefits from working in a new way.

And the employees just play along. They know that the next re-org will happen in one or two years.

Read more about “Agile Theater”

Feature Factory

Every two weeks, the team delivers new features. Delivering is success. We are keeping the velocity up.

Nobody knows if the new features really give any benefit to the customer. And the dev team does not care. They are paid for turning user stories into production code, not for measuring if they actually do something valuable. This is someone elses’ job.

No developer or tester has ever talked to a real user. It’s more like chinese whispers: The users talk to their boss, who talks to the business analysts, who talks to the PO, who talks to the developers, who talk to the testers.

Product Backlog Bankruptcy

The product backlog is big. I mean, it’s huge.

Yes, we know, it should be a sorted list with one top priority item, one second place, one third place, … and one last place. But we really don’t care about the order of items #100 to #600. All of them are not important. Who knows if we will ever start them.

We observed, though, that we have very long lead times. And our estimates are very often wrong.

Architecture Madness

Oh my god, everything takes a long time nowadays. Three years ago, we would have implemented this feature in two days. Now we’re two weeks into the implementation, and there is no end in sight.

You want to work on that user story? Pleas wait until Jane is back from holiday. She is the only one who really knows the desing of that part of the system.

Wait, what? You changed that class? We don’t do that. Things will break.

The last time we changed the design of the software in a meaningful way? Can’t remember. Must have been years ago…

Refactoring Backlog

This one is related to the previous point. There is a backlog of things the team would like to do. Introduce Spring Data. Automate our production deployment. Improve the architecture. Move the messaging code to it’s own process.

But the product owner has to allow large refactorings. They might interfere with the sprint goal, after all. And she often does not do it. Thigs are stressful right now.

Then, suddenly, the PO allows us to work on a big refactoring. But it goes horribly wrong. Things break - Even in production.

Now we are reluctant to try again, because of the big mess we left the last time.

Burnout by 1000 Baby Steps

Management sees agile just as a way to improve efficience.

The daily scrum becomes a management report. Failing a sprint goal is a catastrophe - The team has to report to the PO when it happens.

No the team is under immense pressure all the time - In tiny, daily cycles. They burn out. In the end, one of them writes a blog post titled “Scrum: A Micro Manager’s Dream”.

OPS? What do *we* have to do with OPS?

Yes, I wrote operations here. But it could be any other department of the company. Like Testing, Product Management, HR, …

One or more teams started to implement agile software development. The rest of the company lags behind - Or maybe it never even plans to change.

Now working together with these other departments has become much harder. It does not work anymore. It impedes the agility of the teams. In the best case, something like “Water-Scrum-Fall” is happening. But it might be worse.

Read more about agile ant-patterns in my book “Quick Glance At: Agile Anti-Patterns”: Buy it now!


Did you ever experience one or more of those anti patterns in real life? What is your company doing well, where do you still have problems? Please tell me:

<a style=”font: 12px Helvetica, sans-serif; color: #999; text-decoration: none;” href=> Erstellen Sie Ihre Umfrage mit SurveyMonkey </a>

Maybe You don't Hate Agile - Maybe You Just Need Some Coaching


Some days ago I tweetet…

Why do developers hate Agile? Allan Kelly has a theory, and according to him, it mostly boils down to three reasons:

  1. Agile is now often an imposed change - The desire to become agile does not come from the developers, it is imposed on them by management.
  2. Agile without technical quality/skills makes developers lives worse.
  3. In the wrong hands, the same agile tools are very effective micro management tools.

Today I want to focus on the second and third reason. This does not mean that #1 is not interesting or problematic - quite the opposite! But I will leave this problem alone for now, because it can solve itself over time when you get #2 and #3 right.

Also, the second and third problem fit very well into another discussion I am involved in right now:

Agile Coaching and Technical Coaching

In the last few months, I had discussions with multiple people. We talked about how companies that get agile coaching also need technical coaching, because “Agile” without technical skills is meaningless (#2 of Allan’s reasons immediately reminded me of this discussion).

The discussion is, for now, mostly about how we can create awareness for agile AND technical coaching in companies and how we can work together as different types of coaches. I also wrote a blog post about it: The Missing Link in Agile Coaching.

But, let’s get back to problems #2 and #3 now…

Tools for Micro Management

The same tools that can help a team work together effectively - Like visualizing all work and problems, having regular planning meetings, sprint retrospectives, daily standup meetings, … - can also be used by managers to micro-manage a development team.

Then they do not only lose their purpose - They become dangerous. Team members will be less and less motivated. The best will quit first. Some will stay but “tune out” - They will only do what is absolutely necessary to get a pay check. They will write angry blog posts about why they hate Agile. Hiring new developers becomes more difficult, because the company will have a certain reputations.

As a company, you do not want to get into a situation like that!

I also realize that there is a bigger problem here: That this abuse of the tools is even possible. But I will not even try to solve this right now. Anyway, I would love to see more discussion about it ;)

Lack of Technical Skills

Allan’s idea here is that, without technical excellence, working in an agile way actually makes things worse for developers.

When you do Scrum, for example, you must have “potentially shippable software” at the end of every Sprint. And “potentially shippable” means that you can deploy it to production at a moment’s notice, without (much) extra work. And you should have deployable software after every commit, since every commit will be deployed to a staging environment (or even to production!).

Working in an agile way means releasing to real customers in very short intervals - We want go get real feedback, really fast. It means changing direction often, and changing requirements, because we will know more about the problem and possible solutions once we get feedback.

To achieve this, you need a very high quality, good testing practices, good - executable! - specifications, and a software architecture and software design that is easy to change. If you do not have those things, realeasing often and deploying every commit will be quite painful…

Let’s assume that (almost) everybody actually wants to do a good job. They want to get better at what they do. How can it happen that entire teams lack the technical skills they need to make agile software development work for them?

The Relationship Between the Two Problems

Many teams who lack technical skills also have the other problem - That management is using agile methodologies “against them”.

But I think they do not do it on purpose - Managers, too, want to do a good job. Sometimes, not everybody fully understands how they are supposed to use the agile tools. Sometimes there is a lack of trust: Some managers have been burned before and are now extra cautious. If your company has a KPI/bonus system, it probably incentivizes bad behaviour - your company is actively destroying value by having bonuses!

So, if management is “using the agile tools against the team”, the team probably also has no time to learn, experiment and grow. There is no conference budget. There is no training budget. The company often has processes and policies in place that prevent their teams from becoming better at what they do. They prevent their teams from doing good work!

How can Coaching / Consulting Help?

OK, I am assuming that your company actually wants to do the right thing - they want to become more agile, and they want to do Agile right. If your company - or some important managers within - do not want to do the right thing, you have a completely different problem.

So, if your company wants to do the right thing, but you have one (or both) of the problems mentioned above, you need help.

First, you need management coaching. You need someone who can show your managers how they are mis-using the agile tools as tools for micro management. Your managers probably have valid concerns and good reasons for acting the way they do. So they need someone with whom they can discuss their concerns. Someone who can show them that other ways of working can be effective too - even more effective, sometimes.

Then your team has to start improving their technical skills. They must learn to work togehter more effectivly, produce higher quality code, create evolutionary architectures, avoid defects instead of trying to find them after the fact, … And a technical coach can help them with that.

Yes, you can probably also do both on your own - Managers do not necessarily need a coach to change. And developers, testers and everyone else on the team do not necessarily need a coach to become better at what they are doing.

But hiring external coaches to help you can have several benefits (and internal coaches too, to a lesser extent):

  • They create a time and place where the learning can happen. When the external coach is present, people will find the time to learn/discuss/work with her. They would not dare to waste the money the company pays for a coach by not working with her.
  • People actually listen to them. For reasons I don't fully understand, some people listen when a highly paid consultant tells them something, but won't listen when their employees tell them exactly the same thing (But if you are in this situation, you probably have a problem you should try to solve).
  • They bring in a fresh perspective. Existing teams often develop a certain blindness for problems they think they cannot solve. And they also suffer "inattentional blindness" - they are just too busy with other things to see certain problems. An external coach can remind them of all the things they don't see (or do not see anymore).

Sometimes you will find a coach who can help you with both - Management coaching and technical coaching. But most coaches will either be better at agile coaching or at technical coaching.

This is the reason why I, together with some other people, started the discussion about agile coaching and technical coaching. We want to bring agile coaches and technical coaches together, so that we can provide more value togehter. And we want to raise awareness that agile coaches, together with technical coaches, can help you solve some of your problems.

What Now?

Ask yourself, honestly, “Do we have those problems? To what extent do we have them?” And if yes, talk to people. Discuss possible solutions. Think about very small, safe to fail experiments that might improve your situation.

If you think an external coach or trainer could help you with some of your problems, tell your colleagues and managers. But do not assume that they will be excited quickly. It might take a long time until you can convince everyone involved that getting external help might be a good idea.

Do you want to join our discussion about raising awareness for the need of agile coaching together with technical coaching? Do you have any questions about this discussion? Please drop me an email, I would love to hear your input and answer your questions…

Read more about things that can go wrong in an agile environment in my book “Quick Glance At: Agile Anti-Patterns”: Buy it now!

The Missing Link in Agile Coaching


I was fascinated with agile software development from the moment I first heard about it in an eXtreme Programming course at University. And when I was a developer in a Scrum team for the first time, I decided that I have to become involved in this “agile” thing / community.

Because of that moment almost 10 years ago, I started to learn more about Scrum, Kanban, Software Craftsmanship and other “agile” stuff. Because of that moment, I write on this blog, give conference talks and try to help people become better at developing software.

Agile Coaching - Not for me?

And then it finally paid off: A company asked me to be a Scrum Master / Agile Coach for two of their development teams.

I was there for just about 1.5 years, and I learned so much! I was not only their Scrum master, I was also responsible for coordinating with external departments (mainly Testing and Operations).

We transformed the approach of the team from Scrum towards Kanban. I worked with their product owners, business analysts and developers to introduce specification by example / agile acceptance testing. And some more…

It was a great experience, but after some time I started to miss writing software. I started to miss discussing about software architecture and creating software designs together with my teams. I realized that doing “only” agile coaching was not the right thing for me…

Player Coach?

The next few clients hired me to do different things for them. They hired me as a software architect, as a developer or as a specialist to introduce a new technology.

And while I really enjoy those things, when I come to a new client, I also recognize things that could be improved - Things about how people work together, how the client handles requirements and defects, and so on. “Process” stuff.

So, with those clients, I tried to help them improve their process while having a different role on the team - By discussing with team members and managers, and by telling them stories about what we did in other teams I worked with.

Sometimes this worked better - some people would listen to me - and sometimes it did not work so well. But I did not think about it too hard.

Agile Coaching and Technical Coaching

I did not think about it too hard until Adrian Bolboaca tweeted:

And I thought: Yes, that’s it. We have to convince companies they have to do both: Getting better at working together (e.g. by getting agile coaching) and getting better at what they are actually doing (e.g. by getting training or technical coaching).

That tweet also started a series of events, leading to, among other things, this blog post. Gitte Klitgaard tweeted:

And then Gitte, Markus Tacker and I had a video call where we discussed what we could do to improve the situation. Basically, we want to work together as agile coaches and technical coaches to provide a better experience for clients.

Going Forward

First, we want to raise awareness for the topic. We want to start planting some seeds, so maybe more companies will realize that they can benefit from agile coaching and from technical coaching.

  • Each of us will write a blog post, you are currently reading my take on the situation.
  • We will speak at conferences about this topic. I will give a talk called “Technical Excellence” at several conferences in autumn. And we want to create conference talks together.
  • We will talk about this topic to other people in person. </ul> We think that a major difficulty here is that many companies - or, actually, people in those companies - think they do not need any outside help.
    • The current way we do things works, so why change anything? Well, the current way of doing things is often merely sufficient. And it might stop being sufficient faster than you think...
    • Developers and testers love to try / learn things on their own. Some love to tinker and learn, and this can work very well. But it often is less efficient than getting some help. And often teams do not see certain improvement opportunities because they have developed some blind spots over the years.
    • Management sometimes does not want to admit that something needs improving, because the way things are now happened on their watch. They think admitting they need coaching means admitting that they did something wrong. So they prefer continuing the old way, without getting outside help. </ul> We also want to expand our network, so we can bring people looking for coaches and people who provide coaching together. And we need your input here. What do you think about agile coaching and technical coaching? Where could you need some help? Where could you help others? Let’s have a short video call or an email conversation: Contact me! Read more about things that can go wrong in an agile environment and why you might need a coach in my book "Quick Glance At: Agile Anti-Patterns": Buy it now!