Developing Software Together

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!

Stop the Daily Standup Meeting


So, your Scrum Master (or product owner or some line manager) is out of office. She cancels the daily standup meeting, a.k.a “Daily Scrum”. Did that ever happen to you? Does it happen all the time? If yes, stop doing daily standup meetings. Yes, completely stop them.

You are not doing the daily standup meeting for the team. When it gets cancelled because a certain person is not there, you are doing the meeting for that person. There might be several reasons why this is happening:

  • Everyone is working on their own tasks / user stories, with very little need for coordination outside of the regular sprint meetings. This can cause a host of other problems, but you probably do not need a daily standup meeting.
  • People are not even working on the same project. Everyone on the "team" is on a different project, e.g. people in an agency working for different customers. So your team is not even a team!
  • Your team is working closely together all the time. They are co-located, and they always work together on a single user story. Everyone already knows what everybody else is doing, so you do not need a daily meeting where everyone is stating the obvious.

One could argue that in the first two situations, the “team” is not a real team. But that would miss the point: In all those situations, the daily scrum does not provide any value to the team. It is maily used for reporting the progress to a manager (or the product owner or the Scrum Master).

And for reporting the progress of a project (or multiple projects), the daily standup meeting is not very effective. You need to find a better way to track this progress.

Or, if said manager also already knows what’s going on, it is a hollow ritual that is done for no good reason. A tradition that has surpassed its usefulness. Or, if it never was useful, a cargo cult.

So, why did I say “stop doing the daily standup” instead of “find a better way to do the daily standup” then?

I want you to stop because this is a very simple, low-risk experiment you can do. You need no preparation at all, and you will get feedback immediately. And you can roll back the experiment in less than a day, if it is not working for you.

Just stop the doing the daily standup, and make everyone record what they are missing. After two or four weeks, you’ll have a very good idea which and how much value the daily standup brought to the team. Just make sure everyone is actually recording what they are missing!

By stopping completely, you get a much better idea why you need the daily standup than by trying to change it in baby steps. That’s why I told you to completely stop it: To get more data, faster.

Then, when you know what you are missing, you can design the next experiment around the question: How can we get the main value back, in a simpler, more effective, less boring way? The answer to that question will be different for every team. Maybe it even means bringing the daily standup back like it was. But some teams will find a solution that works better - for them.

You may also want to read Your Daily Scrum is Killing Your Team by J.B. Rainsberger. He also advocates stopping the daily standup when you do not get any value out of it, and he also describes situations in which you’d want to bring it back.

Read this article in Russian - Translation by Vlad Brown

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

Case Study: DevOps at Dynatrace


This article is part of the series Your Company Will Never Be Agile. It is a case study about a company that successfully introduced devops to a big team.

Some years ago, Dynatrace faced the “innovators dilemma”: They had and continue to have a software product that sells very well and grows fast, but they faced the challenges to converge multiple products into one and decided to start green-field to not just converge but actually leapfrog with new approaches such as artificial intelligence to monitoring.

You always need pain for change. Bernd Greifeneder

Their major pain was slow feedback: They had 2 major releases per year. But when they realeased the software, customers would not upgrade immediately. Some would wait for 3 months or more until they installed the new version. So it took a year or more until product management got feedback from real users. At this point, the developers were working on completely different things.

They needed faster feedback. In order to achieve this, they had to move away from software that you could install on your own server - They had to move to “Software As A Service”. And they needed a different organizational structure.

So they created a second product - a new generation that almost competed with their first product, but that was positioned towards most modern cloud technologies at first! Not every management is willing to take that risk. But it worked: Now they have 2 very successful products, which are both growing.

Kill the QA Team

Even before that, when the company was much smaller, Dynatrace faced a groth pain. They started to become more agile, and they had a QA department that did mostly test automation but also some manual testing. And they could never catch up. They had to develop test tools and to test and automate tests after a feature was done. As the company grew, this became worse.

