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 head most often are:

  • We’re being micromanaged
  • The pressure is constantly on, these two-week delivery 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.

How do we find ourselves here? An all too common starting starting point is one of mistrust (note they above), where things are not going so well. Someone hears about agile and deliveries every two weeks. Sounds pretty good to a manager that is used to long lead times, delays, and defects. Someone is sent to two days of Scrum Master training to get the sprints started. Managers are updated everyday at the daily meeting; engineers no doubt get the idea they are micromanaged, and that they are the Scrum slaves.

I dig a little deeper, to understand “why do you feel micromanaged?” They say “We have to update the boss every morning instead of once a week.” “There is continuous pressure in these two week sprints!” “No time to document or to think”

GET UP, Time for another Sprint

Why is there so much pressure in the two week iterations? I don’t use the ‘S’ (sprint) word. It is a completely wrong metaphor. In sports, sprints don’t happen back to back. Sprinting leads to exhaustion. Sure there will be times when we sprint, but those sprints happen in the context of a marathon where you won’t finish if you do not have a sustainable pace.

Engineers tell me “The stories we are assigned are so huge there is no way to get the work done with any quality. We have to rush everything. The Product Owner says it’s priority one. We have to do what the PO says, right? No documentation; no thought; just do it! That’s Agile! Right?”

No, that’s not Agile; thought I agree that is a demoralizing way to work. As one manager told me when In the early days of coaching and training Extreme Programming “This all sounds great, but instead of being beat up once every six months now I get beat up every two weeks!” (His VP was definitely not quite on board with the realities and values of Agile, yet.) We had some more coaching to do it seems.

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. With Scrum, you change the cadence of delivery. Have you changed how you engineer your products? The practices of Extreme Programming are designed to help skilled engineers create software with a long useful life.

Managers, Scrum Master, POs does your engineering team use the technical practices of Extreme Programming to deliver high quality working software every iteration? Do you give them the resources and time to learn the skills they need to be successful in Agile?

Now it sounds like I am one of those anti-management types. I’m not. I spent a decade in management and leadership in a fortune 500 company. I know a bit about the job and can relate to the problems and pressures. The problem is not all in management.

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? If you got good at delivering meaningful valuable progress every iteration, delivering features that continue to work rather than randomly break as new changes are made, you can build a trusting relationship. Management will applaud you.

How do we do that? We’ve been trying to do that all along.

With Agile, the delivery cycle fundamentally changed. Have you changed how you develop software? As a senior developer, are you programming the same way you did that first year out of school? Do you have 10 years experience, repeating the cycle of code, test and fix that is too common in our industry? Have you read any books on iterative development, Test-Driven Development, Extreme Programming, or Design? Have you read any books on development at all? Are those crickets I am hearing? (you are reading this article, so probably you said yes).

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.

This article is based on my answer to a Quora question: In a nutshell, why do a lot of developers dislike Agile?

