I’ve been doing more introductory Agile and Scrum training recently, and have been thinking about the best way to get across the core ideas that underpin Agile. I find the Manifesto Values a bit too woolly, and the Principles too wordy, to be immediately meaningful. At the same time, David Anderson has blogged again about Recipes for Success. I’ve decided that what might be useful would be to put describe what I believe to be the core ideas as my own recipe for success and this is what I’ve come up with.
The Power-Point version is:
Deliver a steady flow of successful and valuable software, by
Empowering collaborative, trusting and motivated teams,
Responding to feedback and adapting to change, and
Building quality in from the start.
The t-shirt version (if I ever designed a t-shirt) would be:
Deliver Frequent Releases
Empower Teamwork
Inspect and Adapt
Build Quality In
That’s not too different to what David has written about (not that surprisingly) but I think there are some subtleties that may be worth commenting on.
For me the primary goal of Agile is to deliver features and value early and often. The other three points are means to that end, but are significantly part of being Agile that they are worth bringing out. That’s why I chose the “A, by X, Y and Z” format. I can’t imagine a good way of delivering software that isn’t early and often, so that on its own may not be what Agile is. Agile is how we deliver early and often, and teamwork, feedback and quality are the main areas I focus on when working with teams.
Some things I haven’t explicitly mentioned are prioritisation, reducing WIP and balancing demand against throughput. These are things are believe are important, and particularly apply to kanban systems, but at the end of the day I decided that they are more ideas and skills which will come out when teams inspect and adapt to deliver quality releases early and often.
What do you think? Have I missed anything important?
I don’t know if it is a key underpinning of _agile_ per se, but I do think it is important that a team operates as a learning-organization.
The feedback loop from the customers should influence and improve our products, and an agile team responds to that feedback quickly. There is also a feedback loop from the process that should influence and improve our team / process. I think an enlightened team would take an “agile” approach to their agility.
Hi Scott – I’m not sure whether you’re saying I missed out learning or just making a general comment!
Either way, I agree, and I intended that to be covered by “Responding to feedback and adapting to change”. I actually removed “in order to learn and improve” at the last moment as it didn’t feel balanced with the other items.
This is a great bullet list. I’ve been trying to find and develop a more concise definition since finding wikipedia’s article sub-par. The one point perhaps that is missed is aligning development with customer and business priorities. Check out my definition of agile development.