I was running projects when I first encountered agile techniques. I still remember the joy of reading the book “Agile Project Management” and seeing clearly how I could improve the way I ran projects. Even before that though, I had adopted improved ways of working that were really just common sense, even before I knew that they were agile).
In particular I found agile approaches brought two very powerful things to project delivery:
- We leverage the community to deliver, rather than aligning resources to critical paths; and
- We continuously manage risk using a “sense and respond” approach rather than “Planning properly to start with”.
I am still a fan or agile project management (and even waterfall in the right context), but I found that thinking of agile as project management inhibited my thinking when I worked with product development teams.
Product management is about value creation and project management is about completing a mission that will create value. Projects consist of milestones and inch-pebbles, while products consist of versions and experiences.
I am definitely a fan of agile product management – We have empowered, focused teams who are learning constantly and creating a continuous flow of value for clients.
My concern is that we seem to be thinking of agile as a product in it’s own right, as opposed to a way to create a product, or a way for a team to learn better ways of working.
Can I please see your catalogue of agile solutions. We have 6 teams in 4 locations and we are hoping to find something in a nice blue culture with some continuous delivery based on a foundation of release trains.
Potential agile customer
I don’t think agile is actually a product
Some say that agile is a mindset – I take this to mean that “agile” is the way the team think, behave and make sense of the world. I am happy with this definition but seeing the world in a new way is not something you purchase.
I don’t think people try to buy a mindset deliberately, but adopting agile practices as part of an agile “transformation” often leads to people implementing their old way of thinking and working, but implemented slightly differently. I explore that further in an article about kangaroos, deer, platypi and the way we learn.
I am not arguing against agile practices here. I believe that good practices will help you to change your team “mindset” in a similar way to yoga or kung-fu practices helping to cultivate a new way of thinking. I just don’t think that there is a catalogue of mind-sets to pick from. I think the team’s mindset is intricately tied to who they are and the environment they operate in.
We can certainly cultivate a more customer focused ethos or a more growth based mindset, but we don’t have an agile product that will create a specific and desirable new mindset within a fixed period of time.
Similarly, I sometimes explain agile as a toolkit or way of working. I can help your team, for example, identify tools, frameworks, practices and complete playbooks that will help your team get through their work more easily. However you cannot simply browse the catalogue and purchase the ideal playbook. You need to experience and combine different practices that, once mixed together, result in your team being more agile than before you tried each of the techniques.
This suggests that agile is something you experience as a journey to help your team find your mojo, or find areas to improve. If this is the case then there is no one “agile” package that you can implement. Instead to evolve your team through a series of experiences, which, collated well, result in ongoing improvements.
However, I recently seen several attempts to show where “agile” is on the Gartner hype cycle. I have also used a diagram about change management to highlight where we might encounter challenges “adopting agile.” Doing this helps make “agile” visible, but I worry that what we are making visible is not actually “agile.” It is a set of things you can implement to become more agile if they are well suited to your context.
But if agile is the outcome we want and we are making visible a potential package of goods and services (products) that might help you get there, then perhaps we are sending the wrong message. We might even be suggesting that the product we implement is the goal we want to achieve. Doing so would distract people from the real goal (greater psychological safety, better ability to respond to change, better collaboration, better ability to experiment and learn, greater clarity, less dangerous magpies swooping people in the garden … or something).
That in turn might lead to people implementing a set of “products” without gaining agility. Even worse, potentially, it might lead to people missing out on opportunities to become more agile because they did not realise they were already on the right journey.
My conclusion is that agile is not a product that can be purchased, or even implemented. It is the improvement you hope to see if you implement something new or refine something old.
I am happy to adopt a playbook or engage in a ceremony, but that is not the outcome, it is just a potential way of getting there.
OK, so maybe I can say that agile coaching is a product that helps take you team from un-agile to agile. Maybe I can say Scrum or Kanban is a way of becoming more agile.
The problem here is that we might be assuming the team is actually “un-agile” which means that they must be sluggish or dull and that implementing our product will make them agile.
It sounds good, but it it’s not true. The old way of working and the old mindset do not not disappear in their entirety and a new way is never perfectly adopted.
We can promise a change initiative will add some value and we can test that it does. But can we say that the organisation has now adopted agile? When are they finished? Most importantly – when were they un-agile?
This probably sounds academic but it is agitating me.
To view a team as un-agile (clumsy, stiff, slow, dull) is a bit insulting and probably arrogant as well.
In every team I have encountered, there are things that they are already doing that help them deliver value faster and more easily and with better quality- agile aspects of who they are and how they work.
There are also things that help them make sense of the world, collaborate better, validate their thinking and get work out the door. This is their current mindset and way of working. This is never perfectly agile, nor completely lacking in agility.
Some teams are in a really bad place and I would call them dysfunctional. Stand-ups won’t help them if we do not tackle bullying, fear, failure to have each other’s back etc.
Scrum and Kanban are good ways to force issues out to tackle them and a good scrum master might tackle the dysfunction. However, creating psychological safety is important whether or not we want to call ourselves agile and may be achieved or destroyed whether or not we adopt a particular framework.
Another team might be tightly knit, high performing and very popular with their customers. I would say they are agile. I am currently working with some teams like that.
However I don’t think that the teams have a finite set of tools and techniques from the agile catalogue of services. Instead they have found a way of working that is currently serving them well. Nor can I say that the team’s journey is “done”, in the way a story, a sprint or a feature are done. Instead the team is still evolving and so is the environment they are performing in.
Improving agility and adopting agile practices are both good things to do regardless of where the team is at.
Unfortunately I have sometimes seen implementing agile practices or even an agile mindset as something that is implemented in the way a product release is implemented. What I should be doing is helping the team to build on what they already have and adopting some new ideas that will make things better.
This would suggest the team is the product and not agile. I could then say that I am helping to enhance the team. Or maybe the way they work is the product and I am helping them to find a MORE agile way of working. But rarely am I decommissioning every aspect of their way of working and replacing it in its entirety.
I can say that I am helping the team evolve and change their mindset, but I am never implementing a new mindset on a team, I am helping them adopt a new way of making sense of the world, if they are willing to do the work of building that new way of thinking themselve.
So maybe my agile coaching is a product and maybe agile practices are also features or products in a catalogue of possibilities . But the illusion that you will get a standard “product offering” that is “the complete and correct agile” at the end of the journey is unhelpful.
So is the illusion that you team are not agile today and that you will be tomorrow.
Your current “substance” is probably the product of your environment, your history and your efforts. You can’t just decommission your mindset and replace it with an agile one and you should not just through out all of your practices to adopt a better “more agile” set of practices.
I guess my conclusion is that I can think of myself as a product that can help your team, or more likely that I can provide a set of services (coaching, reflection, luck generation) that will help your team in their pursuit of agility.
But I cannot sell you a package of something that is called “agile,” I can only help you identify things that will help you be more agile than you are now. Any debate about whether SAFE is good or Kanban is the most evolved agile is less useful than thinking about which gym you will enroll in when in fact you won’t even go and even if you did you are not interested in getting fit.
Instead we should package products that help with the ongoing change journey rather than a single implementation from 0% agile to 100% agile.
James King 