Is doing Agile like having a jam session?

This post opens what I hope will become a series of posts on Agile in general and Distributed Agile in particular; about challenges adopting Agile in a geographically diverse environment; about injecting Agile in originally CMMI-oriented environment; all about running Agile with offshore. And to open a series I felt like I needed a metaphor, something to describe Agile in a new fashion, something fancy .

Yesterday I happened to be dragged into a chat in the office of one of our executives mangers (Alex, sales and marketing). People were talking about how to better position our experience and expertise in Agile.

Alex suddenly asked me a question:

- ok. so tell me. what do you do differently in your job [running projects and saving projects that are not going that well, to put it short] when you do it Agile? explain a fundamental difference to me without software jargon terms, make me understand it.

Then he paused and looked straight into my eyes. I felt like I really needed to explain it, and I wanted to explain it.

Think about it. There's no straight answer to this question. Agile manifesto declares principles that don't make (force) project teams do something fundamentally different from a "regular" (plan-based) approach. Iterative, continuous, open, transparent, collaborative, backlog, priorities, changes, test-driven, etc. - all this can be equally true regardless of the approach. I mean, we exploit all these techniques even in a big corporate high-profile, highly-political, and thus heavy on governance and formal processes accounts. None of this was the answer I was going to give...

- Hm... here's what I do different. I am actually always doing it but Agile setup just makes it very natural. Imagine me communicating with my customer (business representative, business analyst, architect, anybody) about requirements and priorities. I would listen to what they're telling me and actively engage in the conversation by running a funny background process in my head. I would convert what I'm hearing into a software abstraction, that is how would I build it. This abstraction is a very abstract abstraction - assumption-based pseudo architecture. It's like if I hear that there's a format conversion I can think "make it XML, there's always an XML-2-XML, we're done. doesn't matter if we end up doing it completely different, enough to know there's a viable approach that makes sense to me now." Or when I hear there's a report and tabular data I think "make it a relational model and I'll query it out, then slice and dice, we're done". And so on. If I couldn't build an abstraction I would ask for more details. Once I have a fuzzy abstraction that I'm comfortable with (I just need to feel it's feasible) I convert it back to the business functions to see the gaps in what I ended up with and what I was hearing in the first place. And here I would challenge the gaps and clarify the concept, redo the conversion, and go on and on in cycles. It's like I'm always actively thinking and building software in my mind as requirements get progressively elaborated on. I do the same in plan-based environment too, but I do it offline (!). In Agile environment I do it online. That's the difference.

And Alex gave me the metaphor I very much liked:

- so it's like jamming, like a jazz band having a jam session, true ?

here you go. It is like a Jam session, don't you think? The only thing is: you've got to be a damn good musician to do a remarkable jam session...

Using critical resources

For a short period of time a few months ago I was writing a lot of PL/SQL code myself on one project. I was covering up the team of 7 DB people who had enough Oracle knowledge but never really understood business domain so were unable to write effective hotfixes to patch a mission-critical system in production. And since it was often an Emergency threatening the very core business process of the customer (we replaced their obsolete core system with the brand new platform) somebody just had to fix it.

I maintained detailed To-Do lists of all items to be taken care of and was double-checking that whatever I’m working on is the most critical NOW. I knew I only have myself to rely on and I wanted to make sure I use my own capacity for the best possible value, understanding there’s no way I could do all of it. And as a result I knew that whatever I didn’t do during a day was less important that what I did do. See the point? there will always be something that will slip thru the cracks. And there may be a lot (!) of stuff. But as long as you know that it’s of less importance compared to what was taken care of plus you know there’s no more effort you could have put in – you’re good. As good as you could be, I mean.