Asking people what Agile development is is like asking people what math is. You could get answers varying from specific operations to branches of math like algebra or calculus. The answers the Agile question vary from specific practices of certain Agile methodologies like pair programming, standing meetings, sprints, and sprint boards to ‘not waterfall.’
The real answer depends on which question you’re trying to answer. “What is Agile?” usually translates to one of the following.
- What is at the core of Agile development?
- What is the purpose of Agile development? What is it trying to solve?
- How do I implement Agile development?
Let’s dig into these questions.
What is at the core of Agile development?
The traditional core of Agile development is the Agile Manifesto. The Agile Manifesto states:
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 planThat is, while there is value in the items on
the right, we value the items on the left more.
I wrote a post over at the Business is Pleasure blog on where agile methodologies break down. The post also covers the general principles behind agile development. Since I don’t want to duplicate content, I’ll summarize here.
In general, the focus of the Agile Manifesto is basically to:
- allow people to excel according to their strengths, rather than according to the system.
- make sure software works, rather than get caught up in documenting what it should do.
- make the software usable.
- involve the end user and business people before you march too far down the wrong road
- adapt to changes—after all, we’re dealing with real life, here.
What is the purpose of Agile development? What is it trying to solve?
Most Agile proponents would answer this question by explaining the Waterfall method. However, I think the supposed anti-pattern that the Waterfall method represents distracts from the point of Agile development rather than defining it.
Agile development is really about providing a framework that allows developers to build something useful for real world users and deal with the realities of interruptions, timelines, and technical requirements that disrupt an ideal development cycle. In other words, Agile development helps developers deal with reality.
Certain practices, such as iterations, pair programming, code reviews, and retrospectives help developers and development teams adapt to change, avoid or fix bugs, and find ways to employ their strengths to build great software.
Let’s face it, if a programmer or team knew what the ideal product was when they started coding and could work uninterrupted until they were done, they would get pretty close to the ideal product. However, product development never works this smoothly. Typically, a prototype is developed, shown to a few users, taken back to the drawing board to be molded into a better prototype, over and over again until a prototype appears that is good enough to be called a ‘product.’ We then stamp a version number on it and ship it.
Agile helps us deal with these types of interruptions and reworks that are part of the reality of building software.
How do I implement Agile development?
This is where the things get crazy. Everyone seems to have a horse in this race. The Extreme Programming (XP) people think they have the ultimate way to build software. The Scrum folks think the XP folks have missed the point in some aspects. The big name agile coaches and book publishers want you to follow methodologies that benefit them.
So, what is the right way to go? A lot of people will tell you a lot of things. The one thing that many people won’t tell you is “Do what works for you.”
Agile development’s first tenet according to the Agile Manifesto is:
Individuals and interactions over processes and tools
This tells me to do what makes for the most effective interactions and individuals. This implies that you know your strengths. If you don’t, don’t worry. You’ll figure it out as you go.
I recommend to most people that they look into XP, Scrum, or some other Agile methodology they’ve heard of. Choose one or two of their practices and try them out. A good try will occur over a few months. If they don’t work after you’ve gotten used to them, find ways to modify them so you can get the benefits from them and minimize the problems you’re having. Or stop them altogether.
The Agile methodologies are a good roadmap for solving your programming process’ problems, but they are not the destination. The destination is great code. The practices behind Agile methodologies can show you the roads to get you there faster.
I’ve never met anyone who had 100% adherence to a particular methodology work for them. But I’ve seen people get close and get results.
Conclusion
Overall, the confusion about Agile development comes from one of its strengths. You define how Agile works for you. It’s similar to the principles of good living that most people get from their religion. There’s a huge amount of overlap in the religions out there, you just have to find what you believe to be truth and then do your best.
{ 5 comments }
