Improve Your Agile Practices

Enroll in the FREE 7-lesson course that will help you and your team to become more efficient and agile.

In this course, you will create a strategy for improvement. You can start improving after the first email, and you will use the strategy to stay on track months or years later.

* indicates required
Preview Email Course
Do you like what you are reading? Do you want to receive more content like this, in your inbox?
I send out articles just like this to my newsletter about once per week. Subscribe now:
* indicates required
Do you like what you are reading? Do you know people who might be interested too?

Share This Page:

Case Study: Technical Excellence at Smarter Ecommerce

This article is part of the series Your Company Will Never Be Agile. It is a case study about a company that managed to stay small and agile throughout their history.

Smarter Ecommerce has been an agile company from the get-go. Peter, who was one of their first employees in 2008, was always a strong advocat for agile software development.

They started with a "process" that was mostly scrum, but after almost 10 years of continuous improvement, it now looks a bit different. In those years, they started some remarkable practices, like daily tech talks and "Freaky Fridays" (see below).

Over the years, the developers started to "radiate" agile ideas to the rest of the company, and other departments (Product management, online marketing, ...) started do adopt agile practices and to live by agile values and ideas. Now the whole company is "agile".

Smarter Ecommerce places a strong focus on technical excellence and continuous learning. But this does not mean 100% defect-free software for them. They created a culture where failure is allowed, but where they try to detect problems very quickly and in an automated way and fix the important ones right away.

A Company Based on Values

Smarter Ecommerce changes their processes on a regular basis. They run small experiments all the time (from a few weeks to a few months), the keep what currently works and change what does not work - or does not work anymore.

They do this based on their values: They want to be a great employer, they want to enable their employees to learn and grow professionally, they want their employees to take responsibility, they want to adapt their processes for their people and they want to improve continuously to stay fast and agile.

To stay agile, you always have to adapt the process for the people you actually have. As a manager, you have to develop a lot of empathy for your teams and employees.

Christian Gorbach

The key here, to me, is empathy. You need a process that works for the people you have right now. Not for the people who wrote the Scrum Guide. Not for the people you'd like to have. This process might be different for every department, or for every team. Which is totally OK - It only has to work for this single team!

Also, they actively manage process changes: They have a change process for process changes. This means that they try to make changes and run small experiments all the time. They run experiments for up to 3-4 months, then keep what works, and change what does not. They also accept that things that worked well in the past might not work anymore - They even change well-established "best practices".

To manage process changes, they create "process change tasks", assign them to individuals and track their progress.

Agile in the Whole Company

All departments at smarter ecommerce work in an agile way. They saw what was working for the developers, learned about the underlying ideas and started to adopt some of the practices, and changed others. They were actively encouraged to do this by the management of the company.

If your product management is not willing to work in an agile fashion, you will never be agile.

Peter Rietzler

But not all teams / departments use exactly the same process. They are free to experiment and change the process in a way that best fits them.

Focus on Technical Excellence

Smarter Ecommerce have a strong focus on technical excellence. They actively encourage all their developers to learn and play with new technologies (see below).

They are very eager to automate everything. "You can only scale a company with great technical automation and using great tools". They have automated quality assurance, deployments and failure detection.

But technical excellence does not mean defect-free software for them:

We have to let go of the idea of "100% defect-free software". This is expensive and slow. We have to accept failures, but have to be able to detect them quickly so we can react and learn.

Peter Rietzler

According to Peter, fixing a problem in software can be more expensive than a manual workaround or a change of a process. When you fix a problem in software - especially one that rarely happens - You have to pay for it forever, on an ongoing basis: The fix affects your architecture, your design and the maintainability of your software (more code is harder to maintain).

The key here is to detect problems as quickly as possible, in a fully automated way. And then decide quickly: Do we fix this problem right away, should we fix it later or can we ignore it?

Continuous Improvement and Learning

The company puts a lot of effort into hirign, because they want to hire people who are eager to learn. They have accepted that the cannot hire the perfect employee, but they think that they can train them.

Everyone thinks they are willing to learn, but not everybody actually is.

Christian Gorbach

They give their employees a lot of time for learning and professional development. Almost every day (but at least three times per week) they have "Tech Talks", where one of the developers talks about a new topic for 15 minutes. The developers get time to prepare the talk (this should also be done in about 15 minutes), and everybody has to give tech talks.

With this practice, they learn about many different, emerging technologies. And all the developers learn to grasp new concepts quickly, to find the important information about a new technology in a few minutes and to talk freely (almost unprepared) about it.

