What is agile?
You may be relieved to hear that there is an official version of what agile is, and that it’s only 68 words. Here is the 68 word ‘Agile Manifesto’ (2001) in its compact entirety:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Naturally, there’s a lot of discussion (and sometimes contention) about what agile is and what it isn’t. The manifesto is probably the only description of agile everyone would agree is indeed agile. Beyond the manifesto, no matter what you hear, the ‘correct’ practice of agile depends on what you’re learning works for you and your team.
Since that manifesto in 2001, agile has become for watchword for just about every type of applied innovation. Include both ‘agile’ and ‘innovation’ in the subject line of your next email if you want to make sure all the recipients read it. Please believe me when I say this piece isn’t all about defining terms (i.e. boring), but I think it’s probably worth defining what innovation means for an agile team. I’d say a team is definitely innovating if they’re doing three things on a regular basis:
- Exploring what actually matters to their user in terms of problems to solve, jobs to do, desires to fulfill, etc.
- Testing multiple alternative solutions to the above
- Measuring their success more in terms of outcomes they achieve for the user vs. output they generate
To summarize a practical approach to innovation, I like Donald Norman’s diagram, which you’ll find below. You can see how it moves from problem to solution. Also, the idea with the diamond shape is that you’re considering multiple possibilities (diverging) and then using some type of testing to narrow down what you’ll actually do (converging).
Now, here’s the interesting part: I think innovation is just as important for the team that’s deploying a new chunk of enterprise software (Salesforce, SAP, etc.) as it is for the startup that’s going to change how people medicate their pets (or, you know, whatever…). Sure, innovation is traditionally associated with startups and product companies like Google, but also a lot of projects fail because of a lack of attention to the user—if you’ve ever been involved in enterprise/B2B software, you know what I’m talking about.
How do you know whether an agile team is innovating or not? I’d say it’s more of a spectrum vs. a discrete yes or no. Even if you’re handed a bunch of ‘fixed’ specifications for a solution, you still have to figure out how to implement them and the reality is that you’ll probably end up with a lot of discretion around that. My advice to anyone on an agile team is to think about how you’ll improve outcomes for the user through your actions, which is the essence of innovation. Agile is a great way to do that.
See why IT Teams
Track all your projects – Free for 30 Days