12 thoughts on “Why do engineers dislike Agile?

  1. One thing made me hit the brakes as it were in this article.

    “As it turns out, Agile as practiced is dominated with management in 2016.”

    I wonder if this is springboard for another series of articles. And if you have written them kindly excuse my questions.

    Why did this happen?
    Who let this happen?

    Are we who try to learn and espouse Clean Code, XP and the rest just not that as influential as we thought?

    If so why?
    If not how can we be?
    Why have we failed?

    My circle of friends (who seem to be more of a ‘Clean Code support group’) have all chewed our tails endlessly on these questions producing a lot of heat but no light….

    We don’t want to give up – but man… we’re tired.

    Thank you for writing.

  2. Dear Cyp,

    I am happy to post respectful comments from people that do not identify themselves. If you want to contribute disrespectful comments you’ll need to keep clean up the language a bit and identify yourself.

  3. If by respectful you mean agreeing with you then I am sorru I cannot do that. You seem to have deleted every comment from programmers telling you the basic concepts of Agile Manifesto are completely wrong. When you cannot identify a big enough piece of vode as your own you do not care for it. It is a very well studied phenomenon that in groups of people no on will willingly take responsability for a thing if there is no reward in it. Also pandering to children like clients is demeaning and what Agile demands. I will not answer to the demands of one that deletes any comment saying he is wrong. I am just one of the 90+% programmers that say Agile is horrible. You can ignore people like me but the number of people that choose not to accept IT jobs where Agile is practiced are increasing. Soon we will be legion and you will be forced to listen.

  4. I’m not looking for agreement. I’m looking for respectful discussions.

    You say “You seem to have deleted every comment from programmers telling you the basic concepts of Agile Manifesto are completely wrong.”

    I don’t approve replies from spammers. I don’t approve replies with the f-bomb in them. Disagreement without insult, that is what I mean by respectful.

    Virtually everyone that comments on my blog does so as themselves. Why is a secret identity needed to voice your opinion?

    I agree with your assessment that many programers think agile is horrible. So is over-cooked broccoli. It does not say anything about broccoli done well.

    We could discuss specific objections and things you have seen. For example, where do you get “Also pandering to children like clients is demeaning and what Agile demands.”? Pandering is not part of the Agile Manifesto. Sounds like a local dysfunction.

  5. I do not have a secret identity. The site demands I provide my credentials so you need just to check for them. Ciprian is my name. Not sure why it would matter but as I said I do not have a secret identity. The problem with Agile done right is that there is no right way to do Agile. And is not a local disfunction but a general one. Ok, let’s take the Agile manifesto line by line and show why is wrong:
    1. Individuals and interactions over processes and tools
    This translates into useless meetings and a lack of plan almost always. if you have a plan a blueprint of what you need to do, it can be done by anyone with the right qualifications, if not as in the case of Agile then only the original designer may understand what happens inside the cluster*** and many times not even him.
    2. Working software over comprehensive documentation
    Again the lack of documentation thing. Working software is a sign of progress only if you know from the start what the end product should be. Without documentation every time you need to make a change you need to talk to a dozen people just to make heads and tails of it.
    3. Customer collaboration over contract negotiation
    This is the worse line in the Agile Manifesto. The client cares only by end functionality and interfaces. He does not care or understand anything related to backend. And this means that almost always will ask for major changes late in the game and expect that you redo all the work in a couple of days and not ask for extra money. In the earlier models that work extremely well if a client asked for a major change late in the game it will be at a high cost of both time and money. now you are asked to make any change no matter how big on the fly without asking any more money. you are literally a slave.
    Also clients are usually like this for two reasons:
    a) they are usually non-technical or minimally technical but they think they know a lot about the software you are asked to develop
    b) they look after their own interest which is to squeeze as much work for you for the money you are paying. And Agile gives them just that: the opportunity to treat developers as slaves.
    4. Responding to change over following a plan
    This type of thinking always but always produced bad quality products, regardless of are of work. It is the reason we have blueprints for houses and every electronic device we use. And if you still believe in this I will ask you: will you live in a house build on this principle? Would you trust it to withstand a mild earthquake or a mild rain? Because I would not.

    What I found most annoying from Agilists is that when presented with all the problems of Agile they just say: “you are not doing it right” or “it is just a problem with your team” . Agilists always use the no true scottsman defence. It is never the fault of Agile but always the fault of the team.

    PS: your example was involuntary a good one because there is no brocolly cooked well. Broccoli tastes bad to most people regardless on how is cooked.

  6. Ciprian,

    I used to hate broccoli! Now it is one of my favorites. Its both good for me and I like its taste.

    I think we could discover that we agree on what not to do. What you call agile is not what I call agile. What I call agile is effective. What you call agile is not effective. What I call agile helps specific problems. What you call agile causes new problems to pile on top of the old problems. Me saying that does not mean that you are wrong about what object to. I object to the behaviors you describe too. I am against agile done wrong. I am for agile done right.

    You managed to interpret and implement each point of the manifesto wrong. Who would be a proponent of what you suggest agile is? If you want to have a dialog I am open for that. (Also, I don’t like the f-bomb on my family oriented site. So I edited it out of your last post.)

    The manifesto is vague. The authors wanted a statement of principles not a bunch of rules. I came to be part of agile through Extreme Programming. XP includes a set of engineering practices that help support incremental development.

    Many agile adoptions are doing it wrong. They are doing agile in name only. Likely that happens because they are adopting some solution without really knowing what problem they are trying to solve. If you equate agile with Scrum where all that is done is the planning and meeting cycles, I’ll agree with you that it is a mess.

    The cycle is supposed to be a continuous improvement cycle. The creators of Scrum knew about the practices of XP, but did not prescribe them. They figured a team that seriously wanted to improve would go to that next step.

    For instance, the short cycles will reveal that there is a lot of manual retest needed and it is likely that defects are escaping to the customer. Many think chasing bugs is the norm in SW development, so they don’t look to solve that problem. If they will look a little deeper they will find others that have improved that situation through automated testing. Some will discover that automated test at the feature level is nearly impossible to hit all the edges. They might find TDD and use it to further improve their code and product.

    You talk about programming as if there is a blueprint available. Usually there is not. The code is the blueprint. Take a look at this: http://www.developerdotstar.com/mag/articles/reeves_design_main.html. Have you ever known a software product that did not change? Design has to evolve with new functionality and old functionality must be preserved. Test automation, a core part of XP, is needed to keep a product young for a long and useful life.

    If there were a blueprint, where does it come from? Is that a linear process or a iterative process? Having built and contributed to many systems since the late 70s I know the process is iterative. Having designed and built a house, as well as designed and built four basements, I know the design process is iterative, even though a blue print is eventually produced. Having that blueprint did not stop requirements changing. XP is about getting good at change.

    In the 90s, I remember thinking like you: “if you have a plan a blueprint of what you need to do, it can be done by anyone with the right qualifications”. This thought was prevalent in the 1900s and 2000s. Many USA companies thought they could do design in the USA and email the designs to low cost programming countries and get good results. That did not turn out so well for many reasons. One of which is specifying SW is difficult. The number of details is immense. Some can only be discovered once you are deep into it. On top of that, once you do what the customer asked for, they are most likely going to say thanks, but what I really need is something a little different.

    Regarding bullet point 2: “Again the lack of documentation thing”. The point does not say no documentation. You interpreted it as no documentation. At the time of the Manifesto, processes and documentation were growing. I worked with a very documentation oriented company in the 2000s. Why are we writing this document? Because the process document says so. IBM/Rational were growing great lists of prescribed documents. Maybe my project does not need them. Maybe yours does. One of the companies I work with has so much documentation that they rarely get to work on the code, the part that really adds value to the user of the system.

    With the Manifest being vague, it requires thinking. What we wanted the reader to do was to make sure any documents were needed and were built with their cost and customer in mind. We also preferred, thought did not prescribe, automated documents. A requirements document can be written precisely enough to be test cases.

    You totally missed the point of point 3.
    Maybe you should go look at the Extreme programming Bill of Rights.

    And again in point 4.

    Points 3 and 4 are about change. Our thinking and experience was that requirements will change so we better get good at dealing with it. That means short feedback cycles, test automation, getting features in front of customers sooner. In short, getting good at incremental design.

    Most the companies I see getting little from agile, are unaware of the technical practices that really help evolve a system to meet client needs and keep costs down. Engineers are downtrodden. Their reputations are damaged by late delivers with many defects. What if engineers could deliver valuable working software every two weeks that stays working until you change your mind on how the system should work? They would earn better reputations and likely have a less stressful work environment.

    Maybe its time to try broccoli done right and agile done right.

  7. What I call Agile is the real world agile. The moment you try to implement it is what you obtain. We do not live in a perfect world.
    Xp and Lean have failed Agile is just an attempt to ressuect them.
    The blueprint comes from the client . The client should know what they want.
    The short cycles actually prevent from developing quality code because it does not give the developper enough time to see which solution is best and is forced to do quick and dirty implements.
    It can be seen as an iterative process but each iteration is linear and should provide sufficient time.
    The blueprint is the client requirements not the code.
    Not sure why you believe things did not turn well for them. I can give you a ton of examples of good and efficient code written by that model but not one quality software written using xp and Agile. Blizzard are against Agile and make the most efficient code in games.
    Documentation has to give guideliness . For details you can use comments and doxygem but you still need a documentation base.
    Otherwise the code becomes impossible to debug.
    Requirements may change but if there are big chages it produces instability. And short cycles make the code consisting from pieces that do not fit well with each other.
    How can you deliver a consistent piece of code in two weeks? Is unrealistic. This remainds me of the joke that a pm believes 9 women can deliver a baby in one month. You have the same way of thinking.

  8. My experiences are quite different than yours.

    I am confident that there are more bad implementations of agile/XP than good. Its hard to do it right but worth it IMO. In the 80s we denied that incremental development was doable. I wish I knew then what I know now.

    Oh, you asked me a question:

    “How can you deliver a consistent piece of code in two weeks? ”

    Have you ever heard of a walking skeleton? I would be surprised if games were not iteratively refined. I’ve worked with game companies that use the approach.

    I’ll say it again. My experiences are quite different than yours.

  9. By walking skeleton I suppose you mean the agile developpers.(joke). I know what you mean. But you still have to have a consistent base for it to work and not even then can you be sure it does. Yes I know plenty of such companies myself. They usually deliver games yearly or more often, the games have huge resource demands and are full of bugs. I am still waiting for an example of a piece of software developped with Agile that is a quality product. Also about foing it right argument if your medicine kills the pacient in 75 % of cases and works as it should just in 25% it is not a good medicine. Similar with Agile if a big majority of people using it find themselves wanting to quit programming rather than do Agile then the idea is bad. Also you said doing it right is worth it. You have not proved it or said for whom it is worth it. It may be worth it for the bussiness but not for the devs. After all drones and slaves are always a good bussiness.

  10. You said that you work for game companies that implement Agile. But are those games quality games or are the crap companies like Ubisoft, Gameloft,EA are producing yearly from some years now?

  11. I can’t say that I fully understand your comment. I’ll comment for the part that I understood.

    I worked with a very successful slot machine company. They had many critical regulatory and legal issues. Was it a crap company? No. A very high quality company, with a lot at stake for their games.

Leave a Reply

Your email address will not be published. Required fields are marked *

Be gone spammers * Time limit is exhausted. Please reload the CAPTCHA.