They also have what they call "Freaky Fridays": Every Friday, on of the developers DJ - she is responsible for playing music. All other developers get the time to work on whatever they want. They could do a refactoring they didn't have time for, read blog posts, try out a new technology - Really, whatever they want. The only thing they should not do is work on the tasks they have in the current Sprint.

Key Takeaways

Actively encourage process changes: Have a change process for process changes. Assign process improvement tasks to individuals and track their progress.

Process changes have to come from the team: Process improvements have to come from the team. This also means that every team has to be allowed to have a different process than all the other teams.

The whole company has to be agile: Don't stop at the development teams. Make sure other departments learn and understand agile values and principles, and let them design a process around that.

Give people time to learn: At Smarter Ecommerce, people not only get time to learn / experiment, they are actively encouraged to take this time. "We sometimes have to force people to stop working on the current sprint", Peter told me with a wink.

Focus on technical excellence: Automate everything. Encourage people to become better at what they do - And then give them the time and budget to achieve this.

Organizational Structure Prevents Companies from Becoming Agile

This article is the second part of the series Your Company Will Never Be Agile. The previous part is Your Company Will Never Be Agile - Intro.

In order to be good at software development, you need an organization that's optimized for software development

Samir Talwar

Samir told me that when I first told him that I wanted to do an essay / talk about "Your Company Will Never Be Agile". His Theory: Many traditional organizations have organizational structures that are optimized for something else - Banks are optimized for banking, telecommunication companies are optimized for burrying cables in the ground and routing calls, and so on.

And I think it's even worse than that: Many companies have organizational structures that are optimized for how those businesses worked several years / decades ago! They evolved over a long, long time, and now cannot change easily anymore.

If your company does not actively work on optimizing it's organizational structure for software development, you probably don't have a structure that's optimized for software development.

Impediments to Agility

How can your organizational structure affect your agility in a negative way?

Remember: We are talking about true business agility here - The ability of a business to react quickly to changed circumstances. The benchmark here is basically the lead time for a small change in direction: How long does it take from the moment you recognize a change is necessary until you actually changed direction.

Such a "small change in direction" might or might not involve software development. But if IT is involved, we need to be able to deliver the new or changed functionality as quickly as possible, or we will slow down the whole organization.

Here's how your organizational structure can impede your agility:

Wasteful activities: People do some activity - filling out forms, writing emails to different departments, ... - that does not directly provide value for your end users. This is often caused by your organizational structure - When your departments and teams are organized in a way that is not optimal for delivering value.

Waiting time: You need someting from somebody in another team, but she is overworked: Queueing. You need answers from different people in different teams / departments, so you write emails with 10 people on CC and have to wait for the discussion to finish: Coordination. You need someone to sign a document before you can start implementing, testing or deploying: Clearance.

Hand-offs: Say you have two teams or departments who have to work together to provide some functionality: Team one does the first half, team two the second half of the work. Now you have a hand-off. This does not only cause waiting, it's even worse: You lose knowledge in the handoff. You probably need written documentation to coordinate the hand-off, but then you always risk that someone will not understand it correctly. And they won't ask, because they'll simply do what the document says.

Communication bandwidth: People in the same team will communicate more and better - Even if they are not in the same room.

Departments / Silos

Many companies I have worked with so far had at least some of the functions listed below in separate departments:

Development: They implement functionality and fix defects. Maybe they do some unit testing, or even test driven development.

Release Management: Some central department that takes care what is currently released on which production and staging system and when a team / software system can do a rollout. You probably need clearance from them to release something to production or even to staging.

Operations: They deploy your application to the production systems and solve minor issues themselves (like re-starting cluster nodes). You probably need clearance from them too to do a rollout, and you also need at least one person from them during the rollout.

Quality Assurance: They test all new functionality you implement and also automate those tests.

Here's a hypothetical, but not entirely unrealistic scenario. It's a bit exaggerated, but I've seen things like that happen at past clients.

"Release Management" keeps a schedule of all releases to production. They coordinate multiple software systems, and multiple teams work on each of those systems. They also have to provide clearance (usually takes 1-2 days) for each of those releases. This means every team can only release so often - otherwise they would be completely overworked. Our team is allowed to do one release every two months.

