Why do Engineers Dislike Agile?

Being one of the people that participated in the creation of the Agile Manifesto, I find myself very disappointed by the reaction of engineers to the question “Are you practicing Agile?” Their shoulders drop. They start to slowly shake their heads. They mumble; they grumble. They tell me agile is horrible. I ask why. Reasons I hear most often are:

We’re being micromanaged
The pressure is constantly on, these two-week deliveries are too short
All they care about is the date
We only have time for cr**py code, we can’t do it right!

None of those management behaviors are part of Agile (read the Agile Manifesto and its related principles for yourself). Unfortunately, the dysfunction the authors of the Agile Manifesto were rebelling against are alive and well today in most places that claim to be Agile.

Too many supposedly Agile shops are missing a lot. They are not even doing plain old Scrum. If they were, programmers would be better off, for example by:

Self-organizing teams manage themselves
Choosing your work lets you follow your interest (sometime you have to take less desirable work)
Committing to how much can be done in an iteration
Updating each other in the stand up. (It’s not a manager update, though they participate.)
Talking responsibility for design and other technical decisions (being professionals)
Facilitate continuous improvement by doing meaningful retrospectives (being honest with yourself)

The motions of Scrum can help, but they are not enough.

Engineers, programmers, developers! We need to build trust. When we ask for three months to deliver, what happens after 2.5 months? We give the bad news that we’ll need an extra month. Bad news late is the worst kind of bad news. Your trust takes a hit. Then it happens again as you near the new deadline. Your reputation is weakened further. It looks like you are really busy now! You claim to be done and then the bugs start rolling in. You fix the bugs and unknowingly break previously working features your customer relies on. Your trust and reputation is in the trash.

Can we get out of this mess?

With Agile, the cadence of delivery is changed, so must your practices change. Kent Beck told me long ago (paraphrasing): “You’ll never be able to figure it all out up-front. You’ll never be able to stop changes even with a signed requirements document and contract defined penalties. Things will change. That’s the world. If you can’t beat ’em, join ’em. Get good at dealing with change.”

Agile 2016

As it turns out, Agile as practiced is dominated with management in 2016. Most the people that were involved with the Agile Manifesto were programmers, doing what they could to make the world better for programmers and the people that need programs.

Programmers, you have a professional responsibility to improve how you work. We (programmers) better get our act together; we’re just a few more software caused problems away from having the lawyers and government in our business. We better learn to be professional, or some lawyer or government bureaucrat will tell us what professional is. Agile might not be the whole answer, but it does advance the state of the art. It introduces the two week cycle and we can and should use that cycle for continuous improvement. Serious technical improvement, not lip service.

Managers, Scrum masters, and POs do you encourage your team to learn the technical practices of Agile? Do you even know what they are and why they are important? Here are two key areas you cannot afford to ignore if you want your team be more successful and make your customers happier:

These are only a start. But they are foundational.

Agile 2017?

That is up to you.

About the Author: James Grenning trains, coaches and consults worldwide. James’ mission is to bring modern technical and management practices to to product development teams, especially embedded systems development team. He is the author of Test-Driven Development for Embedded C. He is a co-author of CppUTest, a popular unit test harness for embedded C and C++. He invented Planning Poker, an estimating technique used around the world, and participated in the creation of the Manifesto for Agile Software Development.

Wingman Software – http://wingman-sw.com.
James W Grenning – Author of TDD for Embedded C – wingman-sw.com/tddec
wingman-sw.com/blog
twitter.com/jwgrenning
facebook.com/wingman.sw