A common practice I observe among agile teams is the reliance on burndown charts to gauge progress throughout a Sprint. However, I must confess, I view burndowns as a form of agile banditry. The premise of a burndown chart is that for it to move smoothly from the top left to the bottom right, you must have meticulously planned the entire Sprint upfront. But let’s be honest—when we’re developing products that don’t yet exist, this approach is fundamentally flawed.
In my journey through the world of Agile, I’ve encountered a recurring theme that I can only describe as “agile banditry.” This term might sound a bit dramatic, but it perfectly encapsulates the misuse of certain Agile practices that can undermine the very principles we strive to uphold. One of the most common culprits? The infamous story points and velocity metrics.
Introduction to Agile Metrics: The Pitfall of Story Points and Velocity When it comes to Agile teams, many fall into the trap of focusing on story points and velocity as key metrics for success. While they may seem helpful, they often lead to inefficiency and distraction from what truly matters—delivering value to customers.
In the world of Agile, I often encounter a troubling trend that I like to call the “Agile Bandit” mentality. If you find yourself fixated on metrics such as original estimates versus actuals, it’s time for a serious rethink. This approach not only undermines the very principles of Agile but also diminishes the psychological safety of your team.
In Agile environments, there’s often a temptation to rely on metrics that seem to offer clarity and control over a project’s progress. One such metric is the “say-do” metric, which measures what a team says they will do versus what they actually accomplish. While this may appear useful on the surface, it’s often a slippery slope that leads to vanity metrics, reduced psychological safety, and, ultimately, a focus on outputs rather than outcomes.
In my journey through the world of Agile, I’ve often encountered a myriad of misconceptions that can hinder our progress. One of the most persistent myths is the idea of special Sprints—those elusive Sprint Zeros, hardening Sprints, and bug fix Sprints. Today, I want to share my thoughts on why these concepts can be detrimental to our Agile practices and how we can focus on delivering usable, working products instead.
You can’t spend much time in the Agile space without encountering teams doing some kind of special sprints. Whether it’s Sprint Zero, refactoring sprints, bug-fix sprints, or hardening sprints, these so-called “special sprints” are quite common. However, let’s cut to the chase: special sprints are agile banditry, and those practicing them are bandits in disguise. Here’s why they dilute your team’s ability to deliver usable, working products, and how you can avoid falling into the same trap.
In the world of Agile, we often hear about the famous “three questions” used during the daily Scrum or retrospective sessions: What did I do yesterday? What am I doing today?
In the world of Agile, certifications have long been a point of contention. Lately, there’s been a growing trend of dismissiveness toward certifications, with many expressing skepticism about their value. As someone who has spent years in the Agile and Scrum space, I understand the frustration that certifications often evoke. While I agree with some of the criticism, I also see their value, but only when approached correctly.
Have you ever felt something was off with burndown charts? I know I have. There’s always been this nagging feeling that something wasn’t quite right. Over the years, people have revered these charts as the ultimate tool for monitoring a team’s progress. But I’ve come to realize that this couldn’t be further from the truth.
In the world of Agile, there are many relics that still haunt teams today, and one of the most significant is story points. Ironically, the creator of story points has publicly apologized for their invention. Think about that for a moment—an apology from the creator of a concept that has deeply embedded itself into Agile practices. Let’s dig into why story points have become one of the most persistent, yet problematic, ghosts of Agile past.
In the world of Agile, one ghost that haunts us is dogma. If you’ve been in Agile long enough, you’ve probably encountered those dogmatic individuals who cling to a rigid set of beliefs, refusing to adapt or consider the actual data, feedback, or experiences of the people around them. These folks? They need to be shown the door 🚪. Agile is about flexibility, adaptation, and collaboration—dogma has no place here.
If you’re reading this, congratulations! You’re already part of the top 10%. It’s a bold statement, but one I firmly believe in. The reality is that only a small fraction of people actively engage in continuous learning, exploring new techniques, and diving into various topics. Whether it’s something cutting-edge or a classic like “Crossing the Chasm,” the key is to keep your mind open and your curiosity alive.
As a new product owner, you’re likely bombarded with information, advice, and endless techniques. So, where do you start? What’s the single most important thing you should focus on to ensure your success in this challenging role? The answer is simple: continuous learning.
Understanding is one of those elusive concepts that we often take for granted in our day-to-day interactions, especially in the realm of product ownership. As I’ve navigated through various teams and projects, one thing has become abundantly clear: you can’t measure understanding. It’s not as straightforward as drawing a line in the sand and declaring, “At this point, everyone gets it.” Instead, understanding is nebulous, fuzzy, and deeply personal.
As a new product owner, one of the most crucial responsibilities you’ll face is managing your product backlog. It’s the backbone of successful product delivery. The product backlog is more than a to-do list—it’s the foundation for delivering maximum value. In this post, we’ll walk you through the key elements of product backlog management, provide actionable insights, and share practical tips for mastering this essential skill.
One of the recurring challenges I encounter in organisations is the struggle that product owners, particularly those who are new to the role, face in securing stakeholder attendance at Sprint reviews. It’s a common scenario: you’ve put in the effort, crafted a compelling presentation, and yet, when the time comes, the room feels more like a ghost town than a vibrant discussion space. Even when stakeholders do show up, getting meaningful feedback can feel like pulling teeth. You ask for their thoughts, and all you hear is the sound of tumbleweeds rolling through the desert.
As a Product Owner, one of the most crucial yet often overlooked aspects of your role is marketing. Yes, you read that right. You’re not just managing a product backlog or guiding a development team—you’re marketing a vision. Whether you’re a new Product Owner or seasoned in the role, this skill is vital for success. You need to effectively communicate that vision to various audiences: the team building the product, the stakeholders consuming it, and the customers paying for it. Each group may have different priorities, but they all need to be aligned and engaged with your story.
#shorts #shortvideo #shortsvideo Martin Hinshelwood walks us through the 5 things he would teach an apprenticeship #productowner. This is part 2. To watch the full video, visit https://youtu.be/Tye_-FY7boo
In the world of Agile, transitioning from traditional project management to product management is an exciting but often challenging journey. For new Product Owners, one of the most crucial lessons to learn is the importance of Vision, Value, and Validation. These three pillars fill the vacuum left when we move away from project management frameworks, such as Gantt charts and milestones, that may no longer serve a product-focused organization.
#shorts #shortvideo #shortsvideo Martin Hinshelwood walks us through the top 5 things he would teach an apprenticeship #productowner in the wild. For the full video, visit https://youtu.be/DBa5_WhA68M
One of the most vital skills for a Product Owner is negotiation. Whether you’re a seasoned Product Owner or just starting out, mastering negotiation can be the key to delivering maximum value. It’s a skill that you’ll use constantly — with developers, stakeholders, and leadership within your organization. Let’s dive into how negotiation plays a role in the life of a Product Owner and how you can become a master negotiator.
In my journey through the world of agility, I’ve come to realise that the foundation of successful agile practices lies not just in frameworks or methodologies, but in the relationships we cultivate. Bringing modesty and respect for others into our conversations is paramount. It’s about building trust—trust that extends beyond our immediate teams to encompass the entire organisation and even our customers.
When we talk about the Seven Virtues of Agility, one that often stands out is humility. It’s an essential ingredient for effective collaboration and success within Agile teams. Whether you’re a product owner, product manager, or a developer, embracing humility can dramatically impact the quality of your work and the strength of your team.
In my journey through the world of product development, I’ve often found myself reflecting on the relationship between our products and the users who engage with them. It’s a dynamic that can make or break the success of what we create. Today, I want to share some insights on how we can foster a more benevolent relationship with our users, ensuring that they see our products not as burdens or cost centres, but as valuable tools that empower them.
When we talk about kindness in Agile, we’re referring to something deeper than just being nice. Kindness can take many forms—compassion, benevolence, empathy—and it can be directed toward different parts of our organization. It’s about how we treat our customers, our teams, and even ourselves in the way we work. Agile isn’t just about delivering software; it’s about creating environments where people can thrive, feel valued, and succeed together.
In my journey through the world of agile practices, one lesson has consistently stood out: the importance of patience. It’s a simple yet profound concept that can make or break the success of any team or organisation. As I reflect on my experiences, I’ve come to realise that patience is not just a virtue; it’s a necessity in fostering a healthy, productive environment.
In order for organizations to succeed, they must cultivate trust. Trust doesn’t happen overnight; it’s built on the foundation of patience. Patience with people, processes, and, most importantly, patience with outcomes that may not always align with expectations.
In my experience working with various organisations, I’ve often noticed a significant gap between expectation and reality when it comes to the concept of “done.” It’s a term that gets thrown around in Agile circles, yet its true meaning can often be lost in translation.
When we talk about Agile practices, we often highlight flexibility, collaboration, and continuous improvement. However, one key Agile virtue that is often overlooked is diligence. Diligence, in its essence, is that unwavering attention to detail and the commitment to doing what needs to be done—no shortcuts, no compromises. It’s about ensuring quality at every step of the process, and in the world of Agile, this is where the definition of “done” becomes crucial.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
CR2