Better outcomes from evolving Product, Agile & Culture practices in unison
Key takeaways (TL;DR):
- Changing culture is hard, so it should come as no surprise that a lot of digital transformation efforts focus on the Agile delivery process and often with lackluster results where it’s easy to question Agile itself or the chosen frameworks and methodologies
- Modern product practice strives to change the approach from output (what and how much you deliver) to outcomes (the value of your efforts), but these often clash with deeply held cultural norms and the emphasis on process
- Rather than to throw out your Agile framework or try to completely overhaul your Product function, a better way may be to ensure there is balance between Product, Agile and Culture practices
It is a reality that many companies are struggling to adapt to a digital-first world where customers easily abandon products that aren’t tapping into their needs and employees leave for new opportunities at an every increasing pace.
Although this isn’t necessarily a new problem, with companies that have conducted multi-year digital transformation initiatives often seeing staggering low success rates, the pandemic has accelerated this by several years.
Is Agile really working?
For those developing software, this usually means adopting and advancing agile software development practices, including both agile mindset (the little ‘a’, meaning quick and adaptable) and Agile delivery processes (the big ‘A’, meaning frameworks and processes). Problem solved, right? Not so fast..
Whether you are a large enterprise that’s doubled down on SAFe or a smaller shop with a couple “two pizza” Scrum teams, organization are struggling to improve the value they get out of their software product development practice and naturally are questioning whether Agile (and agile) is working, and what to do instead? Stop right there!
I’d argue this is a form of cognitive bias towards the familiar (and IT obsession with process in this instance), and what’s been attributed to Abraham Kaplan (and also Abraham Maslow) as the law of the instrument.
I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” — Abraham Kaplan
So before you go blaming Jeff Sutherland (creator of Scrum) or Dean Leffingwell (creator of Scaled Agile Framework) and declare Agile a failure, let’s look at what else is at play..
Product practice and shift to outcomes over output
While Agile primarily focused on the process to deliver software in smaller chunks, with retrospection and ever greater velocity, modern product management practice tries to shift the emphasis from output (how much and what you put through the delivery pipeline) to outcomes (why what you’re doing matters to customers and what value it brings to them and the organization).
Awesome product folks like Marty Cagan, Melissa Perri and Dan Olsen have done fantastic work promoting this approach, and many organizations have become much better at “creat[ing] tech products that customers love”, as Marty puts it.
But why are so many still struggling?
- As a product person, the easy answer is that the Agile delivery mechanism doesn’t jibe with our product outcome focus (bad Agile!).
- As an engineer or delivery person, the answer is “clearly” that product folks and business stakeholders haven’t sorted out what is needed so that we can just focus on delivering solutions efficiently.
- As a non-product development person, the answer used to be that Agile would make everything much better because we’d do “stuff” so much faster.
Hammers, meet your nails.
By now I’m sure you’ve realized that a big disconnect here is lack of alignment between the various factions, which brings me to the third and final piece of what I call “the triad of Product, Agile & Culture”.
Culture, Vision and Alignment
Amidst what Texas A&M Business School profession Anthony Klotz coined as the “Great Resignation” there’s been a renewed focus on employee experience, not just in terms of pay but also work-life balance and company culture. Companies that focus on intentional culture benefit from higher retention and more motivated employees, but “great culture should [also] provide continuous alignment to the vision, purpose, and goals of the organization”.
Great culture should provide continuous alignment to the vision, purpose, and goals of the organization — Natalie Baumgartner, April 2020, HBR.org
Most of us would agree that having a great company culture is important, but achieving this is hard and takes time. It’s also important to take into account where the organization is currently and avoid mistakes like trying to immediately implement a tool like OKRs without ensuring that there is foundational alignment and commitment.
The same goes for product, where immediately shifting from output (things) to outcomes (results) could end up as just a list of delivered things masquerading as outcomes.
For Agile delivery, the obvious failure mode is that we’ve optimized a really efficient delivery pipeline of “stuff” that neither aligns to company goals nor meet customer needs.
In other words, we create little siloed Product and Agile cargo cults where we go through the rituals and motions that we believe are right without establishing a unified approach that can actual reap the benefits.
What seems to be critical is to ensure that we evolve product practice, agile delivery, and cultural alignment together, and often in a more gradual fashion.
Evolving Product, Agile, and Culture in unison
The premise that I’m advocating is that in addition to evolving the mindset and processes and tools that advance Product Practice, Agile Delivery, and Culture, we need to account for imbalance across both the organizational units themselves as well as in terms of competence gaps.
For those versed in modern product practice, Marty Cagan describes what leading tech product companies do vs basically everyone else. But this is often an ideal state that is far away from where many companies are currently at.
So although striving for greatness across all three areas is a noble and for some an achievable goal, we should ensure that we take a realistic and incrementally beneficial approach that maintains a balance and avoids too much emphasis in one area (e.g., Agile process) while the other ones lag behind.
In practice, that means we may have to be OK with imperfection or suboptimal practices as we evolve, in unison. And yes, by that I truly mean SAFe, project-based development, pre-baked solutions, and lack of organization-wide OKRs. Embrace it.
I’ll illustrate this further via some examples.
Example 1: The smooth Agile train
Agile has its roots in Lean Manufacturing and the concept of reduction of waste through, among other things, reducing the batch size. This in turn was adapted through the Agile Manifesto (over 20! years ago now) for custom software development to combat the traditional project and waterfall approaches to development. We were then (and still mostly are in the context of this example) solving for primarily a process optimization problem, not a customer or employee satisfaction problem.
Whether your flavor of Agile is Scrum, a command and control “scaling” framework like Scaled Agile Framework (SAFe), Kanban, or something different, the goals are pretty similar in that we try to reduce the size of the work, the items we do in parallel (work in process or WIP), and attempt to become more predictable in how fast and how much we get through the delivery pipeline.
So let’s assume your agile delivery process is really good (predictable velocity, CI/CD pipeline, retrospectives that improve the process, etc.). On a fictional maturity scale from 1–5 where 1 is emergent/basic and 5 is optimized/exceptional, let’s rate this company’s Agile practice at a level 4 (out of 5).
Meanwhile, your Product Managers are creating artifacts with outcomes and target metrics from a list of requests, but you aren’t truly validating customer needs (what we call customer research and product discovery). Let’s assess product practice at a level 2. You also have team members that are often leaving, and they aren’t clear about what is truly important for the organization and how we know if we’re winning or losing. We’ll assess Culture in this case at a level 1.
I would contend that this is how things look at a lot of companies today that have made a significant investment in Agile from a process standpoint. Perhaps it’s SAFe or perhaps something else, but it looked different from what everyone was used to and for a while it was really exciting. But then the cracks start to show…
Perhaps there wasn’t a clearly articulated and unified strategic approach that plainly described how the company would win and how success was measured. Perhaps there wasn’t alignment at the top about what not to do (so a lot of different things got prioritized).
Within product, perhaps the product management team had started to evangelize outcomes over output, but given the multitude of “priorities” there wasn’t cohesion and what ended up going through the agile machinery was a still bunch of things. Then everyone was on to the next thing… ad nauseam. If this resonates with your situation, then happy to talk.
Example 2: No rules, just product
This one is admittedly a bit tongue-and-cheek, but hopefully helpful as an illustrative example of an extreme. Note that what should be assumed here is that this is not a start-up looking for product-market-fit, but a company that has an established market presence and competing for market share.
Perhaps the OKRs are set, re-adjusted quarterly, and the cross-functional product team is focused on several experiments to validate what opportunities resonate with our customers and move the needle towards company goals. Perhaps the company used to do SAFe, but given the amount of overhead and negative sentiment it was dropped and our 14 product teams now decide for themselves how to organize and what to prioritize. Perhaps it’s been going great for the last 6 months, as there was just an overwhelming sense of relief when we got rid of all that overhead and teams could self-organize as they pleased. Perhaps there were a couple of winners from the experiments and everyone from the CEO down were excited to launch those features in designated target markets.
Perhaps then the problems started to manifest themselves when our teams had to coordinate across several time zones and across completely different tools and methodologies. Perhaps this resulted in a lot of start and stop, with our Sales, Marketing and Customer Success teams asking when we are going to be able to go GA?
The point of this example is to illustrate that process is not bad, and some agile process coordination and repeatable pipelines do speed up delivery, help drive quality, and ultimately predictability.
Example 3: Culture-led with balanced Product and Agile practices
Perhaps this organization is led by a CEO that again and again shows that she deeply cares about her employees, not just via competitive and gender equal pay and benefits, but about what goes on in their lives and through listening to feedback on how to make it an even better place to work. Perhaps the company and CEO reviews on Glassdoor are consistently favorable and most people that have joined have stayed for several years. The company has clearly laid out which markets it intends to play in (and which ones not to), what needs to happen to generate wins, and how to measure whether that is achieved or not.
Perhaps after slowly growing their Agile practice, the company adapted a lot of the fundamentals behind the Disciplined Agile Delivery (DAD) framework, but realize that no tool/process/framework is perfect and used just enough to ensure that teams can coordinate and mitigate delivery risks.
Perhaps the team topology of each product teams consisted of product managers, designers and full-stack engineers, but despite titles everyone felt empowered to help each other and strive towards the company objectives even if was a little ‘hacky’ at times or didn’t neatly fit within the “rule book”.
Perhaps the product leader and his product managers were aware that they could be doing a bunch more product discovery or try the latest and greatest product practice tools that were brought up in their brown bag knowledge sharing sessions, but given that they feel confident in their product vision and strategy and that they were steering towards the north star metric they weren’t worried about perfection. But nonetheless, everyone continually looked for ways to improve and to try something different, if ever so slightly.
The Goldilocks approach
Of course, in theory, it would be great to be exceptional in all areas, but in reality most companies and people are better in some than others, depending on leadership style, prioritized, organizational design, etc.
So rather than try to optimize each area individually (or radically change direction if status quo isn’t working), the “just right” approach may very well be, as outlined in Example 3, to first focus on ensuring that you are more balanced (look for big gaps and focus there) and then gradually improve Product, Agile, and Culture practices in unison.