So Bernd, together with his teams, decided that a QA department cannot work when you try to move fast. They eliminated the classic approach of QA entirely and instead created a new department “TA” - “Test Automation”, and this new department would only work on test automation tools and help teams automate their tests. They do not test or automate tests.

Developers have to automate all tests as they go. This means more responsibility for developers - They have to make sure that what they implemented works and that it also will work in the future. And it allows you to move faster, since the test automation is done when the feature is done.

After Dynatrace was bought, Bernd has also rolled out this approach to QA globally to other teams in the company, and it was always more successful than the old way.

This initiative was again triggered by pain: Slow feedback, which this time came from the slow test automation after a feature was complete.

Zero to Devops

The pain Dynatrace felt was slow feedback, again: When they started with the SaaS product, their operations team sometimes needed weeks to react. Everyone was unhappy. So the CTO decided: “We need to be able to implement a bugfix and deploy it to production in less than one hour”. DevOps at Dynatrace was born.

At this point, the company had already undergone other major changes: They had already “killed” their QA department, and they had established a culture of continuous integration and continuous testing. Also, Dynatrace had a culture that embraced failure (fail fast, fix what’s wrong, learn from it) from the start. So everyone had the feeling: “We can accept this new challenge”.

To achieve this goal, they had to move operations closer to development. Developers would do all operations for the application / the cluster themselves, and automate everything. Since QA was already integrated in development, after integrating operations they had turned the organizational structure by 90 degrees: Instead of different silos for different functions, they had cross-functional groups that were responsible for a delivery from end to end.

They still had a 24h operations team (which exists in the parent company anyway), but step by step they automated all manual operations procedures. And now, their only remaining procedure is: “If the cluster cannot heal itself, call someone from development”. So now they have fully automated QA, deployment, and application operations, and don’t need the 24h operations team anymore.

There are extreme feedback devices all over the company: The Dynatrace ufo. These are lamps that show all kinds of pipeline problems using a color code.

After the CTO started this initiative, 150 developers in two countries were immediately affected. They faced big problems at the start, and it took them some time until they honed out all of the problems, but now they are hugely successful with it. With even more developers.

Executive Support

I think one of the reasons for the success of those initiatives is that they have support on multiple levels of the hierarchy. They often start with the CTO wanting something, and he then finds supporters in product management, team leaders and developers to achieve his goals.

Bernd told me that, when you do a new project, you have to fully rely on automation from day one. This means that you’ll have very high initial costs, but they will pay for themselves at some point. But you have to get a budget for this, and he sees his task as a CTO to make sure this budget is available.

The way of the engineer: Solve all problems in a sustainable way. Bernd Greifeneder

The DevOps initiative started with Bernd putting a stake in the ground: “We need to be able to implement a bugfix and deploy it to production in less than one hour”. Most told him that this is impossible, but he found enough people from product management, development and team leaders that were willing to try. So they started with DevOps. With a team of 150 developers who were all immediately affected, half of them in another country. And even though it was “a mess” at first, after some time, it was hugely successful.

At one point, Bernd decided that the feedback from their smoke tests was too slow: “One hour for smoke tests is unacceptable. Our new target is five minutes.” And then he gave the TA department a lot of time and money to change the testing technology stack in order to achieve this. Over a year later, they were at ~8 minutes.

Key Takeaways

You need long-term goals: Top management has to put a stake into the ground from time to time (“We need to be able to implement a bugfix and deploy it to production in less than one hour”). And then make sure everyone understands this goal.

You need support on all levels of the hierarchy: In order to achieve those goals, you need some first supporters on all levels of the hierarchy and in all departments.

Allow and embrace failures: Failing is OK as long as you fail fast, correct what’s wrong and learn from your failure.

You have to turn your company structure by 90 degrees: To move fast, you cannot have the traditional departments (silos) for Development, QA, Product Management, Operations. You need cross-functional groups that are composed of all those functions.

