My friends who are not programmers or IT people ask me what’s up, what’s exciting in my mind & my life, and I don’t know what to say! “You wouldn’t understand” isn’t very appealing… so here is my attempt to explain why I’m madly, deeply, head-over-heels in love with a “software development methodology”.
So you might have noticed that I love life, and love and truth and beauty. I love the stuff that warms my heart, gives me hope, connects me with other people, brings peace and joy. And I hope you’ve noticed that I don’t mean unicorns farting rainbows here — I love sitting with someone who is hurting, in the cold rain, with puddles of smelly-stuff at our feet. I love working through hurts with my lovie, reaching for the light. I love life. And, to get to the point, Agile is life. Agile is love.
Agile is an approach to business that trusts that collaboration actually produces better results than coercion. That change is good because it means things can evolve and improve. That talking about mistakes and difficulties leads to their resolution. That people who love making programs will actually do a better job for the people who love making money if they’re given the tools they need to work, and if people are listening to each other.
How cool is that?!
I hear sometimes that good things (like money) come from carrots and sticks, from fear, from doing what you’re told. What I love about Agile is the way it uses beautiful things that we value (like collaboration, curiosity, trust, connection, problem-solving-pleasure) to create more beautiful things we value (like solved problems and friendship and more solved problems and money-stuff like houses).
The less-fuzzy side of Agile
I figure some Agile folks might be eye-rolling about this; if so, I can understand why. Agile doesn’t look so fuzzy in the real world. It’s about actual workday practices like
- fluid requirements Instead of deciding (or guessing) at requirements and documenting them way in advance and all at once, etching them in stone, Agile development expects requirements to change (improve!) all the time.
- active involvement of stakeholders The people who need the software say whether it’s “done” or not, for example.
- short iterations Biting off a chunk of work that folks can wrap their minds around, and is easy to evaluate the success of.
- pair programming Two sets of eyes on the code means better code. (And I could go on and on about the wonderfulness of collaboration.)
Anyway, if you’re curious to know more about Agile, here’s the original Agile manifesto, and here’s a Wikipedia article to get you started. And if you run a business with an IT department, and you want to make more money with more love, I could introduce you to some brilliant people… ^_^.
6 Comments on “What is Agile and why you might care”
You can track this conversation through its atom feed.
Great post as usual!
The trick is to LOVE and CARE! Not about money, but about people (and animals are people too!) and creation. LOVE and CARE is COLLABORATION. Do that and what money is NEEDED will appear. WEALTH is meaningless unless ALL are wealthy.
BTW, one small criticism: what the hell is wrong with unicorns farting rainbows? 😉
Posted on September 3, 2010 at 2:31 pm.
Jason Douros says:
I’ve worked in Software Development for about 12 years now and I’ve been under most of the gambits of methodologies. From strict painful waterfall to nothing and now Agile Scrum.
I have to say that Agile is by far the best I’ve experienced.
You really have to be careful though. Collaboration needs to be with all of the people setting expectations, goals, features, and deadlines of the software. The moment someone “higher” then the team members decides when a product, feature, or enhancement MUST go out…it all breaks down.
Agile…like all authority structures IMHO…works best when all are equal and no one has an authoritative role over another on the team. Flat collaborative structure is the best way to go in Software Development, and most other aspects of life.
As soon as one person has “power over” another then it all goes to hell form my experience. All authority creates marginalization at some level, and I think we should strive for little to no hierarchy to avoid this. Not to mention loving someone is a ton easier when you are both equal.
Good observations and post. I wonder how much of Agile we could borrow for the structure of our spiritual communities? Or do we start to stray into the business heavy crap from Maxwell, Warren, and Hybels at that point?
Something to think about.
Posted on September 3, 2010 at 7:00 pm.
@traleefitz Yeah, business is an interesting issue when you’re also wanting to follow the Jeebus, huh? Provides me with interesting things to think about
@jasonduros Yeah, I’m so with you. I have to say that the one company I get to see up close seems to do that pretty well. I don’t get a sense of the “threat-culture” I’ve had at some jobs I’ve worked at. On the employee’s part, I think it’s about remembering that it’s a voluntary relationship that either party can walk away from, rather than thinking that the job is something you need to survive. Getting to that point might take some work. — Which brings me back to the nvc thing. 🙂
Posted on September 7, 2010 at 2:10 pm.
I appreciate the general spirit of what you say here. When I discovered agile methods in 2002, I was on the verge of leaving the IT profession altogether. The reasons for that were all the usual complaints about traditional IT organizations and methods. It just wasn’t worth getting up in the morning and going to that sort of job.
I wanted to be clear about that before going on to complain about your definition of agile. First, I think of the Agile Manifesto as the basic definition of “agile” (as a buzzword). It’s a loose definition, and we’ve all felt free to toss in whatever we felt was a good idea under the heading, “agile.” That has led to a lot of confusion about it.
Let’s look at the four points you list under the heading, the less-fuzzy side of agile. The first two points could be derived from the Manifesto, but not the last two.
The Manifesto never mentions “iterations.” It mentions frequent delivery of valuable software. “Iterations” are sometimes useful, but not the only way to achieve frequent delivery of valuable software.
I see two potential problems with including “iterations” in a definition of “agile”.
(1) For skeptics, anything definitionally associated with “agile” will be suspect. They might deny themselves the benefits of adopting an iterative process in cases when that might help them, just because they are keen to avoid anything that smacks of “agile.”
(2) For practitioners, including specific practices in the basic definition tends to limit their openness to alternative approaches. They might (and many do) keep hammering away trying to make “iterations” work in situations for which they don’t help, and overlook other ways to achieve “frequent delivery of valuable software,” such as approaches based on continuous flow and WIP control. “Agile” is not primarily about practices. Practices should be omitted from general definitions, in order to maintain flexibility.
The Manifesto doesn’t mention pair programming. IMHO pair programming has become a general good practice. It is independent of process or methodology. If we include pair programming in the very /definition/ of “agile,” then there is a risk that people will fail to consider using it just because they aren’t adopting an agile process overall.
Posted on October 16, 2010 at 12:14 pm.
Gak. If I suggested that Agile is a list of practices… yuck. I wasn’t really going for some kind of rigid definition. I was aiming to describe the juice of Agile. In fact, going for some kind of firm (big upfront?) definition seems kinda un-Agile to me.
Agile is spry. It welcomes change, looks for ways to improve. Iterations helped improve things, and maybe continuous flow can help more. I hope I described that spryness… that seems more important to me than trying to nail down specifics.
Posted on October 17, 2010 at 9:33 am.
Peter Helander says:
Hi and thanks for great blog. I just wanted to add that here is another good reference that will further people’s knowledge about Agile: https://angelaharms.com/2010/what-is-agile-and-why-you-might-care/#comments .
Also, since I am from Sweden, I know that people over there listen and collaborate a LOT better than over here, with or without Agile involved. Maybe send all Agile wannabees and Agile PROs to Sweden for Agile Camps could be a good idea?
Cheers.
Peter
Posted on December 21, 2011 at 2:58 pm.