Part 3: Understanding Frameworks
I’ve been dreading writing this post for a little while now because the topic is so divisive, even so, I’m hoping that this article will give some insight and understanding of modern product delivery frameworks for aspiring PMs.
There’s a growing misconception that mastering the PM role is just about understanding Agile frameworks, getting a Scrum certificate, and handling routine tasks like scheduling daily standups, prioritising backlogs, and estimating story points. In reality, delivering effective software solutions for customers involves so much more, including strategic planning, discovery, and deep customer understanding.
An analogy I like to use when talking about frameworks is that of a mechanic working on a car. If you had a flat tyre you wouldn’t reach into the toolbox for a hammer, you’d be looking for a spanner to remove the nuts so you can replace the wheel, or maybe your tyre repair kit so you can patch the hole and get the car back on the road. It’s similar in product teams, if the business problem is that you’re building features and measuring output instead of outcomes, just grabbing and implementing a framework won’t solve the problem.
I won’t go into the specifics of any single framework in this article as there are a million others out there that will do a much better job at describing the intricacies of each, but what I do want to cover is what’s important to know when trying to break into product management.
Historical Overview of Software Development Frameworks
To build some context, we need to understand the historical inflection points for software development as a whole, the introduction of Waterfall, the development of Scrum, the rebellion against Waterfall, and the current status of software development frameworks in 2024.
Aha! has a great article on Waterfall vs Agile, and here’s their recount of how Waterfall originated:
“The origin of the waterfall approach is typically attributed to two academic papers published in the 1970s — "Managing the development of large software systems" by Dr. Winston W. Royce and “Software requirements: Are they really a problem?” by Thomas E. Bell and T. A. Thayer. While Royce's paper explained how teams can follow a series of steps to deliver on time and on budget, Bell and Thayer's work focused on the importance of beginning projects with a clearly-defined set of project requirements.”¹
That all seemed well and good, but when you try and document everything about a software solution up front, and then spend some significant amount of time building it, and then release it; what happens if you’ve gone off track at some point and built something that no one wants to use? How can you adjust the process to be more flexible to change, more responsive, more…Agile?
Fast forward to February 2001, when 17 people gathered together in Utah to codify a better process than Waterfall. The way that this change was solidified was through the Agile Manifesto, which officially described this new way of working. There are 12 principles behind the Manifesto that helped to support its ideas. As soon as you read both of these, you will see that both the Manifesto and Principles are very broad in the way that they are worded, generally, when people think of Agile they instantly associate some framework like Scrum² or Kanban, however, there are no frameworks specified in the original documents - and that’s significant.
These days it’s trendy to bash Scrum and other Agile frameworks, even I’m guilty of it, and I think that much of the pushback stems from the commercialisation of Agile. Where there’s money to be made people will find a way to make money, and that’s where the certifications, transformations, and consulting products enter the picture. People figured out that businesses wanted to transition to a better way of working, and the easiest way for an executive to feel like they’ve achieved that is to hire some consultants to come in and implement some processes (a start, middle and end…very Waterfall wouldn’t you say?) and at the end of the transformation project, the executive gets to announce ‘We have transformed and now we’re Agile.’
This type of transformation project has diluted the core ideas and principles of the Agile Manifesto, and has led down a dark path where people know how to do certain rituals for a framework, but don’t know why they’re doing them or how those rituals are meant to help develop software effectively, because in the end they’re just the product of a Waterfall transformation project run by an executive team.
So where does that leave us?
What pairing PMs really need to know about different frameworks
As an aspiring PM, it's crucial to not only know the names of different frameworks but also understand their core principles, strengths, and ideal application scenarios:
Waterfall: This traditional framework follows a linear and sequential approach. It's beneficial in projects where requirements are well-defined and unlikely to change. However, its rigidity can be a drawback in dynamic environments.
Scrum: Scrum is iterative and promotes flexibility and rapid adjustments. Ideal for projects requiring frequent client feedback, it encourages teamwork, accountability, and continuous improvement. But, it may not suit all team structures, especially those not used to rapid iterations.
Lean: With its focus on maximising customer value while minimising waste, Lean is excellent for optimising existing processes and workflows. However, it requires a deep understanding of what adds value from the customer’s perspective.
Kanban: This framework is great for managing workflow with continuous delivery. Its visual nature (using boards and cards) helps in tracking progress and managing bottlenecks but might be less effective in complex projects where the workflow is not continuous or predictable.
Extreme Programming (XP): XP emphasises high-quality software and responsive customer feedback. It’s most effective in environments where requirements change rapidly but require a high level of discipline and close collaboration.
Scaled Agile Framework (SAFe)³: SAFe provides a way to scale Agile practices to large organisations. It’s complex and requires a significant investment in training and change management, making it suitable for large enterprises but potentially overwhelming for smaller teams.
Shape Up: This approach, developed by Basecamp, advocates for fixed-time, variable-scope projects. As well as thinking about ‘bets’ instead of estimation when deciding what to build.
SWARM (Scaling Without A Religious Methodology): This methodology challenges the notion of packaged scaling methods being essential for successful transformation in agile environments. Instead, SWARM focuses on a more holistic approach, emphasising the importance of adapting to specific organisational contexts, encouraging groundswell enthusiasm, and supporting change without strict adherence to a predefined set of processes or certifications.
Applying Frameworks to Business Contexts
When talking to a company, it's vital to understand not just what framework they use, but also why they chose it. Different business types, sizes, and industries may find certain frameworks more beneficial than others. For instance, a startup might thrive with the flexibility of Scrum or Kanban, while a large corporation might want the structure of SAFe.
We can think about the above frameworks as various solutions to the problem of: “I want to build software effectively.” and businesses should be considering whether these solutions deliver the outcome they want. In the same way, as we build software, thinking about whether this feature or solution will achieve the outcome we expect for the business, we should be putting frameworks through the same vigour when figuring out if they work for us and our business.
A business will generally be applying one of these frameworks to try and achieve the goal of delivering software effectively, and by understanding each of them you can understand the specific processes the team will be running. Your first PM job will almost certainly give you no control over what methodology is being used at a business. Still, it will give you great insights into what works and what doesn’t when applying a framework to a specific business type/size/industry that you can learn from and take forward in your career.
Beyond Delivery: Discovering and Validating Ideas
It's important to recognise that most of these frameworks focus predominantly on delivery. However, the discovery and validation of ideas are equally crucial. This gap means there's often a lack of structured processes for understanding and addressing customer needs. As a PM, you should strive to integrate discovery phases into the development cycle, ensuring that the software built not only meets technical specifications but also solves real user problems effectively.
Common Pitfalls and Misconceptions in Product Management Frameworks
As you embark on your journey in product management, it’s good to be aware of some common pitfalls and misconceptions that often mislead new PMs:
Misconception: Agile Equals Scrum: One widespread misconception is equating Agile with Scrum. Scrum is a popular Agile framework, but as we’ve discussed, Agile encompasses a broader set of principles and methodologies.
Pitfall: Overemphasis on Tools and Processes: Many PMs fall into the trap of focusing too much on tools and processes, losing sight of the end goal – delivering value to the customer. It’s crucial to understand that frameworks are a means to an end, not the end itself.
Misconception: More Meetings Equals More Productivity: In frameworks like Scrum, meetings (like daily stand-ups or sprint reviews) are common. However, an excess of meetings can lead to decreased productivity. It's essential to strike the right balance and ensure meetings are efficient and purpose-driven.
Pitfall: Resistance to Change: Another common mistake is rigidly sticking to a framework without considering its fit for the product or team. Be open to adapting and combining elements from different frameworks to find what works best in your specific context.
The Future Outlook in Product Management Frameworks
Looking ahead, the landscape of product management frameworks is poised for exciting developments:
Embracing Flexibility: We will likely see a shift towards more hybrid frameworks that blend methodologies to suit diverse product needs. This flexibility will be key in adapting to rapidly changing market demands.
Increased Integration with AI and Machine Learning: AI tools will play a larger role in streamlining processes, from backlog management to market analysis, enabling PMs to make data-driven decisions more efficiently.
Focus on Customer Experience: The future will emphasise frameworks that prioritise customer experience and value delivery over strict adherence to processes. This includes integrating customer feedback loops more seamlessly into development cycles.
Sustainability, Social, and Ethical Impact: As global challenges intensify, frameworks that incorporate sustainability and social impact considerations into product development will gain popularity.
Conclusion
Well, that's a crash course on understanding product management frameworks. Remember, there's no one-size-fits-all solution in software development. It's all about picking the right tools for the job and adapting as you go. In my next article, I’ll be diving into 'Thinking like a PM' – we'll explore the mindset shift needed to really succeed as a PM. Stay tuned, because understanding the frameworks is just the start; it's how you think and act on them that really makes the difference in the PM world. Catch you in the next one!
If you've got questions, thoughts, or just want to chat about all things product management, feel free to drop me a line at Will@productcoach.io.
¹ https://www.aha.io/roadmapping/guide/agile/agile-vs-waterfall
² Interestingly, Scrum actually preceded the Agile Manifesto by about 6 years, with Ken Schwaber and Jeff Sutherland working together to release this paper in 1995.
³ If a business is touting that they use sAFE it’s good to be weary of them, as this framework is the epitome of the problem where consultants come in and sell a new (and complex) framework to a business to appease executives that they are ‘digitally transformed’ without actually changing anything significant about how they work.
