Agile is not Chaos

There is a human tendency, albeit a bad one, to stereotype. Take for instance the words traffic and chaos. In many cases, you can imagine a chaotic crossroad in India or China, with people and cars crossing in all directions. It’s not because there aren’t traffic jams anywhere else in the World, it’s because of stereotyping. We are constantly sent links and funny videos of horrendous traffic jams in certain countries, and that is why these images come to mind. 


(Picture by under CC 2.0)


Take for example the above image. I found it by typing in the words "traffic jam" in Flickr. It was the first one that popped up. Do the same in Google or any other search engine for images. You’re bound to get a large proportion of similar images. I didn’t even have to use the word chaos.

Consider a Project Manager, could be of any type of project, but for the sake of this post, and seeing that not only myself but many of my readers are somehow involved in software development (except those that find my blog because of this post or this post), we’ll consider the project is software. John, the Project Manager has been accustomed for many years to the Waterfall Methodology. There is a clear and precise line of what a project should consist of and a diagram of how it should be performed.


One fine morning, Bill, the CEO, calls John into his office and says

John, I read this thing on CEO High Flyers’  magazine on the plane yesterday, called Agile. I want us to do it too. I’m not sure what it is, but I’m hearing good things about it. Let’s become Agile.

So John goes back to his desk and starts to look up this whole Agile thing. He reads a little bit about XP, some things on Scrum and goes back to Bill the next day.

Bill, this Agile thing is insane. It’s pretty much anyone does whatever they want and there is no control at all. Take this: they’ve got this "methodology" called Scrum, where people don’t even get tasks assigned. You believe that? And there is absolutely no clear design phase, no testing, it’s completely and utterly absurd. It’s just chaotic.

Bill wasn’t too amused. No tasks assigned? No control over who does what? Anyone can do as he or she pleases? Nonsense. He’d have none of that.

John at this point felt relieved. He’d been running projects using Waterfall for years, and albeit, yes they did run a little late, yes, sometimes the customer didn’t really get what he wanted, yes many times the actual design had to be thought out again, but there was control. As long as there was control, it was ok. Agile on the other hand just seemed chaotic.

Stereotyping is also caused by lack of understanding, by being prejudice.

Is John to blame? Not at all. John was a developer himself once and he’s been "brought up" one way. He’d constantly been shown that the only way for a project to succeed was to have a clear definition of what each person’s role in the project was, what the exact phases were and what he had to work on at any given moment. To now throw that all away and take on an approach such as SCRUM where there is no task assignment, there are no clear boundaries between requirements, design and implementation, seemed too chaotic.

But is it really chaos? Is Agile about disorganization? Is Agile about no up-front design or testing? Here is where it gets difficult. Agile is like SOA, depends who you ask, at what time, at which location and you get a different answer. All of them are similar, but each person gives his or her definition of the word.

To define Agile in one sentence, Agile is about adapting to change.  Agile is not SCRUM. Agile is not XP. Agile is not about throwing design or testing out the windows. Agile is about being flexible, about being adaptable. How you go about doing that is another matter.

Waterfall does not fit in with Agile because it is rigid. There is a clear distinction about the different phases in which a project should be executed. By stepping outside of those phases, or going back, you are essentially breaking the methodology.

SCRUM is an alternative to Waterfall that fits in with Agile methodologies. Why SCRUM works and how it improves over traditional software management methodologies has largely to do with the people behind the project. I’ve covered two essential qualities that a team should have previously in a post about multi-disciplinary and confident and reliable team members.

However, the path to adopting SCRUM or any agile methodology is not easy. It takes time and discipline. The benefit though is that the ROI is very high.

What SCRUM is and the advantages it has over Waterfall, both for the team and ultimately and more importantly for the outcome of the project is best left to a future post. What is important to understand though is that Agile is not chaos, nor is it about doing away with practices. Try and not stereotype it.

One thought on “Agile is not Chaos

  1. Candy

    Agile is not always implemented in a good way or at the point in the life of an application/product where it can be useful and not disruptive.

    Agile is chaos when it is implemented with the following being taken away:
    1. Complete requirements
    2. Use Cases (solely relying on 2-3 sentence user stories and NOTHING else)
    3. Documented architecture (which means it has not been through through thoroughly)
    4. Any kind of POC for brand new applications being started from the ground up
    5. Solution design (documented or not … it is just gone … start coding with that you have)
    6. Project Management: no milestones, no due dates, nothing
    7. Test Plans
    8. Test Cases (all adhoc testing)
    9. Scoping meetings

    I work in chaos. “Agile” was implemented in the following manner:
    1. The people doing the work do NOT manage the work or the process. It is directed from the top down (meaning Director/VP is the scrum master).
    2. Retrospectives are a joke. No one talks about the elephant in the room because management is present in the meetings. All suggestions give that would actually help fall of deaf ears. Retrospectives are a way for management to communicate the changes in the process they feel will help … but the decision was made without non-management team members input. Retrospectives are a way for the scrum master to ask leading questions to try and convince those who are doing the work to believe in the way he thinks it should be done.
    3. The management of the defect tracking process moved from the QA Manager to the Dev Manager.
    4. Scrum Master believes that one day programmers will develop code without defects and pays no attention to the increasing number of defects. Scrum Master only watches the burn down chart created off of story points from features and enhancements and does not take into consideration the number of outstanding defects.
    5. What has been developed during an iteration has NEVER been something that could have been released. Over 200 sprints on one product and the code has never been releasable.

    The result is releases have NEVER been on time (or even close) in three years. Working on a team that could succeed but have their hands tied by a so-called Agile methodology makes for increasing turn over rates, aggravated employees and generally un-happy people. And, by the way, no revenue is being generated!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s