I do not want to do Agile

This post comes from a conversation I had with a client, let's call him Joe. He was reluctant to adopt this new Agile Methodology that some other folks in the organization were suggesting. "I just want to put the business people to work with the developers and do the work" he said. Wait a minute. Is there much more to Agile? Not much to be honest.

Let me summarize what I think are the essentials to working with Agile:

• Communication and Collaboration: basically what Joe said, right? I remember I heard Hernan saying ours was a problem of communication, business people communicating a problem to a group of technical folks trying to model a solution for it. Having everyone in the same room and inside the same project is the best way to improve communication (speaking face to face is the most effective way of communicating) and working in the same project (towards the same objective) is the best way to collaborate.

• Customer Involvement throughout the project: or letting the people that understands the business into the construction process. Scrum is nothing but a framework that enables this, breaking what needs to be done in small chunks and working in iterations that allow the business to see the progress and provide feedback that can be capitalized in later iterations.

• Attention to Software Quality: We always talk about this in the Agile community, but doesn't it apply to any software methodology? Of course, having well designed, well tested and clean code is what allows us to change (or adapt to change as Jim Highmith says) and be able to keep coding sustainably (without the cost of change growing exponentially, as (of course) Kent says). Erghh. Probably this applies to any methodology anyway. It is worth stressing out, however, that Agile doesn't work without this leg and of course, Agile is not a solution for the lack of technical skills. There is a set of engineering practices, enforced in the Agile community that (at least in my opinion) improve the quality of the code. Just to name a few: Test Driven Development, Continuous Refactor and Continuous Integration.

So far, besides the attention to software quality (which arguably goes there anyway), I haven't said nothing else than what Joe said. You would say 'what about Scrum, User Stories, etc.'. Think about it and you'll see they fall into these categories.

Just to allow you to think, look at this diagram that I created a while ago and I called it the Agile Architecture, to denote the Agile most important components (I know the name is lousy)

You see. There's not much more. So what do we care when we are crafting projects in 10 Pines (more than thinking if we are doing Scrum correctly or making standups rigourously):

• Are we involving the clients efficiently? Are we showing them how the project is going? (is their feedback being applied?)
• Are we communicating and collaborating efficiently? (among us and with the client?). How can we improve?
• Are we happy with the code we are writing? Are we confident with the automated tests? Are we keeping the code clean and free of technical debt?

And that's about it.