In order to get clearance from release management, you need a changelog and a test protocol. The testing department tests most new features within 1-2 days after they are declared "finished", then they need another 1-2 days to automate the test. When they find a defect in a new feature, it goes back to development and it takes another 2-3 days until it's developed and tested again. Before each release, they also insist on 2 days of smoke testing before providing a test protocol.

Operations wants the deployment unit at least 1 day before the release, but they only accept it once there is clearance from Release Management.

So, in order to reliably do a release, we have to have a code freeze 10 days before the release: 1 for operations, 2 for clearance, 2 for smoke testing, and 5 for "test-fix defect-test again" of the last few features.

Features from earlier iterations/sprints will be delayed even longer, since they have to wait until the next release, which is up to two months away.

IT itself: Say you have four departments - A, B, C and a centralized IT department. Does it make sense to have IT as a separate department? You probably have the IT department because someone saw "synergies" in centralizing it. But often the IT department is then organized in three groups: A, B and C, where group A serves department A, B serves B and C serves C. They don't even talk much with each other. So in this case, there are no synergies, but you have complicated the communication structure between each department and the corresponding group in IT. Sometimes it might make sense to have a separate IT department, but sometimes it would be better to move IT closer to the people who need them.

Communication Paths

In many companies, the established communication channels make it hard to get the information you need quickly when you need it. And decisions take longer, because you need people from multiple teams/departments to make a decision, but you can only communicate with them through the established channels.

"Reduce the distance between problems and problem-solvers" is one of the points of "Agile Doctrine", as coined by Jason Yip. And this distance is still huge in many companies. Not necessarily the physical distance - All persons might be in the same building. But the "organizational distance" can still be big: How easy is it to communicate with all the persons you need information from?

Team to end user: I have worked with companies in the past where developers are not allowed to talk to end users. The PO does the talking. But actually, the PO talks to business analysts. But they don't talk to end users either - they talk to the boss of the end users. That's 5 rounds of Chinese Whispers between end users and developers.

Availability of key persons: Maybe you are allowed to talk to everyone you need information from, but only at certain points in time. In the past, I worked with teams where we only could talk to key stakeholders during project initiation phases - They just wouldn't have any time for us later. So the business analysts had to document everything they said in writing, and later we hoped that we understood the documentation correctly (Remember: Documentation Lies). And the key stakeholders could not change their minds without a change request.

Team to other teams: You want to do something, but in order to achieve your goal, you have to coordinate multiple people from different teams (operations, ESB, other application teams, ...). When this happens too often, it is an indication that your team structure is not aligned with your business goals.

Strategy / Goals / Budgets: Often, companies try to hide the details of the company strategy, the tactical goals and the current financial situation from their "line workers". They do so with the best of intentions: The line workers don't necessarily need to know this, so why should they spend time on learning / processing this information? The problem is that self organization cannot work without information. Decision making and problem solving takes longer, since information about the problem first has to get to a level in the hierarchy where all necessary information and power is concentrated, but it will arrive there diluted. The solution will be watered down too when it finally reaches the people who need it. And the feedback loop is very long.

Inappropriate communication channels will slow you down considerably. And if you are slow to take and implement decisions, you cannot be truly agile.

Example: The Enterprise Service Bus

If you have an Enterprise Service Bus (or ESB), this will slow down your development. You might ask: How can an architectural detail like an ESB be a problem of the organizational structure? Here's how:

So, you have different software systems and subsystems that communicate with each other over a network. To make sure that you have well-defined communication protocols in place, and also for some flexibility, you bought a piece of software that manages and channels all messages between your software systems - an ESB.

If you have an ESB, you probably also have an ESB team. The ESB does not only route messages, it also filters them, provides auditing, can translate messages, implement fallback, and so on. You need someone to implement and maintain all this functionality. Your ESB team does this - After all, it would be a mess if all teams added functionality to the ESB themselves. Also, not every team can have an ESB expert on the team, right?

This is actually an example for both "Departments / Silos" and "Inappropriate Communication Channels". Because now you have a bottleneck: The ESB team. You need them for all changes that involve any communication between any two of your subsystems. That's potentially a lot of changes - Especially if you really want to have an Evolving Architecture.

Even worse: The functionality has to be deployed to production on the ESB before it can be deployed on the subsystems. If you have scheduled deployments, like in the example above, and the ESB team deployes every two weeks, then you have to wait for your next deployment after their next deployment after all teams were done implementing the change. This adds weeks to your lead time!

End-to-End in the Value Chain

You have to "Reduce the distance between problems and problem-solvers".

