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:
- 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.
- Agile without technical quality/skills makes developers lives worse.
- 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.
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!