Agile Versus Traditional Development: Exposing Some Fallacies

I have been goaded into this.

When people talk about Agile as compared to Traditional software development, it generally translates as Scrum as compared to Waterfall. Not all the time, but generally. There is the impression that Agile is tied to a particular set of to-do’s and structures and that it’s arch enemy, that which has proven inadequate and totally unrealistic, is the Waterfall a.k.a. Traditional approach.

This is a fallacy. On several levels. As Public Enemy said, don’t believe the hype.

For one, Agile is simply a school of thought. It is not Scrum any more than it is XP, or a combination of the two, or something you make up that follows a core set of principles. Like there are the 10 Commandments and various ways to interpret them, there is the Agile Manifesto and various ways to put them in place.

For an Agile method to be valid, it does not need to have a recognized acronym or have a book written about it. It does NOT need to be branded. This is my main beef with Agilists. I like Agile approaches. They are common sense, really. You do your morning routine in an Agile way. Time to brush your teeth? Cant find your toothbrush? Use your finger, or your wife’s (sorry sweetheart). It is adaptation, at the core of the Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Taking these one at a time:

Individuals and interactions over processes and tools says to ME that the people in your team are more important than the fact that you want them to Scrum. What will work for them? Stand-ups? A backlog? Both? XP? Just being in the same room talking all the time and having a terrific dynamic? These are all good, if they help deliver good software and/or software as contracted. You cannot forget about the contract, although it is not the end-all, be-all of the project. If an internal effort, there is an implied contract between development and the stakeholders. Look at the main statement again. Process is Scrum. Tools are backlogs and burndown charts. Again, the people are more important than any artifact, process, or tool.They come first, then their methods of work. This is just work, folks.

Working software over comprehensive documentation says that it is more important that you produce something that works than you can demonstrate your immediate impression of it on paper at any given point. I have heard it said that the functional requirements for software is the final codebase. The idea of comprehensive documentation is, I believe, a throwback to Big Requirements Up Front methods of analysis. But still, if the Client demands this, and they will, people come before process. If you make a Scope Document or a Class Diagram, or do some UML, this does not mean you are not Agile. In many cases, you have to – particularly where there will be integration points. You kinda want to be aware of this up front, and it might even be in everyone’s best interest to have the high level – HIGH LEVEL - architecture documented. Almost everyone who has had any experience in software knows that if you make a GANTT chart at the beginning of a project and compare it to what happened, it will almost be apples and oranges (with the difference increasing exponentially with the time, scope, and complexity involved).

Customer collaboration over contract negotiation says that the Client is part of the team, and if you are going to be Agile in some fashion, they should be aware of it and on board, ready to take part. This winds up being more important for the development team to remember (and the salespeople as well) than anything else. Instead of worrying too much about having everything signed off on before you begin (death trap), you want a dialog to be ongoing and indeed, iterative refinement (an MSF term), progressive elaboration (a *gasp* PMI term), and any other term (continuous integration, etc.) that describes the dynamic allowing for change to occur with a degree of transparency should be of foremost concern. It is also, I think, another way of saying that people come before process and that working software comes before a giant stack of documentation.

Responding to change over following a plan means that sometimes, even your Scrum team might have to break into “Traditional” mode. It might. It also means the obvious: expecting change will be more useful than  reacting to it. The former manifestation of this statement is the important one, I think, since we all know what “Agile” means and it is tiresome at this point to reiterate. I don’t think it is impossible that an Agile team would find itself forced to map against dot notated requirements at the request of a CFO at a Client organization. This has happened to me. We did it, but as people fought it, it strained the team and doubt snuck into the Client’s minds. Your Client is probably not totally hip to what you are doing, even if you describe it, and especially if their boss was not in on the conversation and is asking, “how much and when?!”. For the team to say, “this is not Agile” is not something that goes along with responding to change. It says you had a plan, and this isn’t part of it. It is hypocritial, really. It is a pain, sure, but are you going to complain about work being hard sometimes? I am sure you will find endless lakes of empathy.

This is why I take issue with companies that will teach yours to be Agile, yet show up onsite with books on Scrum and Scrum only, just touching on the Manifesto and common sense reality behind things. It isn’t about Scrum. It is about realizing that software is like anything else and does not always go according to plan, that people and relationships make projects sucessful and not contracts, that your Client has to like what you deliver and be aware of what you are doing to feel as though they have not thrown money into a time machine, and to know that there is no cookie cutter solution to *anything*, much less software.

Software Engineering and the Development process is a Complex Adaptive System, and like any other CAS, (this is an excerpt from the preceding link, which is not about software and software only, but about CAS) there are things we can look for:

· Simple Rules: Complex adaptive systems are not complicated. The emerging patterns may have a rich variety, but like a kaleidoscope the rules governing the function of the system are quite simple. A classic example is that all the water systems in the world, all the streams, rivers, lakes, oceans, waterfalls etc with their infinite beauty, power and variety are governed by the simple principle that water finds its own level.

· Iteration: Small changes in the initial conditions of the system can have significant effects after they have passed through the emergence – feedback loop a few times (often referred to as the butterfly effect). A rolling snowball for example gains on each roll much more snow than it did on the previous roll and very soon a fist sized snowball becomes a giant one.

· Self Organising: There is no hierarchy of command and control in a complex adaptive system. There is no planning or managing, but there is a constant re-organising to find the best fit with the environment. A classic example is that if one were to take any western town and add up all the food in the shops and divide by the number of people in the town there will be near enough two weeks supply of food, but there is no food plan, food manager or any other formal controlling process. The system is continually self organising through the process of emergence and feedback.

This is my issue with proselytizing Agilists. They have their way, and it is THE way, and if you challenge them they say, “well, how is your Waterfall project going?” and give you a smart ass grin.

Like I said, I really dig the Agile Manifesto. I even like Scrum and XP, when they work. Try forcing a company who has been used to producing software under a Fountain methodology or a Spiral methodology to do Scrum and take away their coffee, force them to stand up at 8AM when they are used to their routine. They will resist if they have seen any success from what they have been doing, and believe me there really are companies that produce good software under models that are not branded Agile.

As I always say, take the good, leave the bad, and approach every project with an open mind and open toolbox.

And yeah, I will also state that Agile Certification is a sham. I will certify you. Send me $500 (sale!) and a photo of you next to a nice burndown chart or sitting next to another developer and you will get a piece of paper that says you are a bona-fide Agile Professional. It will mean as much as any other Agile Certification does. You probably know people who studied for the MCSE, passed the test, and then looked for work in IT with the certification in hand but no experience. Not much difference here, except that Agile Certification classes dont even require you to take a test. If they just called it “class” or “education” I’d have no issue with it.

If you want to learn and be good at this stuff, read, talk, and use it. In other words, follow the Agile Manifesto.

Is that a “duh” or what?

Thank you,

Josh Milane

MIT Consultants, LLC

PS – I like UML. Visio is my friend. Not only that, I like COMPLIANT UML. Activity Diagrams especially, with pins and all. When there are complex business rules, it helps to see them in front of you and (imagine this?) improve the processes that are in place. I also like scoping up front, in a broad and shallow way. And I am an agile proponent. However, I am foremost a proponent of the Client.