You will move fastest if you have small, cross-functional teams that can work on the whole value chain - From a problem some end user has to deployed software on the production systems.

You have to turn your company structure by 90 degrees.

Bernd Greifeneder

What would have been different departments or teams in the past - Development, QA, Operations, ... - should now be different roles in cross-functional teams. Teams that can do anything that's required to deliver value to the company, along the whole value chain.

This article is part of an on-going series. Want to get notified when I write the next article in this series? Subscribe to my newsletter (you should also see a popup below) and you'll get a mail with my next article.

Your Company Will Never Be Agile - Intro

Your company wants to become agile. Most companies want that. So they hire some consultants, do a couple of re-orgs, call their line managers Scrum Masters, and so on. And then they declare success: Development is a little bit cheaper now. But many of those companies with "successful" agile transitions did not really become agile. They don't have real business agility or sustainable development or truly self-organized teams.

The ugly truth is: If your company is not already agile, it most likely will not become agile. Not within a reasonable period of time. Sure, you can do all the little rituals that Scrum mandates. You can even fully implement all the extra stuff that SAFe wants you to do. But this does not make you agile. This is not what I am talking about.

I am talking about true business agility. And many companies are struggling hard to achieve it. They are not even moving in the right direction. Even though they "sucessfully" implemented Scrum (or any other "agile" process).

Business agility is the "ability of a business system to rapidly respond to change by adapting its initial stable configuration"

Wikipedia on "Business Agility"

The problem is: It does not matter that you successfully implemented Scrum or Kanban or SAFe in your development team. It does not matter that you do continuous integration or devops or noops. If your company is not able to move fast and change direction quickly, it is not agile.

The only thing that matters is its agility: how fast can the company change when the context changes. Agility is a property of the organization, not of a team. Improving agility usually includes using agile and lean practices at team level, but it’s not the full story.

Alexandru Bolboaca and Adrian Bolboaca

And if your company is not already agile, don't wait for it to become agile in the near future. "Agile" is not a new trend. "eXtreme Programming eXplained" was published 16 years ago, as of this writing. So, if your software company is not agile yet, it is already 16 years late.

Sure, some companies can and will change. But for many companies, this will take a long time. Longer than one would reasonably wait. In this article series, I will list some reasons why many companies cannot easily become agile, even when they adopt agile practices (Spoiler: Change is hard. Most companies have processes and policies in place that prevent certain kinds of changes.). So, if you are waiting for your company to become truly agile, try to face the truth: It might never make it.

But does it matter?

Everyone is affected by Economic Darwinism. In the long run, only those will survive who meet the customer needs and demands best.

Uwe Friedrichsen

Yes, it matters. Because, as Uwe Friedrichsen explains in his conference talks about "The Next Generation of IT", economic darwinism affects every company.

Some companies already feel the heat, for others it might take years or even decades until there will be a dangerous competitor (think: regulated industries, government institutions, ...).

At some point, a company will come that meets the customers needs better and faster than all the others. You can only hope this is your company.

Here are some reasons why companies have a hard time becoming agile:

Organization not Optimized for Software Development

In order to be good at software development, you need an organization that's optimized for software development

Samir Talwar

If your company is organized in too many departments or if it has the wrong department / team structure, you will struggle to become agile. An organizational structure that is not optimized for software development will be slow because there are too many hand-offs and deadlocks/live locks in your organization.

I am talking about a demand / supply split, for example. Or separate Development / QA / Operations departments. Those are things that impede your efforts of becoming agile.

Read More: Organizational Structure Prevents Companies from Becoming Agile

Bonus Systems / Annual Budgets

Annual Budgets are, by definition, not very agile. The same goes for fixed budgets for big projects. You lay out the basics of your companies finances for the next year - or longer. Changing direction quickly is not possible, especially late when the budget runs low. You'll often hear things like "We don't have money for that" - Even for necessary changes.

Bonus Systems are even worse - They encourage local optimization. People will work against each other to rescue their bonus. They won't do anything that could endanger their bonus - Even if this endangers the future of their company.

Coming soon: A blog post about how annual budgets and bonus systems prevent agility.

Middle Management is a Problem

Top managers of most companies want their company to be able to react quickly. People at the bottom of the hierarchy - Developers, testers, ... - often want to be agile. But many efforts are killed by middle management.

Don't get me wrong - they don't want to be the problem. They are probably not doing this on purpose. But they are concerned about their jobs and their bonuses. Especially in companies that do not have a great failure culture.

Coming soon: Why you need a great failure culture and the right middle management to become agile.

The Company is Killing Motivation

Many companies have policies and procedures in place that completely kill the motivation of all people involved - Managers, developers, testers, operations engineers, ... . People are not allowed or able to do good work because policies, beaurocracy or a lack of funding prevents them. So they don't try anymore - They become demotivated. It is extremely hard to change those policies, because they have been in place for very long.

Sometimes nobody even sees those problems anymore - People develop blind spots. When there is a problem you cannot solve for a long time, you don't see it anymore. But motivation suffers. And without motivation, change is not possible.

Coming soon: You need motivated people that work towards a shared goal to implement change.

It's Harder for Big / Old Oranizations

Why do many big / old organizations have so many management layers? Why do they have so many policies and processes in place? Why do they have all those departments, communication channels, escalation paths, and so on? Why did they become a bureaucracy?

Probably this didn't happen by accident. They became this way for a reason. Something bad happened, so they created a policy to prevent that in the future. They tried to save money by centralizing IT or Testing or Operations. And so on. For all the little details that build up the bureaucracy, there is a valid reason that can be found in the past of the company.

The problem here is that all those little details make up a system of policies and processes where it became hard for people to do their actual work. So you have to see if you can get rid of many of your processes and policies, even though they might make sense. And you have to make sure that you don't create processes and policies as a reaction one-time events - That you don't scar on the first cut.

Coming Soon: Why you need to relentlessly simplify your company, all the time.

Counter Examples / Case Studies

I also have two case studies of companies that managed to stay agile or become agile. They are here to act as counter-examples to the claim "Your company will never be agile". I interviewed their top management and tried to summarize what they are doing right - from my point of view.

Smarter Ecommerce: A small, international company that has been agile from the get-go. They are sticking to their values, but contstantly changing their process. They practice continuous learning and improvement.
Read the case study: "Technical Excellence at Smarter Ecommerce"
TBA soon: A company that has managed to become more and more agile even as they grew to become a large company with market-leading products.

What now?

So, your organization does not get all the topics mentioned above perfectly right. Is all hope lost? Will you never be agile?

I'm afraid it's not that clear-cut. Noone gets everything perfectly right - At least no company I know. But every area where you still have room for improvement is an impediment for your effort in becoming more agile. It is an impediment to delivering more value to your customers faster. It is an impediment to earning more money sooner.

Noone gets everything perfectly right - But successful organizations are constantly searching for areas where they can improve. And then they implement those improvements in a rigorous, sustainable, safe-to-fail way. Even if it means making big changes to their organizational structure or policies.

Want to get notified when I write the next article in this series? Subscribe to my newsletter (you should also see a popup below) and you'll get a mail with my next article.

Employee Training: Who's Responsibility is it?

After my last article, Intrinsic Motivation and Technical Excellence, a reader of my newsletter told me that something I wrote is apparently diametrically opposed to something Uncle Bob wrote:

[...] when a company employs someone, the company is responsible for training the person to become the employee they want!

Intrinsic Motivation and Technical Excellence

Whereas Uncle Bob wrote in The Clean Coder:

Your career is your responsibility. It is not your employer’s responsibility to make sure you are marketable. It is not your employer’s responsibility to train you, or to send you to conferences, or to buy you books. These things are your responsibility. Woe to the software developer who entrusts his career to his employer.

Robert C. Martin, The Clean Coder

Are we disagreeing here? I don't think so. And if we are, then only slightly.

Your Career is Your Responsibility

Period. You cannot expect your employer to do anything only you will profit from, just because "it is the right thing". So, if you want to learn technology X because it will look good on your resumee, don't expect your employer to give you the time to do so. Your employment is basically an exchange: Money for work done. Anything more (from both sides) is icing on the cake.

Your career is your responsibility. If your employer does not give you the time and resources to learn and become better, you should be prepared to work on them on your own.

And you should think hard about whether this is really the right employer for you. As an employee, your employer is probably your single source of money. So it's also your single source of failure for your career. When they stop giving your money for whatever reason, you need to be prepared to find someone else who gives you money. So if you get the feeling that your employer is steering you towards an uncertain future, think about your options early. Don't wait until it is too late.

You cannot expect your employer to do anything only you will profit from. But your employer should do things they will profit from:

Motivated People are Your Employer's Responsibility

