Balance of Leadership and Control in Scrum
Scrum is built on self-management, yet accountability cannot exist without authority. If Scrum Masters and Product Owners are held responsible for outcomes, how much control should they have? Too much, and teams lose autonomy. Too little, and they become ineffective. This article explores the nuanced balance of leadership, authority, and control in Scrum—how influence must be complemented by decisive action to enable true agility.
Why Measuring Individual Cycle Time is Killing Your Flow (And What to Do Instead)
Looking at cycle time for an individual is a fundamental misunderstanding of how flow works in a system—unless the individual is the system. And here is why! Process Cycle Efficiency (PCE) Drives Flow, Not Individual Productivity Kanban isn’t about individual productivity; it’s about optimising the flow of work through a system. When you measure an individual’s cycle time, you ignore the real bottlenecks—queues, dependencies, and wait times that slow everything down. A person might complete tasks quickly, but if those tasks get stuck waiting for reviews, approvals, or other handoffs, the overall system remains inefficient. If you want faster delivery, fix the system, not the people.
Stop Hiding Behind Complexity and Start Delivering Continuously
Every organisation says their software is ’too complex’ for continuous delivery. That’s nonsense. Complexity is an excuse, not a blocker. Azure DevOps, Starbucks, and countless others proved it wrong. The only real obstacle is the resistance to invest in fixing what’s broken. Complexity is an excuse, not a blocker. Microsoft proved it. Starbucks proved it. You can too; if you’re willing to put in the time, effort, and money.
There Is No Such Thing as a "Junior" Scrum Master
Would you ever hire a Junior CISO or a Junior Financial Director? Of course not. These positions, by definition, require demonstrated mastery of their respective domains, alongside the authority and responsibility to enact meaningful change. The same should be true of a Scrum Master. The idea of a “junior” Scrum Master is a fallacy. The Scrum Master is not an entry-level position, nor is it something that should be handed out as a career stepping stone. A Scrum Master should be born fully formed, emerging from the Scrum Team as a practitioner who has already demonstrated technical mastery, business mastery, and organisational evolutionary mastery. They should be elevated by the team, not assigned by management.
Testing in Production Maximises Quality and Value
Testing in production, is about structured, observable releases that allow for fast feedback, controlled exposure, and rapid course correction, ensuring quality without sacrificing speed. One such paradigm shift in software delivery is audience-based deployment.
Without Delivery, There Is No Value
Before delivery, all ideas and strategies remain theoretical. They are assumptions - educated guesses that may or may not align with actual needs or expectations. Delivery is the only mechanism through which these assumptions are validated, transforming theory into tangible outcomes that can be measured, tested, and improved.
Stop Promoting Branches
The traditional Dev → Test → Staging → Production model is flawed, leading to unnecessary complexity and reinforcing outdated software delivery patterns. This breakdown explains why branch promotion is a failure mode, why GitHub Flow and Release Flow are reasonable alternatives, and why Git Flow belongs in the bin.
Delivery is the only Measure of Progress in Scrum
As a social technology, Scrum has remained steadfast in its ethos for over 32 years, enabling teams to generate value through adaptive solutions to complex problems. Yet, a subtle distinction in its guidance often trips up practitioners - Scrum explicitly mandates a Done Increment but implicitly mandates Delivery. This distinction, though subtle, holds profound implications in a modern context where DevOps has reshaped the landscape of software delivery.
The Scrum Master is accountable for Delivery
Ultimately, the Scrum Master is accountable for the Scrum Team’s success. This includes product delivery, product success, Sprint outcomes, the team’s ability, and ensuring the team has the resources, skills, and ethos needed to succeed. While the entire Scrum Team shares accountability for delivery, the Scrum Master’s role is to create the conditions for effective delivery and continuous improvement. Delivery is the minimum bar for effectiveness—without it, the team cannot measure or realise value. Without delivery, there is no increment, no feedback, and no way to empirically assess value. A Scrum Team that delivers without value is ineffective but still functional. A Scrum Team that fails to deliver anything cannot be considered effective under any measure.
Why Handoffs Are Killing Your Agility
Many organisations attempt to adopt Lean practices without fully understanding their implications in software development. This often leads to excessive handoffs, which fragment communication and reduce agility. Here’s the kicker: handoffs are not Lean, Agile, or DevOps. They are an anti-pattern that introduces waste, increases cycle time, and makes collaboration difficult.
Definition of Done - Objective vs Subjective
In countless teams, there’s a recurring mix-up between “what” we’re building, “how” it aligns with business objectives, and the objective quality criteria by which it should be measured. The result? Chaos masquerading as agility. To clear the air: in Scrum, the “what” and “how” are driven by Product and Sprint Goals. These provide directional clarity but remain inherently subjective—a north star guiding your path, not a litmus test of quality.
Why Most Scrum Masters Are Failing and What They Should Know
As a DevOps consultant, Agile consultant, and trainer, I’ve worked with hundreds of companies to improve their software product development. It’s astonishing how many Scrum Masters lack even a basic understanding of Scrum, let alone the expertise required to support the teams they work with.
You can't stop the signal! But you can ignore it!
In organizational development and team dynamics, Agile (as the Agile Manifesto delineates) and Scrum (as the Scrum Guide outlines) guide teams not by solving their problems but by illuminating the issues that demand attention. These frameworks aim to identify and spotlight the challenges within a team or organization’s processes, effectively saying, “This is wrong, go fix it!” when a team struggles to produce a working product due to various obstacles. These are clear signals!
Pragmatism crushes Dogma in the wild
In my journey of delivering an immersive Product Development Mentor Program over the last eight weeks, a compelling narrative unfolded that beautifully illustrates the essence and true strength of Scrum. This story, rooted in the practical application of Scrum through Minecraft, unveils the depth of adaptability and resilience that Scrum can foster within a team.
Blocked Columns on Kanban Boards Obfuscate Workflow and Undermine Effectiveness
The Boards in Azure DevOps are a powerful tool that your teams can leverage to enable transparent visualization of the current state of value delivery. However, the inclusion of Blocked columns can stealthily erode the very foundations of efficiency these boards are meant to uphold. By obfuscating the state of work-in-progress and breeding a culture of hands-off responsibility, Blocked columns can become the silent saboteurs in your workflow.
The Evolution of Agile Learning: Insights from Scrum.org's Webinar
This week, I participated in a Scrum.org Webinar hosted by Sabrina Love (Scrum.org Product Owner) as well as my colleagues, Joanna Płaskonka, Ph.D. and Alex Ballarin to discuss the state of learning and how immersive learning is the future of training.
The 7 Deadly Sins of Agile: A Grecian Odyssey through Modern Software Development
In the rich tapestry of ancient Greek philosophy, the concept of the seven deadly sins stands out as a profound exploration of human nature and morality. Deeply rooted in Greek thought, these sins were not seen as fleeting transgressions. Instead, they were formidable obstacles, barriers between individuals and a virtuous, fulfilling life.
How to Set and Achieve Effective Sprint Goals
Many teams grapple with the intricacies of Scrum, and one of the most pivotal components is the Sprint Goal. It’s not just a fleeting thought or a mere list of tasks; it’s a commitment, a promise, and a clear direction.
The Definition of Done: Ensuring Quality without Compromising Value
The Definition of Done (DoD) is a sacrosanct measure of quality, ensuring that every piece of work meets the standards necessary for release. On the other hand, acceptance criteria focus on the work’s content. Merging the two can risk the integrity of a working, usable product. This article delves into the nuances of maintaining the sanctity of the DoD while ensuring the delivery of valuable increments.
Deciphering the Enigma of Story Points Across Teams
Over the past decade, a recurring query has been echoing in my ears: “How can we normalise Story Points across teams so that we can look across and maybe compare teams?” It’s high time we address this.
Decoding Scrum Team Work: Balancing Sprint and Refinement Work
Software Development is not just a systematic process but a dynamic interplay of critical work that shapes the progress of your product. A Scrum team’s work can be classified into Sprint work and Refinement. To steer your Scrum Team towards success, it’s essential to understand, manage, and balance these two types of work. This article dives deep into the heart of Scrum team operations, offering clear-cut strategies and innovative visualisation techniques to help you understand and manage your Sprint work and Refinement processes effectively. Decode the intricacies of Scrum teamwork and unlock the path to achieving your product goals with increased efficiency.
The Race for Market Responsiveness: A Fresh Perspective on Organisational Agility
As I sit here, sipping my morning cup of tea, I ponder the current state of organisational agility. I’ve been in this game long enough to have seen the rise and fall of various methodologies, each promising to be the silver bullet that will solve all of an organisation’s woes. I was initially an ALM consultant, then DevOps. But, as I’ve often found, the reality is far from the promise.
Rethinking 'User Stories': A Call for Clarity in Product Backlog Management
As someone who has spent a fair amount of time in the trenches of product development, I’ve realised that the language we use to describe our work can profoundly shape our approach to it. One term that I believe has been misused and misunderstood to the point of causing more harm than good is “User Stories”.
Sculpting the Product Backlog: A Delicate Balance Between Lean Inventory and Future Readiness
In the realm of product development, crafting an efficient Product Backlog is an endeavour akin to sculpting a masterpiece. Just as sculptors chisel away the excess marble to reveal the form within, product managers must carefully mould their backlog, ensuring it’s a lean inventory that reflects the unrealized value of the product. The Product Backlog must encapsulate our current aspirations for the product while being transparent and understandable to all stakeholders. It’s a living artefact that dynamically evolves with the product. However, we must also resist the temptation to create an overwhelming catalogue that loses its sharpness and becomes a weight dangling around the team’s neck.
Rethinking Product Backlog: Navigating Through the Weeds of Complexity
The Product Backlog is a critical asset in Agile product development; it represents a dynamic lean inventory of everything the product needs. For those of us navigating the multifaceted landscape of product development, there is often an impulse to seek an ideal structure for the Product Backlog. The familiar hierarchy of Initiative->Epic->Feature->User Story->Task/Bug is a common schema. However, before embracing this structure as a silver bullet, it’s imperative to critically evaluate the implications of imposing a hierarchy on the Product Backlog and to recognize the nuanced dynamics of working in complex environments. In this article, I will examine the delicate interplay between Product Backlog management and the intrinsic nature of complex systems.
Navigating the Future with a Fine-Tuned Product Backlog
As a seasoned Agile consultant, I find myself amidst conversations about the mechanics of a successful Agile project. Today, I focus on an essential yet often underappreciated aspect - the Product Backlog. A well-ordered Product Backlog that is comprehensible to all stakeholders is a critical beacon that illuminates the path to a transparent future.
From Unused Gym Memberships to Agile Implementation The Parallels of Misapplied Investments
In software development, an increasingly prevalent phenomenon is the adoption of agile methodologies, akin to individuals embarking on fitness journeys through gym memberships. However, a striking parallel between the two realms can be drawn – the misuse and under-utilization of the tools at disposal. The essence of this analogy reflects a more fundamental notion: the gap between intention and implementation.
Storms of Neglect The Perils of Not Delivering Usable Products in Agile Iterations
In light of the importance professional teams place on delivering usable, working products, I find myself compelled to address the woes that befall teams that need to adhere to this crucial tenet. We understand the need for working products; now, let us dissect the perils of straying from this righteous path.
How Usable Working Products Are Your Ultimate Weapon Against Risks
It baffles me how some agile teams, who claim to be the pioneers of modernity, are living in archaic times where usable working products are as rare as unicorns! Just a heads-up, my dear agile practitioners: the linchpin of Agile is a Usable Working Product. Yes, you read it right!
Risk Mitigation: Agile Usable Products vs Documentation in Traditional Project Management
As the software development landscape evolves, evaluating the time-tested traditional project management strategies alongside the burgeoning agile methodologies is essential. The central tenet I would like to explore today is comparing using usable working products as a risk mitigation strategy in Agile with the elaborate documentation characteristic of traditional project management.
