Agile Says What?
November 4th, 2009
The other night I spend forty-five minutes on the phone with a friend talking about what agile is. He hadn't been exposed to the ideas behind agile. When I started talking I don't think I really hit on what agile IS. I talked about practices and the way my team works. He had many of those methods in his experiences but not all of them, and not really in what I would consider agile. After I got off the phone I noticed that I only talked about practices and not about principles. So I thought to myself, "What IS agile?"
This is a hard question for me to answer. Every time I start to think about it I go back to the practices that I use in order to achieve what I consider agile. That isn't right. Agile isn't a set of practices, is it? No it can't be. The Agile Manifesto specifically states "Individuals and interactions over processes and tools." If it isn't about processes what is it?
The more I thought the more agile seemed to be nothing more than agility. Every methodology that I talked about had to do with the ability to change direction at the drop of a hat. Agile is about reaction. Not just any reaction, but ones that cause positive change and outcomes. Agile is about feedback and learning. After all this...Am I agile?
I am agile. I am constantly learning from every source at my disposal. I go looking for ways to improve myself and my product. I adapt to change. I am always trying to push the envelope further. Yet, I can't help but feel that I missing something? What am I missing?
The one thing that I didn't mention above. Is it in there somewhere? Delivering a useable project at any point in development. That is it. That is what I'm missing. This has got to be the hardest part of agile. No matter what we do it always seems that we are one step away from delivering that product at the drop of a hat. If the customer says, "I want to deploy now." I should be able to happily say, "Already done." Not that I don't have software that I can deploy all the time, but what really makes a project "useable?" Can I deliver something that can be let out into the world every week?
That is my goal. From this moment forward I'm going to try and guide my project and my customer so that we are always moving forward with usable software. Not a half done feature at the end of an iteration. I'm going to try and guide the story selection for my projects so that at the end of each iteration we have something to "useable" to deliver. Is it possible?
What is useable? Is this really possible, or is it an ideal that we strive to achieve knowing that it doesn't quite work that way. Once we have the app in production it is easy to keep that way, but is continuous deployment really possible from day zero? Can each commit still be tiny yet completely deployable? What are your thoughts? Also did I miss anything that defines agile, but isn't a practice/methodology?
4 Responses to “Agile Says What?”
Sorry, comments are closed for this article.
November 5th, 2009 at 09:25 PM
Great post, Amos. I agree with a lot of what you're saying. Agile is about lots of those things. It's also about the business and development sides learning to speak each others' language, learning to value each other, and respect one another's points of view.
But what you missed from about is the humanistic side of agile. That's what separates agile from the rest of the iterative and incremental processes. Its how valuing the people involved with the act of creating something are an integral part of that thing. Without them, you'd have nothing, and with them, at their very best, working together to for a sum greater than their parts, you've finally reached your goal.
Does that make sense?
-- bab
November 5th, 2009 at 10:13 PM
Amos,
I agree with both of you guys. Coming from my last project I really saw how much of "agile" ends up being people issues and isn't limited to software development.
A lot of it really comes down to caring. Caring about your craft enough to always be learning. Caring about your client enough to embrace the change that drives their business. etc.
Nice post. I posted more of my thoughts over on my blog.
November 5th, 2009 at 11:26 PM
The thing that scares me about agile is that it is yet another false notion that a change in methodology is all that is standing between a team and shipping. In my limited experience, I've seen teams that were using some agile practices unwittingly because it was the only way to ship. I'm not against agile, far from it. But I have yet to see a team that I thought could be fixed with agile. Most of the bad teams I've seen have bad people. There is a silver bullet to software development. Hire people that don't suck, and fire those that do. The latter is much easier, yet I rarely see it done.
November 6th, 2009 at 09:23 AM
Brian, I agree with everything you say. I was trying to get at the point that even though I believe in agile when I try to explain it I always end up talking about practices/methodologies and not about the thoughts that truly make up agile.
Heath, in your very first sentence you mention a change in methodologies. I agree with your sentiments, but agile is more than that. It is a thought process. I know at the end of my post I ended up talking about continuous deployment and that is a method. I'm sorry I got sidetracked and confused people as to the real point of my post.