“We can’t afford to *not* take an agile approach”

We’re spending a couple days next week with developers at one of our clients to practice agile and more specifically test driven development. In preparation I’ve been exchanging emails with one of their leads on what he is hoping they will get out of this time. He’s a great developer who has recently been exposed to agile practices through his collaboration with Carbon Five. I think his comments are insightful and widely relevant so with his permission I am sharing them with you here.

<snip>

[What we want to accomplish is:] 1. Elucidate what it means to be agile, how it changes the way we think about problems, and show how that thinking is actually practical

…

* WRT #1, a very important and powerful thing I’ve learned from the last few months is to think about the measure of progress as user/customer “visible” artifacts. This really flies in the face of how many of us traditionally think about “progress”; typically progress is this piece of infrastructure or that feature that is required for some future thingy. Concentrating on “user”-visible artifacts gives concrete reward, ability to adapt to problems early, and doesn’t call into existence things that aren’t strictly necessary. It also requires trust in your ability to refactor (ruby is great at that!) and solve problems in the future (we’re all reasonably smart).

Typical objections include:

– “but I’m working on something that isn’t user-visible” — we should address the notion of “user” to be stakeholder, developer, etc. and “feature” to be a concrete artifact

– “but we need all these pieces of infrastructure are required for user-visible feature X!” — you can still decompose the feature into smaller, if not completely useful, pieces. Some of these pieces imply various pieces of infrastructure. By building your infrastructure gradually you always have something you can use *now*, and reduce the risk of ended up with something that’s not quite right.

– “but then where do I put things like design discussion, generating a test plan, and so on?” — some ahead of time design dicussion is useful and necessary, but specifics design decisions are *part* of the implementation of the feature. Testing is *not* a separate step; it’s the definition of what it means for something to be complete. Agile tends to wrap all these things into discrete micro-waterfall units.

– “but I’m building this experimental thing that doesn’t directly contribute to ‘user’ experience” — perhaps there’s another way to look at it, and perhaps it might make sense to think about what specific problem you’re trying to solve. If you can state the problem, you can state a story that implies that it is solved. If not, what are you really doing?

* “Embrace change” is also *really* important. In an environment like ours it’s not useful to get upset if requirements change. Agile methodologies have changing requirements as their primary assumption. Hence the “useful right now” and evolutionary process. [Interesting to note that we built the automated [system] like this, one story at a time, and came in _ahead_ of schedule]

* “Trust yourself” is important too; assume you can refactor and adjust later if you made the wrong decision. This is hard to do, but easier with practice.

* “Communication and collaboration” — In person is way more efficient, and these methodologies tend to favor it. If at an impasse, just start and see where you end up. That’s what we did. A common concern here is that it might be hard to coordinate several teams into a single release, but solutions exist.

* WRT agile practices, something I’ve learned to do in the last few months that is valuable is timeboxing. Totally underrated!

One further thought:

* We can’t afford to *not* take an agile approach (rapid small value-adding changes towards a goal) because 90% of the time when you’re a startup like us you probably won’t end up with (or even want to end up with) what you originally thought you wanted.

</snip>