Employment is basically an exchange: Money for work done. Actually most employment contracts are even: Money for time at the desk (but if the employee does not do any work, they will not stay with the company for very long). It is not your employee's responsibility to love their job. Companies cannot just complain that their employees are not intrinsically motivated and do nothing else - They have to create an environment where intrinsic motivation can grow.

You, as a company, are not responsible for making your employees more marketable. But, on the other hand, your employees are not responsible for becoming exactly the employees you need. They are not obliged to learn the skills you need in their spare time. When you hired them, this became your responsiblity.

If you, as a company, do not allow your people to refactor, if you do not allow them to learn or go to conferences, if you do not allow them to grow professionally, some of them will start thinking about whether you are really the right employer for them. This is absolutely reasonable because you are their career's single point of failure.

If you want to compete in this global market, if you want to stay relevant in the future, you need innovative, creative, motivated employees. You need people who love their job. This means that you have to give them jobs they can love. You need to give them freedom and time to grow professionally. Not because it's the right thing to do, but because your profit depends on it.

To Recap...

It is not the employer's responsiblity to take care of your career. It is not the employee's responsibility to become exactly the person the employer needs. But when the employee does not show any interest, they risk being fired. And when the employer does not allow their employees to grow professionall, people will start thinking about leaving.

When people start to think about leaving because they see the company as an impediment to their career, the best will leave first. Some years ago a friend of mine was leaving his company. He told me "This is a company where only people with mortgages stay. Everyone else leaves after a year". Believe me, you don't want to be a company like that.

When employment is only an exchange of money for work, both sides suffer. When you allow people to do good work - and to learn to do good work - they will be more motivated. And because they are more motivated, you, as a company, will profit.

Intrinsic Motivation and Technical Excellence

In my last article, I wrote about how managers are responsible for creating an environment where intrinsic motivation can happen. Here is one thing that I'm sure would help a lot of companies / teams:

Allow your people to achieve technical excellence!

"Wait, we allow that. We event want our people to be excellent!", I hear you say. All companies and managers want excellent people. But many are not willing to invest anything - money, time, process changes, ... - in enabling their people to achieve technical excellence. And some companies are even hindering their people to do excellent work.

You know, most (if not all) software developers / testers / managers I know actually want to do good work. They want to create excellent software. They want to learn how to do that. They were intrinsically motivated to create better software, but their company has killed this intrinsic motivation.

For many of them, developing software is a day job. They do not want to spend tens of hours of their free time per week on side projects or reading books or doing code katas. They do not want to learn and become better in their spare time.

Which is totally OK! Because, when a company employs someone, the company is responsible for training the person to become the employee they want!

So, if you want technical excellence, train your people and create an environment where people can learn. On the job. Create an environment where technical excellence is rewarded.

Are your team members allowed to read blog post, magazines and books during their work time? What is your training budget? What is your conference budget? Do you encourage your people to speak at conferences or user group meetings? Do you host or sponsor user group meetings?

Encourage experimenting and learning, even if you know that this means people will make mistakes. Allow team members to try new things and to work on stuff that is not on the Scrum board. Allow your developers to refactor (it saddens me how often I have already heard "we don't have time for refactoring").

And talk to your people. Tell them that you want technical excellence and that you need their help to change the company / department / team in that direction. Ask them what they need, and then listen to them.

Do those things one step at a time. See what works and do more of it. Stop what doesn't. Over time, the intrinsic motivation in your people to be good at what they do will come back.

Do you have any questions? Do you have any stories about companies that do this exceptionally well (or are quite bad at it)? Please tell me!

Intrinsic Motivation

I sometimes hear managers complain that their people are not intrinsically motivated. "We need people who love what they do, not the people we have, who are only here for the money!" Saying something like that as a manager is a bit ironic because...

You are in charge here. If your people are not intrinsically motivated, it's your fault.

Most corporate environments are not very good for allowing intrinsic motivation to happen. Some even kill intrinsic motivation very quickly. And it's often not one big annoyance that kills intrinsic motivation, it's lots of little things that add up.

Many little annoyances that give your people the feeling that "I cannot decide anything here" or "Nobody wants to hear my opinion" or "No matter what I do, things don't change here". Then it's only a matter of time until your people adopt a "work-to-rule" attitude...

As a manager, if you want intrinsic motivation, it is your job to create an environment and a culture where intrinsic motivation can happen. One where your people can decide for themselves and experiment and fail and learn and be creative. One where your people feel respected.

What happens at your workplace that kills the intrinsic motivation of the team members? What do you or your managers do to create an environment where people can be intrinsically motivated? Please tell me!

