Agile Everywhere And All The Time?

If you talk to any number of software developers you will find out that majority of them work in agile shops — places where they use some agile methodology to do their work. This brings up two questions: Is that really true that agile methodology took over the development world? And why would that happen?

Agile methods became popular because of a number of companies from Silicon Valley with huge valuations and really agile teams. But what is missing out of valuation number is the fact that those people started agile and applied it in the correct circumstances. They didn’t know how to solve the problem they were after. Sometimes they were not sure if there is a problem.

The most reasonable definition of when agile needs to be applied I heard from Eric Ries — that agile methods are most useful in the situation when either problem or solution is unknown. If you have a technology and market of which you don’t know, or you know some problem you want to solve but the solution to that problem is not clear you might want to think about using one of agile methodologies. Actually what is not clear in both cases is the market. When you look to connect solution to the market that is when you use agile. Agile methods allow you to change the direction in which you apply the majority of your most expensive efforts.

So what is agile? There are Scrum, Extreme Programming, Kan Ban just a few that come to mind. The basic idea is this: it gives more power to developers to decide how complex something is and to determine the time it will take to do the work in addition to improving feedback loop — the retrospective that gives you ideas on what is not working well and how to improve the workflow. In return it gives the employer of the developers more clear and realistic picture of the timeline of development.

Considering this information lets think — do all the companies around work on the solutions to problems they don’t know the market to? I really doubt that. Then why agile everywhere?

One thing that I hear over and over is that companies trying to become more agile. I understand that they are trying to be more efficient. Those are the companies that are trying to start using new and now very popular agile methods. Here is the problem with that: there is zero reasons to use agile if both your problem and your solutions are known to you. What you need instead is to get developers involved into process of design.

The usual Waterfal method (the name that became almost derogatory lately) goes like this: Collect data, come up with specifications, Design, Develop, Test, Release. Perfectly good approach if you know your market, know the problem and can come up with a solution. Really nothing wrong with that. Except for when you get your Marketing Department dictating your time horizons. Just because they need it “yesterday” doesn’t mean that it is possible to develop it really fast. I hear about companies where clients decide on complexity and time of a task even though they think they are being agile. They do have daily scrums and task boards but that is not very agile.

Agile mindset came form inside of development shops. It came from engineers. And if you want to piss off an engineer come up to one and say that something he is doing is “easily done, all he has to to is to add a column in a database.” Since most of the time what engineer does is not easy, because that easy thing needs to exist inside something, and that something is inside of something else with “tubes” connected to it from somewhere else. In order to be able to do anything you have to understand how that “easy thing” connects to everything else. So the main idea as I said before — let engineer decide on what is easy and what is not. That said, it will depend on which engineer you ask. If it is somebody who just came aboard and just starting to dive into “the thing” then your task might be difficult for him, but if it is somebody who has scars, left from rough edges of “the thing” all over his face, then it really might be easy. The difference is the resolution of the model of “the thing” in their heads. This is solved by pair programming and daily meetings. You can call them daily scrums.

What I see happening is that the big bosses hear about or read about the big new shiny thing called agile. They hear what it did for Toyota or HP or other company that applied it to the right problem. They decide that their company too will benefit greatly from this agile thing. They come to the VP of development and say, — “Make that happen, Joe!” Considering that Joe has a lifestyle that he likes very much — Joe goes and tells his stuff that we need to improve the methodology. If Joe knew what he was doing wrong before, he probably would have changed that, but he doesn’t see anything wrong with how the company is run, but he needs to show that he has done the improvement. So he renames everything in terms of Agile. What ends up being there is Scrumofall, Waterfall that was painted in agile turms. Your weekly meetings become Daily Stand-ups, your spec turns into Epic, and you rename your tasks into cards. The main thing that doesn’t change is that deadlines are set by management and nobody listens to developers how complex that “easy” feature actually is.

The whole thing reminds me of what KGB did in 1991. They changed all the labels. KGB became FSB, and Soviet Russia became Russia.

So coming back to the questions: Is that really true that we are all agile now? I don’t think so. What happened is the bureaucratic mimicry. As far as I can tell, not that many people understand what agile is. Some are not interested in learning, some are hostile to it, some just don’t care — they want to do their job like they used to do it, go home and forget about it. Can’t blame them. What I can do is blame the management for torturing people in the name of the next Big Thing, and at this point very fashionable Agile thing. There really isn’t anything wrong with Waterfall done right.

View All

Leave a Reply

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