Everyone needs a basic understanding of “Agile”: I asked Bernd if it is an advantage when managers are engineers. He said “It is an advantage, but it is clearly not required. However every manager has to understand some basic agile principles: Why we need to move fast, why we need very fast feedback, why it makes sense to invest money in solving probelms in a sustainable way”.

You really have to invest time and money: You have to solve problems in a sustainable way: You have to automate everything. You have to work on faster feedback - constantly. This takes time and money. But it will pay for it at some point.

Lead, follow, or get out of the way: Everyone has to know that this is the new way, and that it will stay like this for a long time. That they cannot wait and do nothing until the next way will be announced. That they have to follow this way when they want to stay with the company. Top management has to put a stake into the ground.

Your Company Will Never Be Agile: Budgets and Bonuses


This article is the second part of the series Your Company Will Never Be Agile. The previous part is Organizational Structure Prevents Companies from Becoming Agile.

Imagine you are a manager in a company that has annual budgets and bonus systems. A team that you are responsible for wants to work in a truly agile fashion (self-organized, re-planning every 2 weeks, working with emerging requirements, …). Do you allow them to do it? Under which conditions do you allow them to?

Bonus Systems

People with targets and jobs dependent upon meeting them will probably meet the targets – even if they have to destroy the enterprise to do it. --W. Edwards Deming

If your company has a “traditional” bonus system, you (the manager or the employee) will get a monetary bonus if you meet some targets (based on Key Performance Indicators - KPIs) in the current budgeting cycle. You probably also risk being fired if you do not meet your targets a few times in a row.

So you have to make sure to control every aspect that might influence the KPIs your targets depend upon. In a hierarchical organization, you basically have three possibilities: Either you tell your subordinates directly what to do, you choose their KPIs and targets in a way that they positively influence yours, or you do both (Be careful if you choose the third option: You might create a percieved conflict of interest for your subordinates - between their targets and what you have said).

With your bonus and your job depending on meeting some targets annually, you cannot allow your teams to work in a truly self-organized way. You cannot allow them to re-plan every 2 weeks. You cannot allow them to work with emerging requirements (which make the end-result unpredictable). You would lose some control over your targets. You cannot let them work in an agile way.

But what if you chose all the KPIs in your company based on continuous improvement? Then you, as a manager, would still get your bonus and keep your job, as long as all your subordinates improve continuously. Sounds good, but you probably still don’t want to risk it: Your subordinates might not meet their targets, and then your bonus is gone too… So, some managers will still stick to micro-management.

Annual Budgets

When your company does annual budgeting, they need to plan ahead for at least a year - probably longer. This will be an impediment to agility. It means there are things that you cannot do in the next year, because they were not accounted for in the budget.

You will prominently notice this in the last weeks of the budgeting cycle, when managers will either:

  • Throw money out of the window because there is some budget left. They will send people to trainings, buy stuff, ...
  • Push back on everything that might cost money, because the budget is almost gone. You want to hire another member for your development team? You want to buy a team license for the profiler you need? Not now, mabe in March...

The annual budget will prevent teams, departments and the whole company from reacting quickly to changes in circumstances. It will prevent the company from achieving true business agility.

Especially in combination with targets: When the bonus or the job of some of your managers depends on the company hitting the budget, they will push very hard not to implement any changes that would cause the company to miss the target. Even if those changes are necessary for the company to remain profitable in the long run.


Most of the work that companies organize as projects today should probably not be projects at all. Most of the work should be organized as a continuous stream of value creation.

Projects create problems because they have an allocated time-frame, a budget and a plan how to achieve the project’s goals (there are even more problem with projects - refer to the link above for more information). The problem here is that, within the time-frame, you are not free to change direction, otherwise the project would be challenged.

To Recap...

Annual budgets, bonus systems based on KPIs / targets and projects create incentives for some people in your organization to prevent (or delay) changes (and you cannot find the right set of KPIs to prevent this). When some people in your organization delay or prevent necessary changes, your organization is not agile.

So, in order to become truly agile, your organization has to find a way to perform well without annual budgets and bonus systems, and mostly without projects.