KPIs & Bonuses: It's the System

Earlier in this series, I wrote about what happens when management try to change people's behavior with KPIs, targets and bonuses. Some will try to game the system, or your KPIs will cause unwanted behavior. If they find the right set of KPIs so that cheating and unwanted behavior become impossible, they'll probably destroy motivation, morale and teamwork. But what if they find that right set of KPIs and manage to create an environment where everyone stays motivated and nobody quits?

It's the System...

The results will still be negligible. 95% of the variation of an organizations performance is caused by the system, only 5% by the people. Please read through the exercise in the linked article - Joe really has only very little influence on whether he can finish his work on time - Even if his bonus depends on it.

Also, there are always people who cannot improve their KPIs. Maybe they are juniors who cannot yet influence their outcomes in a positive way. Providing training for them would make much mure sense than giving them a bonus based on their KPIs. Or maybe they are already working as hard as they can. They would need some coaching to show them better ways of working, not KPIs to show them that they are not good enough.

Sure, in a system with bonuses based on KPIs, when a company does not get the results it wants, it does not have to pay the bonus. So they save a little money. But they also didn't get the result they wanted, which probably wasted much more money than the saved bonus brought back.

Companies must stop punishing their people when results didn't happen. They have to start to improve their systems so that results are more likely to happen. They need to create an environment that maximizes learning. And one that is failure-tolerant: Failure always has to be an option, and the company has to be able to survive any failure that could happen.

Trust is Key

Recently I read a great article about a similar topic: Why we cannot learn a damn thing from Semco, or Toyota.

Their [Toyota, Semco, ...] wonderful stories and practices will remain impossible to emulate, however – as long as we keep carrying around fundamentally screwed-up notions about other people´s human nature [e.g. that they cannot be trusted].

Niels Pfläging - @NielsPflaeging

Nobody can force people into being more agile. No company can coerce or bribe their people to be more efficient or to work together in a better way. But they can create an environment where those things can happen. And they can stop doing things that prevent them to happen.

But as a first step, companies and managers need to completely change their thinking - They'd really have to start trusting their people. And I fear that, at least for some companies I worked with in the past, this would be too big of a step...

KPIs and Bonuses: Motivation and Morale

In the last post from this series, "Bonuses and Wasted Resources: The Right Set of KPIs", I wrote about how it's really hard (or even impossible) to find a set of KPIs where cheating or wasting resources becomes impossible for the people being measured. But what if management can really find that right set of KPIs, that makes it impossible for people to cheat or waste resources? Now the performance of all employees will improve, right?

Turns out, no, you still have problems. It turns out, most (if not all) people actually want to do good work.

But when management forces them into that right set of KPIs (that tries to make cheating impossible while rewarding desirable outcomes), they make it harder for them to actually do their work. People will have to spend more and more time checking if they are within their KPIs, reducing the time being productive at work.

Also, in our industry, it is extremely important to find creative solutions for hard problems. To be creative, people need an environment where they can fail safely, and where they have lots of options (different ways) for solving the problem. The right set of KPIs takes away both: They can only fail so often before their KPIs go down. And because the KPIs were designed to inhibit certain behaviors (cheating, wasting), they also take away options for solving problems [*].

So, with the tightly woven right set of KPIs, managers make it harder for their people to be productive and to do good work. But that can be offset with the desired outcomes that the KPIs encourage, right?

Well, no. If management makes it hard for people to do good work and to be productive, job satisfaction will suffer. Some people will just tune out and only do what they are told [**]. Some will leave. And those who leave will probably be company's best talents - Those who have lots of options finding new jobs.

So, if managers constrain their people with KPIs, their best people will leave. And others will resort to just doing what they're told, killing creativity in your company / teams. I don't think this is really what they wanted.

But what if you can find the right set of KPIs, and create an environment where everybody is motivated and wants to stay with the company? Then everything will be fine, right? Well, I don't think so. In the last post from this series, I will tell you why. Stay tuned, and subscribe to my Newsletter so you don't miss it!

[*] Don't get me wrong: I do not want your people to cheat. But the KPIs that were designed to inhibit the cheating and wasting resources will almost certainly also inhibit good behavior.

[**] I have talked to several managers that complained that some of their people are lazy and that they cannot find good people. All of them had systems in place that prevented their employees from doing good work - At least to some degree.

Bonuses and Wasted Resources: The Right Set of KPIs

