Again, conversations give me a zillion things to write about. The recent conversation that has cropped up again is my various viewpoints of the Agile Manifesto. Not all the processes that came after the manifesto was written, but just the core manifesto itself. Just for context, here is the manifesto in all the glory.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Several of the key signatories at the time went on to write some of the core books that really gave Agile Software Development traction. If you check out the Agile Manifesto Site and do a search for any of those people, you will find a treasure trove of software development information.
My 2 Cents
First off, I agree with a few people out there. Agile is not Scrum for instance. Do NOT get these things confused when checking out Agile, or pushing forward with Scrum. As David Starr points out in his blog entry,
"About 35 minutes into this discussion, I realized I hadn't heard a question or comment that wasn't related to Scrum. I asked the room, How many people are on an agile team that is NOT using Scrum?
5 hands. Seriously, out of about 150 people of so. 5 hands."
So know, as this is one of my biggest pet peves these days, that Scrum is not Agile. Another quote David writes,
"I assure you, dear reader, 2 week time boxes does not an agile team make."
This is the exact problem. Take a look at the actual manifesto above. First ideal, "Individuals and interactions over processes and tools". There are a couple of meanings in this ideal, just as there are in the other written ideals. But this one has a lot of contention with a set practice such as Scrum. There are other formulas, namely XP (eXtreme) and Kanban are two that come to mind often. But none of these are Agile, but instead a process based on the ideals of Agile.
Some of you may be thinking, "that's the same thing". Well, no, it is not. This type of differentiation is vitally important. Agile is a set of ideals. Processes are nice, but they can change, they may work for some and not others. The Agile Manifesto covers the ideals behind what is intended, that intention being to learn and find new ways to build better software.
Ideals, not processes. Definition versus implementation. Class versus object. The ideals are of utmost importance, the processes are secondary, the first ideal is what really lays this out for me "Individuals and interactions over processes and tools". Yes, we need tools but we need the individuals and their interactions more.
For those coming into a development team, I hope you take this to mind. It is of utmost importance that this differentiation is known and fought for. The second the process becomes more important than the individuals and interactions, the team will effectively lose the advantages of Agile Ideals.
This is just one of my first thoughts on the topic of Agile. I will be writing more in the near future about each of the ideals. I will make a point to outline more of my thoughts, my opinions, and experience with the ideals of Agile and the various processes that are out there. Maybe, I may stumble upon something new with the help of my readers? It would be a grand overture to the ideals I hold.
Great post, I like the distinction you’re making. The "Agile" buzzword gets tossed around quite haphazardly. Saying "we practice Agile development" has become almost meaningless without offering further clarification.
The process is the holy grale of big companies. You must not work in order to not disrupt the process. The process is fragile and does not stand the many people using it. The more people use the process, the more it gets de-stabilized and finally gets broken. People are harmful to processes. They’ll change processes – that’s a natural habit. The most clever solution is to isolate individual processes for single persons and small groups and let them report to a higher instance only the most prevalent issues – in weekly turns. This allows individual adjustments of small processes and saves the big overhead of big-process-synchronization.
XP is intended to give the individual and the group the freedom to do exactly that: refator your own process if needed.
HTH – Matthias
Never really gotten a good handle on Agile. Yet, I really like the statement "Individuals and interactions over processes and tools". Personally I think that is the key to any successful endeavor whether personal or professional. Thanks for writing this post.
Marty & Matheny – Absolutely, very good points to the both of you! 🙂 Thanks for commenting.
@lindit – Thanks for reading & suggesting!