What is Agile, really?
I’m tired of reading misinformation about Agile. I’m tired of reading statements like these, that are just outright wrong:
Agile means writing software without writing documentation.
Agile means not caring about the long term.
Agile means engineers get to decide the project’s features.
Agile means not having strict practices.
And worse still are the half truths where Agile is confused for a specific practice of some Agile developers, statements like:
Agile means pairing.
Agile means Test Driven Development.
Agile means scrum.
So what is agile really?
Agile is writing software in teams that regularly reflect on how to become more effective, and trusting that team to adjust its behavior accordingly.
This is the core of agile, synthesized from Principles behind the Agile Manifesto. It’s about people. It’s about trust. It’s about continual improvement. This is where most implementations of Agile falter: they fail to trust the team. If you can’t build a team you trust to improve themselves; fire yourself. Replace yourself with someone that can.
That’s it. That is all you need to know about Agile. With this core, the team will re-evolve the major practices of Agile, but in the team’s context. Take “ship early, ship often” for example. This principle would quickly get re-derived, as the team’s regular reflections would be blocked on the same problem: they don’t know if they’re doing well or not. A quick root cause analysis would show that they don’t know how they’re doing until they’ve shipped real value to real customers. The rest of the principles can be re-derived in a similar manor.
well put
I agree with your account of Agile, I think the problem is that this account only makes sense to developers. One of the problems with Agile is that it tries to either ignore or dispense with business level accounts of what is going on.
“Ship early, ship often” makes sense in a continuous integration environment – it should make sense to developers, team leaders and project managers, but to business people it sounds terrifying “You mean we’re going to launch every day – do you know how much effort goes into a launch?” The disquiet comes from nobody bothering to address their concerns and speak their language. One thing that comes out of understanding this is that agile training might help both developers (who need to learn to talk to senior management and clients) and clients and senior managers(who need to learn how to remain calm when talking to developers). But I don’t think you can really get anywhere without finding truly remarkable project managers who can speak both business and technology.
good post,
in short, agile is really about <a href=’‘> a set of principles and supporting best practices
let’s try that again…
agile principles and practices
Trust and continuous improvement are part of it, but not the whole thing.
You could make the case that is about sustainability, respect, or craftsmanship. You could make the case that it is about predictability or risk mitigation. You could make the case that agile is about responding to change. Getting real… getting transparent… and that reality and transparency are a two way street. You could make the case that the practices are derived from the principles but are in some ways inseparable.
I appreciate the point you are making, but like agileconsultant said… it comes off like trust me and I’ll write you some good code.
I think your statement summing up the Agile Manifesto’s core statements infers a little much; it loses the meaning of the four statements. I am not saying your statement is wrong, just incomplete. I think the reason it is four statements is simply to make them memorable and because each one is a distinct pillar of the Agile Acroplis (feel free to us that if you like). The principles can certainly be derived from the pillars, but not teh other way around. The principles truly help guide the practices that are used.
BTW, I loved the opening on what Agile doesn’t mean and teh half-truths!
Paul
[...] Desinformación y Verdades a Medias de Metodologías Ágiles Timothy Fitz escribe en su blog una nota acerca de la definición real de una metodología ágil. [...]
What you’re saying rhymes well with one the Agile articles I’ve recently published on the degradation of agile.