“We are uncovering better ways of developing software by doing it and helping others do it.” Agile Manifesto
Agile has reached – and blazed past – buzzword status.
It’s no longer new (the term being applied to software development over 17 years ago), yet people are still learning about it for the first time. When they do, they frequently refer to agile as a software development methodology, a product development methodology, or a project management methodology.
It’s none of those things, or any kind of thing. It’s a way of looking at and thinking about how to approach knowledge work.
Instead of a noun, it’s an adjective.
Instead of a methodology, it’s a mindset.
What does an agile mindset look like?
There have been a few attempts at describing an agile mindset.
We started with the Manifesto for Agile Software Development. The Agile Manifesto started with the key sentence, quoted above, and then proceeded to share 4 values and 12 principles, focused on challenges of software development teams and based on the situation in 2001.
Then there was the much less known perspective – the Declaration of Interdependence – which tried to bring leadership into the picture.
Recently we’ve seen several other views including Modern Agile, and many others, usually in the form of some sort of manifesto.
In the words of Inigo Montoya, “…there is too much. Let me sum up.”
When you have an agile mindset you accept the fact that you face uncertainty – that you can’t know everything when you start working on something.
When you have an agile mindset you approach things in a way that allows you to continuously learn and adapt. You seek to remove that uncertainty.
When you have an agile mindset your goal is to deliver a desired outcome – you satisfy your customers’ needs.
How do you adopt an agile mindset?
When people adopt agile, undergo an agile transformation, or “have agile done to them” they learn about one of several frameworks (Extreme Programming, Scrum, or SAFe). They learn about techniques, artifacts, roles, and ceremonies.
Those techniques, artifacts, roles, and ceremonies are put in place to help you start behaving in a way aligned with that mindset. But until you know why you do those things, you won’t really understand the mindset.
To adopt an agile mindset, you and your team need to continuously ask yourselves these questions and behave accordingly:
- Do we understand the outcome we’re trying to deliver?
- How can we understand that outcome better?
- Will this help us deliver that outcome?
- Are there things we aren’t sure about?
- What can we do to learn about those things we are uncertain about?
Don’t get hung up on what the framework says.
Don’t worry about what “agile says” (here’s a hint – agile doesn’t say anything)
Resist the urge to label what you’re doing. You don’t need to call it scrum, you don’t need to call it agile, you don’t need to call it lean. If you need to call it anything, call it “what works here.” Labels don’t matter.
What does matter is that you focus on a clear outcome and that you take steps to constantly learn. You seek to continuously understand your customers needs better. You seek to get a better understanding of their desired outcome. You seek to continuously be more effective at satisfying those needs.
The ceremonies, the roles, the techniques? They can be helpful if you keep in mind why you do them. Forget that, and they become agile theater.
How does that make you a better product person?
When you clearly understand the desired outcome and focus on delivering that outcome you avoid delivering things that aren’t necessary.
When you seek to continuously learn about your customers, and their needs you are able to define the right outcome with the minimum amount of output.
When you continuously learn the best way to work with your team you make sure you have a shared understanding about what they need to deliver and why.
In short, you become more effective.
Your team will want to work with you on future products.
Your organization will view you as someone who gets the right things done.
Resources
Frameworks and Methodologies
Alistair Cockburn described the difference between frameworks and methodologies in relation to agile on his blog. The key part of his argument is that methodology is the set of conventions the team agrees to follow. Scrum, Kanban, XP, SAFe, etc. are frameworks that teams use as a starting point for creating a methodology to fit their context.
The Power of the Agile Mindset
This is one of my favorite talks about the agile mindset, and it has nothing to do with the fact that I introduced it in the video. At Agile2011, Linda Rising gave one of her patented “weird talks”. This one was about cognitive psychology and Carol Dweck’s work on fixed and growth mindsets. Linda equated the growth mindset to an agile mindset and proved to be a huge influence to many later discussions about the agile mindset.
The talk was also quite meaningful to me as a father of a bright (not so) little (anymore) girl.
Design Like You’re Right, Test Like You’re Wrong
In a Q&A follow up to OnAgile2017, Jeff Patton explains his views on discovery and why you should design like you’re right and test like you’re wrong. This is a form of learning that product people should do whenever they work on a product that is often attributed to Lean Startup but that Jeff suggests should have been part of agile from the get go. Ultimately, it doesn’t matter where the idea came from as long as you actually do it.
Organizations can exhibit an agile mindset as well.
While the agile mindset is something you usually find in people, it’s possible to see it exhibited in organizations. Here are three organizations that walk the agile organization walk, but see no need to talk the talk, even though they share their practical experiences freely.
Modern Agile Keynote
In his keynote from Agile2016, Joshua Kerievsky explained what he means by modern agility, shared real-world modern agile stories, showed how modern agile addresses key risks while targeting results over rituals, and revealed how the 2001 agile manifesto can be updated to reflect modern agile’s four guiding principles.