In an earlier article, I wrote about how competition and bonuses encourage cheating and waste. I wrote a personal example, where I eperienced that I cheated and wasted resources during a competition that didn't even matter to me. I got a lot of positive feedback, including:

Not new, but a nice example of why metrics are bad: by @dtanzer

Jens Schauder (@jensschauder)

And Jens is absolutely right: This is not new. It is actually fairly old. But time and again, I work with customers who have implemented or want to implement a system of bonuses to motivate their employees. And when I talk to them, I often get answer like:

"Well, you have a point. But you just have to find the right combination of metrics so that cheating or wasting resources is not possible anymore."

Ok... But that's incredibly hard. Let's assume Louise Elliott would have given us the following challenge: "The side where everyone has a card wins, but there must not be any wasted cards".

My cheat would still have been possible: I could still just declare we are finished, and hope that the counting occurs only when everyone really has a card. I could even cause some chaos to delay the counting. Wasting cards would also have been possible - It would be next to impossible to determine that not a single card has been wasted.

But that's an artificial example. Let's look at something real companies are doing. Louise mentioned a company that had a KPI for testers like "less then x defects found in user acceptance testing". The idea is that testers should find the defects before going to UAT, so if there are no defects in UAT, they did a good job and deserve a bonus.

What you've done now is to incentivize testers to waste time: They need to be absolutely, positively be sure that there are no defects. So they'll probably spend much more time than necessary testing features, just to be sure. Wasting time has another positive side effect: Less features make it into UAT, which makes defects less likely.

Some time ago, I talked to a manager about a similar situation. And he told me: "Of course you are right. That's why we also need a KPI that says average testing time per feature must go down every year".

Your testers could now just reject all the hard to test features very quickly. Find some minor bug in the feature or the specification, and reject it. This increases the lead time for the hard-to-test stuff, and so more easy-to-test stuff goes into every release. Less features in the UAT, and they all are easy to test: Less defects! Of course, your product still suffers. So we need another KPI...

I guess there might actually be the perfect set of KPIs - Maybe it is possible to find a combination of metrics where cheating and wasting resources becomes so hard that people won't even try anymore. But if you find that set, you are still screwed. In one of my next blog posts, I'll tell you why: Stay tuned! Subscribe to my Newsletter so you don't miss the third part of this mini-series...

P.S.: Did you know that you can ask me anything?

Competition, Bonuses, Wasted Resources and Cheating

Yesterday I was at TopConf Linz, and one of our speakers, Louise Elliott, wanted that everyone in the room gets a card with a red and a green side. She needed us to have those cards because she did some experiments where we could vote by showing either the red or the green side. But to me, what happened before the actual experiments was even more interesting...

Louise gave me and another person a deck of cards, and we should distribute them to the people in the room. I was to distribute them to the right side, the other person to the left side. And the side where everyone would have their cards first would win.

We started to distribute the cards. I started quite slowly, and I don't know if my colleague / competitor started faster. But then Louise said: "You do know that you are in a competition here, right?"

I realized that I had much more cards than I needed, so I started to hand out large decks of cards to every row. Like, 15-20 cards for a row with 8-10 people. After the last row, I shouted "done!", we counted, and everybody had a card, so we were declared winner. The other side finished at just about the same time...

We were the winners, but I wasted just about half of my "resources" (cards) by giving each row more than they needed. Also, we maybe cheated a little: I'm not sure if everyone already had a card when I shouted "done" - I guess not. But I was confident that everyone could show a card when asked to, which would, of course, be a little later than my shouting "done". So yes, we won. But only by a very little margin, and we wasted a lot of resources and cheated a little...

This reminded me of the bonus schemes I saw implemented at some of my customers. They created a system of metrics, reward and competition in which cheating and/or wasting company resources was a possibility to win. And if something is possible, somebody will do it sooner or later.

Now, you could say, we obviously hat the wrong metric. Or not enough different metrics. If Louise would have better nailed down the winning conditions, my cheat would not have been possible... In one of my next blog posts, I want to write about why this won't work either: Stay tuned! Subscribe to my Newsletter so you'll never miss one of my articles...

Update: Part two is here: Bonuses and Wasted Resources: The Right Set of KPIs. But you can, of course, still subscribe to my newsletter ;)


My name is David Tanzer and I have been working as an independent software consultant since 2006. I help my clients to develop software right and to develop the right software by providing training, coaching and consultanting for teams and individuals.

Learn more...

Subscribe to Developing Software Together RSS