Uncharted Waters

Sep 20 2016   10:35AM GMT

What’s Wrong With Agile?

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


It looks like agile can not stand on its own anymore. There are scaling frameworks — SaFE, LeSS, DaD, SCARE — that are all designed to organize small teams in a way that people detached from the work (ahem, managers and directors) can understand. There are the post-agile phenomena like continuous delivery and the Grows method. And then there are the hoards of trainers and consultants each trying to teach technical teams their special brand of agile process.

So, what’s wrong with agile? In an Agile2016 interview, Ron Jeffries and Chet Hendrickson describe problems across the board — planning, implementation, and process. I have mostly seen people stumble over planning and process.

Most companies I have worked with were never quite able to figure out what one shippable increment of software looked like. A typical planning session might start with the technical team gathering in a room to talk about the features we were supposed to start working on tomorrow. Our product manager arranged the features in a list starting with what she thought was most important. The developers would take a look at the list and go through circles of “We can’t start the report till the UI is there, we can’t start the UI till the API is there, we can’t start the API till….”. Eventually, the product manager would get tired of listening, and the developers would get tired of talking in circles. Each developer was assigned a feature and was told to break that feature down into tasks to put into a velocity tracking system before they started working.

At the end of a release inevitably we would have a couple of features done, a couple of features that were mostly done but still working through cycles of bug discovery and fixing, and maybe one feature that was not started at all and would get pushed into the next sprint. There is a lot of dysfunction embedded in that story, but the one that stuck out most to me is the inability to see past, and break apart dependencies. In my experience, that is what leads companies into this view that every sprint is a compressed waterfall.

Rather than building a feature, then releasing, then building another feature, and so on, the average company doing agile has a planning week, a development week, and a testing and bug fixing week. They took what was happening in 3 or 6 months, cut scope, and started doing it in two or three weeks.

Every time I would ask about breaking up features into tasks in a more effective way, managers would say we didn’t have the time to invest in that right now, or the developers would say it wasn’t possible with the set of features we were supposed to develop this time around.

In the video above, Ron said “if you can’t eat at all, you can’t eat well”. Chet mentions people signing up for the Indy 500 when they can’t even parallel park a car yet. That seems to be what most companies I have worked with are doing with agile. We were taking an idea based on shipping software faster, misunderstanding how to do that, and then trying to scale it up so that hundreds of developers were shipping every couple of weeks. In the end we were doing bad work quickly.

If you’re wondering what’s wrong with agile, take a look at the most basic concepts — what is a shippable increment, where are the dependencies, can individual features be delivered to customers. Companies that can’t answer those questions clearly probably need to work on that instead of scaling things up.

9  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • oracle5
    My experience with doing Agile (which started with Extreme Programming back in the 90's) has always has been a management problem. If managers and supervisors are removed, it will work. But as long as they continue to stick their noses into the self-managed teams, it will fail. A group of engineers with a good systems engineer can very easily break down what you call above the dependencies and figure out how and when to do things. As soon as their supervisor gets involved it all falls apart. If you tell the team that it is up to them and actually let them doing it, the team will figure it out. But those managers running in fear of losing their job will mess everything up every time. The only time where I saw Agile succeed is when the manager took a step back and let the team do it, he knew his job was to remove obstacles, and he did it very well; he also bought dinner when we had to stay late.
    30 pointsBadges:
  • BradleyRoss
    Myers-Briggs has a set of personality traits that includes T (thinking - Think out the problem before you come up with a rational logical explanation - Dilbert the engineer) versus F (feeling - It must be right because I have a good feeling about it - pointy haired boss in Dilbert). If you look at the Agile documentation, it assumes that you will use your intelligence to come up with a good conclusion. Unfortunately, it seems that the manager is a strong F because he had better "emotional intelligence", which can also be defined as the ability to be a better brown-nose. This type of manager doesn't feel that it is necessary to think logically because he knows he's right. He will also make sure that the team only contains people who will agree with him and make him look good.
    60 pointsBadges:
  • ianfromoz

    At the heart of Agile is the understanding that not all requirements are known at the beginning of the project. The problem is that Agile is often used as an excuse for a lack of requirement collection and planning. I have had programmer state that Agile doesn't need planning and project management. Without such things Agile is very successful. Such statement rely on the fact that without defined goals anything can be considered success.

    It is however possible to use Agile programming methods inside a more traditional project management framework, such as PRINCE2. This gives the necessary project controls, while allowing for learning through the development process.

    20 pointsBadges:
  • BRRamesh
    I feel the core value to make Agile succeed is Cultural change and understanding behind all the practices and ceremonies. Many times the rules are being followed without worrying about what the intention is. I agree that the team needs to get more and more self-organized and free from external influence but we cannot forget business realities. Constant education is required at all levels of the organization to make Agile work and for this the Coaches' role is very crucial.
    60 pointsBadges:
  • Satyabvv
    I Agree! Basically, there are few adoption issues that making the Agile Practices fail and not getting the advantages being provided by Various Agile methodologies. In my experience few factors that failing the process are: 1) Educational issue - not understanding the principles of Agile to the core 2) Lacking of learning from past SPRINTs (Retrospection); 3) Cultural Changes - we still carry the Waterfall culture - not communicating frequently with all the stake holders....
    5 pointsBadges:
  • oracle5

    BradleyRoss - absolutely, I think you nailed it, I had forgotten all about Myers-Briggs test. After I left the group with the last intolerable manager, he was completed the team only with people that agree with him (being right). I got a call yesterday that the most current "release" was at jeopardy because of show stoppers 2 days before the release to the customer was scheduled. He is blaming the team...

    BRRamesh - YES!!!

    30 pointsBadges:
  • Justin Rohrman

    My experience is similar. There really isn't a place for a command and control type manager in small agile teams. A large part of the philosophy is that teams are capable of self-direction. 
    2,130 pointsBadges:
  • Justin Rohrman

    I'm not sure I completely agree that people with an F on the myers briggs scale are inclined to do that. That particular manager liked to steam roll any ideas that weren't his. 
    2,130 pointsBadges:
  • Kevin Beaver
    Based on my research in the field of psychology and how it impacts human behavior in and around IT and security, managers who are controlling and downright mean are simply insecure on the inside. Their fears of failure (and being judged poorly) and their desires for gain (to keep everything within their realm of control) can be distilled down to low self-esteem. It's the lowest-common denominator that determines most human behaviors in most situations.

    Those whose are emotionally intelligent in IT and security are the ones at the top of the field who are the most well-respected, earn the most money, and are going places. People who can communicate well, read other people well, and adjust their style based on the current situation are few and far between hence many of the challenges we have in our field, especially as it relates to non-techies "getting" what we do and staying our side. As I wrote here, you can never, ever underestimate the power of relationships in IT and information security.
    27,505 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: