Agile, Lean & HCD are not puzzle pieces which can be put together
They’re mindsets, not processes.
“There are consultants and consultancies that competently specialize in training and coaching in any of these areas, but that’ll leave your organization with the challenge of integrating them because, you need all three to predictably build successful products.” — Jeff Patton
I’ve been there, guilty of doing exactly what Jeff is talking about, trying to implement only one side of the coin — either pushing Human Centred Design (HCD) or agile (even lean, once) — like a moth to the flame, blinded by tunnel vision I pushed my agenda and eventually learned the hard way that they are not mutually exclusive things, rather all three are necessary for building amazing products and experiences.
I see it all too often, companies jump on the agile bandwagon whilst someone else in the organisations has the idea of jumping on the HCD one. Both parties spend a lot of time independently doing some great things, making the company more customer-centric but suddenly friction starts to form between them — they start to step on each other's toes. Suddenly the agile people are mixed in with the design folk and the company starts to ask the question, how do we integrate them? — how does agile, HCD and lean work together?
I’ve worked at places where this dilemma was but a minor inconvenience, however I’ve also seen places where this escalates fast, like a snowball rolling down a hill, turning in some kind of religious divide between fractions — both believe in the same god, the same set of principles yet despite all this common ground they still find themselves at war with each other…why? In my experience, and much like religion, the divide is caused by simply differences in opinions, not because of competing goals or agendas. In reality, all three are trying to achieve the same thing — to build great experiences and products, there’s nothing contradictory about it. (apologies to anyone who is offended by my religious metaphor)
Sadly, often a common goal is not enough and eventually, the two fractions end up pulling in opposite directions, leaving the organisation caught in the middle of some epic tug-o-war for power.
One of the things I often see this conversation eventuates too is where one ends and the other starts? Where does design belong and where does agile come in? Sometimes this questioning is innocent and pure curiosity but other times it’s some kind of jockeying for power — a desire to establish a clear boundary between one person’s turf and another.
Well, what does google say?
One google search away and you can find hundreds of “answers” to the agile vs lean vs design question. In fact, there are a plethora of different models and frameworks out there all telling you how they should work together. Mostly linear frameworks denoting where one ends and the other starts.
Human nature leads us to like such linear frameworks. We are drawn towards clarity and boundaries between where one starts and the other finishes, although in reality this is rarely the case — the world is not so black and white, it’s a whole-lot-of shades of grey.
Many (myself included) are dissatisfied by the latest linear process from Gartner and alike, feeling all kinds of hand-offs between the likes of “design” and “delivery” — like links in a very long chain between the customer and those building the product — rather things are not so linear, they intersect and shift back-and-forth — it’s all pretty grey!
Like many before, we too are no longer convinced with what our google search had provided us and decide to try and visualise it ourselves. After hours of going around in circles, we call it quits, dissatisfied, never quite nailing it — why is it so hard to visualise?
I’ve come to the conclusion, it’s because they are mindsets, not processes and you can’t visualise a mindset (or at least I haven’t seen anyone nail it yet).
HCD (aka Design Thinking), agile and lean are mindsets, not processes. This is why we continue to fail to both apply them and visualise them together — we are looking for answers in the wrong place!
I understand the human desire for linear process and clarity — executives want a ‘how-to’ guide — but that’s not how mindsets work, they’re not plug-and-play, not puzzle pieces that can be easily put together.
Jonny Schneider put it well, he described these three mindsets as the mindsets of product development and I couldn’t agree more. There is no one way, no one answer or mindset rather we need to apply all three if we want to build amazing products.
“There is no one correct way, nor is one single mindset enough. But all together, elements of each mindset help us to find our way forward.“ — Jonny Schneider
Many mindsets, in the one team and (in my opinion) ideally in every person — to quote Jared M. Spool “everyone is a designer” — well in this case a product person.
Jared Spool has talked about this idea at great lengths — that design (and agile and lean as well) are mindsets and skills which should not be contained to one individual or one team. Rather they complement each other and are all necessary when it comes to building great products.
Jared’s organisational maturity is a great example of this and I’m a big fan as it paints a very practical pathway for organisations capability uplift (albeit design focused). The model starts with what Jared calls the “Dark Ages” where companies have no design at all, they then graduate to dabble in design and eventually build up towards the end of the spectrum where design is finally infused within the organisation — where “every project team member has fluent design skills”.
It takes a long time to get to this point, but the benefits are clear. The products and services the team now produces are head-and-shoulders better than anything the team has produced before.” — Jared Spool
Being someone who have experienced both sides of the coin, I’ve been one of those consultants that Jeff Patton was talking about and I learned the hard way the limitations of not integrating these three mindsets and rather pushing only one side of the picture and have felt that very real impact of the organisation trying to work out how to integrate them. However I have also experienced first hand the benefits of the opposite side, the nirvana that Jared Spool’s “Infused UX Design” is describing, where all team members are fluent in design, as well as agile and lean. This is what modern product development looks like, many mindsets infused together in those building the product — a single puzzle piece, not adjoining pieces.
So how does it look all together then?
I’m a fan of Jeff Patton’s duel track approach where there is continual discovery and continual development — neither start and neither end — rather they are two streams of constant work which are tightly coupled.
“Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.“ — Jeff Patton
Two types of work, one team. We are constantly looking to learn more about ideas, problem spaces, our customers, etc whilst also building and shipping things that we have already learned about and have a high degree of confidence on. We then cycle back through and do more-learning by measuring the things that we had shipped in the past — are they giving us the impact that we hoped they would.
As I mentioned earlier separating the people who do each of these kinds of work is a bad idea — rather you want to promote a holistic team who have both an intimate knowledge of their product and its customers.
Many argue that discovery sometimes is a bigger thing, something that cannot be done in parallel or by the same team doing delivery, rather it should be done on its own — maybe we want to probe a problem space or test out a new moonshot idea — and I agree this is sometimes true. At times there is a need for separate discovery but that doesn’t warrant having a separate permanent design team.
Rather in these situations, I’ve often first look to see if it makes sense for the product team as a whole to do the discovery — they’ll keep the lights on but do nothing more from a development point of view. This usually makes the most sense in cases where you have an existing product which is undergoing something like a major pivot — because, a) you have an existing product team to start with and b) if you’re doing something like a major pivot it may no longer make sense to do any further development on the product in its current state.
A second more likely outcome is that this approach doesn’t make sense, for many reasons (like wanting to validate a new product idea). In these cases I would spin up a temporary discovery team — usually an extremely lean team consisting of roughly 1x Product Manager, 2x Product Designers, and 1x Engineer. This discovery team would then spin-back-down once they have completed the discovery and return back to the team where the opportunity came from. Another possible scenario is that they may in fact spin off to form a new product team of their own if the opportunity panned out to be big enough to warrant it.
A parting thought…
To say that an engineer is no use in design and conversely a designer is wasted in development is a narrow minded way to look at product development. Everyone has their strengths and weaknesses but I believe they will always have value to contribute. Sometimes our desire for instant gratification leads us towards extremely tactical approaches, we tend to strive for local optimisation rather than playing the long game — i.e. I can easily optimise for how many lines of code a developer can punch-out or the amount of designs a designer produces — or I can play the long game, be strategic and look at the end-to-end delivery of a product and optimise for that. In my experience the latter tends to lead to better outcomes, maybe not in the short term but overall, yes. This means getting engineers involved in product discovery and conversely, designers involved in development is paramount to building great products — product dev is a team sport!
A good friend of mine refers to himself as a Product Engineer, he is by all accounts a “product person” who displays all three of these mindsets and is a shining example of someone who has reached the end of Jared Spool’s UX maturity spectrum — although an engineer at heart and passionate about extreme programming and good code design, he also has a depth of knowledge in design thinking and HCD. He understands the tradeoffs between these mindsets are necessary for building great products.
I have seen him work in product discovery, deep in research, interviewing customers and helping the team find product-market-fit — and conversely I’ve seen him in his core trade focused on delivery, building and shipping products and often using Jeff Patton’s dual track to do both simultaneously.
For me this is what agile, lean and HCD look like working together, an application of different mindsets and different types of work all done by the same people in the one team.
Often it is quoted that Product Managers are at the intersect of Business, Tech, and Design but I believe the future of high performing product teams is for the whole team to be at the intersect, not just the product manager. Each will still bring their expertise in on a specific area but no longer are the lines between the different stages of a product clear and neither are the lines between different types of product work. I believe this calls for a new bread of product people like my friend. People who displays all three mindsets — a Product Mindset.
