DEV Community: Martin Hinshelwood - nkdAgility.com

Why Most Scrum Masters Are Failing and What They Should Know

Martin Hinshelwood - nkdAgility.com — Thu, 05 Sep 2024 11:14:48 +0000

I’ve worked with hundreds of companies to help them get better at building software products, and it beggars belief that so many Scrum Masters have no idea about Scrum, let alone the domain of the team they are trying to help.

Most Scrum Masters (about 61%*) have not read the Scrum Guide, have no technical acumen within the context of the Scrum team they work with, or have only a basic or rudimentary ability to apply Scrum!

_ And they wonder why they are getting laid off. _

I’m not surprised that they are, and I would go so far as to say that most Scrum Masters are incompetent and should be fired. Unfortunately, many of the 39% of competent Scrum Masters are getting caught up in the cull.

What should a Scrum Master for a software team know?

The core accountability of a Scrum Master is the effectiveness of the Scrum Team! Can you help them be effective if you don’t understand even the most basic practices within that team’s context?

“A Scrum Master is a lean agile practitioner with techical mastery, business mastery, and organsiational evolutionary mastery!” – Lyssa Adkins**

I would expect a Scrum Master for a software team to know:

Scrum : its values, underlying principles, and how to apply them effectively. This includes understanding the Scrum framework (roles, events, artefacts) and the purpose behind each element.
DevOps : understand the three ways of DevOps, common practices, and how to apply them effectively. This means knowing automation, infrastructure as code (IaC), and continuous feedback loops.
Modern Engineering practices : everything from DevOps, plus… CI/CD, SOLID principles, test-first strategies, progressive rollout strategies, feature flags, 1ES (One Engineering System), observability of product. Familiarity with design patterns, refactoring, and coding standards.
Agile/lean beyond Scrum : a strong understanding of other Agile/lean philosophies like Kanban, XP (Extreme Programming), and TPS. Know when and how to integrate elements from other frameworks and strategies to complement Scrum.
Release Planning : understanding what release planning entails, how to break down product roadmaps, and how to forecast releases while balancing priorities. Be able to facilitate discussions with the Product Owner and Developers about product increment goals.
Product Discovery & Validation : understanding what needs to be built and how to make decisions based on limited knowlage. Know and understand evidence-based management and hypothesis-driven engineering practices.
Stakeholder Management : understanding how to work with stakeholders, communicate progress, manage expectations, and foster alignment. Know how to teach the team to shield themselves from external pressure while still delivering value.
Scaling Agile : Understand frameworks for scaling Agile, such as Descaling, LeSS, or Nexus. Be able to coach teams on how to function effectively within a scaled environment and manage dependencies.
Coaching and Facilitation Skills : the ability to coach the team towards self-management, continuous improvement, and collaboration. Skilled in facilitation techniques like liberating structires to be able to facilitate meetings and events.
Conflict Management : possess the ability to navigate the grone zone safely leverage managed conflicts within the team and foster a healthy team environment for ideation and discovery. Understand team dynamics and how to encourage constructive feedback and communication.
Metrics and Continuous Improvement : familiarity with Agile metrics (e.g., Cycle Time, Work Item Aging, Work In Process, Throughput), and how to use them to enable improvement. Ability to encourage the team to reflect on these metrics and find ways to improve.

While the Scrum Master may not _ do _ much of this work above, they are _ accountable _ for it being done effectively! That means training and mentoring teams in the use of the practices above, and then once they understand, knowing when to move towards coaching and facilitation of the team, their stakeholders, and the organisation.

“Without theory, there is no learning. That is, without theory, there is no way to use the information that comes to us. We need a theory for data. We need a theory for experience. Without theory, we learn nothing.” – W. Edwards Deming***

Reference

* Assessment of knowledge based on Scrum Match model and their published data
** Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by Lyssa Adkins
*** System of Profound Knowledge by W. Edwards Deming

The post Why Most Scrum Masters Are Failing and What They Should Know appeared first on naked Agility with Martin Hinshelwood.

You can’t stop the signal! But you can ignore it!

Martin Hinshelwood - nkdAgility.com — Wed, 17 Apr 2024 14:30:00 +0000

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!

Yet, teams often overlook these clear signals. This raises the question: Why does such a disconnect exist between receiving these critical signals and acting on them? What barriers within teams and organizations prevent them from hearing and responding to these alerts?

We can draw parallels to Toyota’s manufacturing process and its concept of the “andon” chain. This chain enables any worker to stop the entire production line upon detecting a flaw, addressing problems immediately instead of allowing defective products to proceed. This approach, critical to Toyota’s quality assurance, symbolizes a commitment to excellence and continuous improvement.

When American car manufacturers adopted this concept, they installed the physical chain, but workers hesitated to pull it. The underlying fear was that stopping the line would result in punitive measures rather than being viewed as a positive step toward quality maintenance. This situation reveals a profound truth: the effectiveness of such systems lies not in their physical presence but in the culture and philosophy that empower their use. Thus, it’s not the “andon” chain that’s broken; it’s the systemic failure to foster an environment that encourages and values its use.

This analogy highlights the challenges of implementing Agile and Scrum within organizations. These philosophies act as the software development and product management’s “andon” chain, signaling when something goes wrong and necessitating action. However, if an organization’s culture or a team’s mindset does not align with principles of transparency, continuous improvement, and feedback responsiveness, these signals will remain ignored.

The primary barrier often stems from fear—fear of repercussions, fear of change, or the inertia of existing practices that discourage deviation from the norm. A lack of understanding or commitment to Agile and Scrum’s underlying philosophies may also contribute to a superficial implementation that fails to capitalize on these frameworks’ full potential.

To reap the benefits of Agile and Scrum, organizations must cultivate a culture that not only listens to but also values and acts upon the signals these philosophies provide. This involves creating an environment where halting the metaphorical production line to fix issues is celebrated rather than discouraged, embedding continuous improvement into the organization’s DNA, and deeply understanding and practising the principles of the Agile Manifesto and the Scrum Guide.

Only then can organizations address the systemic issues blocking success, paving the way for meaningful and sustainable improvement.

The post You can’t stop the signal! But you can ignore it! appeared first on naked Agility with Martin Hinshelwood.

What should you do if your Sprint Review delivers harsh, scathing feedback?

Martin Hinshelwood - nkdAgility.com — Wed, 13 Dec 2023 13:43:00 +0000

Navigating Harsh Feedback in Sprint Reviews – An Agile Approach

In the Agile world, Sprint reviews are pivotal events where feedback can be a gold mine… or a minefield.

What happens when this feedback is not just critical but harsh or non-existent?

How should Agile teams, especially Product Owners and Scrum Masters, navigate this challenging terrain?

In this post, we’ll delve into understanding and managing harsh feedback during Sprint reviews.

Understanding the Gravity of Feedback

When your Sprint review brings in harsh or scathing feedback, or worse, a deafening silence, it’s a red flag that needs immediate attention. But, as John says, this isn’t the time to retreat – it’s an opportunity for introspection and action.

Key points to ponder:

Are we building something our stakeholders genuinely care about?
Is there a disconnect between stakeholder expectations and the product’s trajectory?
How do we bridge the gap between what we’ve produced and what our stakeholders need?

Turning Negative Feedback into a Strategic Tool

Embrace the Negative: Negative feedback, though tough to swallow, is an invaluable indicator. It shows that your path might need adjusting.
Investigate the Root Cause: Don’t just note the negative feedback; dive deep. Why are stakeholders dissatisfied? What did they expect, and what did they receive instead?
Stakeholder Engagement: Enhance engagement levels. If stakeholders are apathetic, find ways to make these reviews more relevant and engaging for them.

Possible Outcomes from a Sprint Review

John outlines three potential outcomes from a Sprint review that’s laden with harsh feedback:

Halt: The feedback might indicate that it’s time to stop. If your product isn’t hitting the mark and there’s no viable path forward, halting can save resources and redirect efforts to more fruitful avenues.
Pivot: Agile loves this term! Pivoting means altering your course. Maybe a slight tweak or a major overhaul is needed based on the feedback received.
Persevere: Sometimes, despite the feedback, your team might need to stick to the plan. This is usually the case when you have strong convictions about your strategy and anticipate future success.

How to Effectively Implement These Strategies

Open Communication: Encourage honest and transparent communication within the team and with stakeholders.
Collaborative Analysis: Work together to analyse feedback and decide the best course of action.
Flexibility: Be prepared to adapt your plans based on feedback.
Stakeholder Mapping: Understand your stakeholders’ interests and concerns to tailor your approach effectively.

Conclusion

Remember, harsh feedback in a Sprint review isn’t the end of the world – it’s a pivotal moment for learning and growth. As John aptly puts it, the key is in how you respond to it. Either halt, pivot, or persevere, but do it with strategic intent and a clear understanding of your stakeholders’ needs.

And remember, Agile is all about flexibility and adaptation. Use every Sprint review as a stepping stone towards creating a product that not only meets but exceeds stakeholder expectations.

Takeaways

Listen to Feedback: Embrace all forms of feedback, even the harsh ones.
Reflect and Analyse: Understand the ‘why’ behind negative feedback.
Be Prepared to Change: Don’t be afraid to pivot your strategy.
Persevere When Necessary: Stick to your guns when you believe in your product’s potential.
Engage Stakeholders: Make your reviews more engaging and relevant.

Agile practices like Sprint reviews are about more than just ticking boxes; they’re about creating a dynamic, responsive environment for product development.

So, take that harsh feedback and turn it into your most valuable asset!

The post What should you do if your Sprint Review delivers harsh, scathing feedback? appeared first on naked Agility with Martin Hinshelwood.

The Urgent Call for Agile Organisational Transformation

Martin Hinshelwood - nkdAgility.com — Thu, 29 Jun 2023 09:00:00 +0000

As we progress deeper into the dynamic landscape of the 21st century, our long-established organisations, born of the Industrial Age and infused with a DNA of strict command and control, stand on shaky ground. These organisations strut with command-and-control bravado, erecting clear hierarchies in their stable inert markets where bureaucracy reigns supreme. However, they are feeling the tremors of a rapidly evolving, technologically charged dynamic markets and are plagued by sluggish responses and missed opportunities, which are their Achilles heel in these new fast-paced markets. Not since the 1970s has the classic hierarchical model, rooted in the stagnant waters of stable markets, been a viable proposition for companies seeking to thrive in an era of unprecedented change and unpredictability. Clearly, we cannot continue to coat deep-seated hierarchical practices with a thin veneer of modern innovation and expect sustainable transformation.

I see countless individuals trapped in the bureaucratic maze of classic hierarchical organisational structures, their creative potential stifled, their drive for innovation subdued. The belief is that switching to a more modern network model could liberate them from this stifling environment, fuelling both individual and organisational growth.

Command & control has overcome agility, but it’s not a lost cause.

There is hope in many new and old organisations moving towards a more market-focused approach based on the Follett’s principles of decentralisation and democratisation of the workplace. A world where cross-functional teams dance directly with market demands, while the rest of the organisation provide the necessary services to enable those teams to be nimble and adaptable, they ride the waves of the change markets.

While market dynamics have shifted dramatically over the last half-century, the operations of businesses have remained stubbornly static. Businesses yearn for the capacity to flex and adapt in response to the ever-changing market landscape, but this requires more than just minor tweaks to team operations. Most big businesses’ current processes, procedures, and practices are finely tuned to maintain the status quo in they were developed in. The need of the hour is for businesses to radically overhaul their organisational architecture to facilitate better alignment with contemporary markets’ swift, volatile pace.

Agile was that attempt; sadly, agility has lost the battle against the monolithic paradigm, and the ghosts of hierarchical structures continue to haunt our organisations. The inherent flaws in most organisational transformations lie in their inability to address the root causes of dysfunction, opting instead for the allure of quick fixes and superficial changes. This approach does little more than perpetuate the reign of command and control, allowing it to thwart the advance of agility.

Moreover, the high failure rates associated with organisational change initiatives have desensitised people towards change, leading to widespread apathy and scepticism. Why invest energy in an endeavour doomed to fail?

Tracing the historical trajectory of the market landscape, we see the colossal momentum generated by the Industrial Age, characterised by rapidly expanding stable, long running, markets and limited competition. A relative state of stasis governed these markets, creating a safe haven for businesses to grow unopposed with a focus only on productivity and ignorant of effectiveness.

During the height of the industrial revolution, Fredrick Winslow Taylor crafted what would become business models tailored to this market reality. Born amidst the emerging markets dominated by textiles, steel and large-scale goods production, this hierarchical model thrived in the predictable, slow-changing, or ‘Inert’, markets.

As the 20th century dawned, competition intensified, and product diversity increased, nudging markets from the predictability of stagnant towards the dynamic, complex, and volatile nature that they have today. This shift gained momentum in the 1940s with the advent of television and software, spreading ideas at a breakneck pace.

The advent of the microprocessor in the 1970s and the euphoria surrounding the moon landings pushed the economy into overdrive. These events marked the transition of almost all markets to the complex dynamic, and the classic organisations, unable to cope with the speed of change demanded by these markets, began to falter.

This transformation, however, went largely unnoticed, and many businesses, although effectively obsolete, continued to lumber forward, propelled by financial reserves, customer goodwill, or sheer scale. Vast amounts of waste encumbered them, and if these organisations fail to breathe life into their moribund structures, they will indeed stumble and fall, though it may take them many years to do so.

Moreover, I’ve noticed a tendency for businesses that initially abandon hierarchical practices to slip back into old habits as they grow. An even more profound realisation is that all start-ups are dynamic network organisations. However, these businesses gradually transformed into monolithic organisations characterised by hierarchies, departments, and command-and-control dynamics without regular hygiene or refactoring.

They build up organisational cruft.

Enter the network organisations, born out of Mary Parker Follett’s revolutionary concept of a decentralised organisational structure. Leveraging her social work experience and fascination with organisational dynamics, Follett centred her approach on social organisation.

Every hierarchical organisation has an underlying network-based organisational structure, a network of communication and collaboration that drives success without relying on the steering and escalation mechanisms that the hierarchical model so heavily depends on.

Despite the rise of numerous attempts to create more dynamic organisations – from the Scaled Agile Framework (SAFe) to the Spotify Model – many of these initiatives merely layer more control mechanisms atop the existing hierarchical model and already excessive bureaucracy.

The time has come for a resurgence, a renewed drive towards the modern network organisational model. Agility’s dream of a decentralised, democratic, low-atrophy organisation that can swiftly adapt to market changes is not an impossibility. To make this dream a reality, we must shift away from classic models and move towards modern ones. However, we continually allow the classic to persist.

As agile practitioners, we’ve enabled this complacency by making organisations believe that only minor changes are necessary. We must challenge these misconceptions, actively promote modern models and practices, and stop accepting that organisational change will take years.

With concepts such as OpenSpace Agile and OpenSpace Modern, we can transform from the traditional, rigid classic model to the modern, adaptive model that can truly thrive in the face of complex, modern markets within only a few months.

Then, with the continued application of constant refactoring and organisational hygiene, we can maintain an agile, modern organisation at scale that can continuously adapt to the changing needs of whatever the market throws at it.

References:

Here is a list of the books, blogs, and content that may have influenced my ideas and positions for this post:

The post The Urgent Call for Agile Organisational Transformation appeared first on naked Agility with Martin Hinshelwood.

Become the leader that you were meant to to be

Martin Hinshelwood - nkdAgility.com — Thu, 04 Feb 2021 13:10:00 +0000

Leadership is not about control, but about inspiring those around you.

Managers transition to Leaders

As organisations move towards modern management practices there will be less of a need for Managers. However that does not mean that those same people are not needed! Their role is shifting from managing people, to managing effectiveness and leading people!

How You Can Achieve Great Relationships and Results; by Ken Blanchard & Renee Broadwell

In a traditional organization, people report to people up the chain of hierarchy. No matter how important we say our customers are to our company, people (even managers) RESPOND to Who is Above Them. We need to change this and upend the story. CxO’s become responsible for clearing obstacles for the Leaders in the organisation to do the same for their teams.

Lead by example and become the leader that you were meant to to be!

For more depth read Good To Great: Why Some Companies Make the Leap… and Others Don’t and The Ideal Team Player: How to Recognize and Cultivate The Three Essential Virtues. Or better yet attend a Professional Agile Leadership Essentials Training with Certification with us.

The Scrum Master is a Leadership Role

There is a belief that the Scrum Master is the Scrum Team’s manager or maybe a Scribe, or even and admin. The Scrum master is not not Report Driven or interested in Resource Utilisation! They are a leader who provides services to the Scrum Team, the Product Owner, & the Organisation.

Scrum Master Anti-Patterns

I love the story of Turn this Ship around David Marquet

Ditch the anti-patterns and become the leader that you were meant to to be!

For more depth read Drive: The Surprising Truth About What Motivates Us and Scrum Mastery: From Good To Great Servant-Leadership. Or better yet attend a Professional Scrum Master with Certification or a Professional Scrum Master – Advanced with Certification with us.

Upcoming Training Opportunities

Guaranteed
| |

Professional Agile Leadership Essentials

Public | Open (16)

                        <a href="https://nkdagility.com/training/scheduled/live-virtual-professional-agile-leadership-41-2-days-in-8th-february-2021/#tickets" title="Book Now">Book Now</a>


                <a href="https://nkdagility.com/training/scheduled/live-virtual-professional-agile-leadership-41-2-days-in-8th-february-2021/">Details <i aria-hidden="true"></i></a> 
              </small>

18:00-22:00

Europe [GMT] |
|

13 - 14 February , 2021

| |

Professional Scrum Master

Public | Open (12)

                        <a href="https://nkdagility.com/training/scheduled/live-virtual-professional-scrum-master-with-certification-in-lagos-nigeria-on-13th-february-2021/#tickets" title="Book Now">Book Now</a>


                <a href="https://nkdagility.com/training/scheduled/live-virtual-professional-scrum-master-with-certification-in-lagos-nigeria-on-13th-february-2021/">Details <i aria-hidden="true"></i></a> 
              </small>

09:00-17:00

Africa [WAT] |
|

15 - 16 February , 2021

| |

Professional Scrum Master

Partner | Public | Open

                        <a href="https://programutvikling.no/slot/professional-scrum-master-with-certification" title="Book Now">Book Now <i></i></a>



                <a href="https://nkdagility.com/training/scheduled/professional-scrum-master-with-certification-in-oslo-feb-15-2021/">Details <i aria-hidden="true"></i></a> 
              </small>

09:00-17:00

Europe [CET] |
|

27 - 28 February , 2021

| |

Professional Scrum Master II

Public | Open (20)

                        <a href="https://nkdagility.com/training/scheduled/live-virtual-advanced-professional-scrum-master-psmii-with-certification-on-27th-february-2021/#tickets" title="Book Now">Book Now</a>


                <a href="https://nkdagility.com/training/scheduled/live-virtual-advanced-professional-scrum-master-psmii-with-certification-on-27th-february-2021/">Details <i aria-hidden="true"></i></a> 
              </small>

09:00-17:00

Europe [GMT] |
|

29 March - 1 April , 2021

| |

Professional Scrum Master II

Public | Open (20)

                        <a href="https://nkdagility.com/training/scheduled/live-virtual-advanced-professional-scrum-master-over-4-1-2-days-on-29th-march-2021/#tickets" title="Book Now">Book Now</a>


                <a href="https://nkdagility.com/training/scheduled/live-virtual-advanced-professional-scrum-master-over-4-1-2-days-on-29th-march-2021/">Details <i aria-hidden="true"></i></a> 
              </small>

18:00-22:00

Europe [BST] |
|

Any Date!

| |

Professional Training in Scrum, Kanban, & DevOps

Delivery Mode: In-Person or Live Virtual

Visability: Private or Public

Request | Details

|

Any Time

We have taught classes from New Zealand to Seattle and everywhere in-between!

And if you would like to schedule a private course for your organization, just get in touch!

The post Become the leader that you were meant to to be appeared first on naked Agility with Martin Hinshelwood.

Story Points & Velocity are a sign of an unsuccessful team

Martin Hinshelwood - nkdAgility.com — Mon, 04 Jan 2021 14:20:00 +0000

Story Points and velocity have been used for many years in the Scrum community and have been engrained so much in the way that things are done that most folks believe that they are part of Scrum. The accepted wisdom is that Scrum Teams are supposed to use User Stories, Story Points, and Velocity to measure their work.

Accepted wisdom is wrong!

Reviewers: Steve Porter

“I used to say Story Points set the Agile industry back 10 years. I was wrong. They set the industry back 20 years.”-Daniel Vacanti

Velocity and Story Points are not Scrum

There are a number of things that we collectively believe are required to do Scrum, and these have been perpetrated by the long-running perseverance of trainers teaching to the lowest common denominator and keeping things as simple as possible. There is the general consensus in the trainer community that folks that attend Scrum training are not smart enough to do anything else. However, if you go have a look at the Scrum Guide and see how many time common things that you believe are mandated in Scrum are referenced:

Velocity: 0
Story Points: 0
Burndown: 0
User Stories: 0
Original Estimate: 0
Bug Count: 0
Actual Completed: 0

The answer to all of these searchers is zero! These are complementary practices that may or may not work within the bounds of your organisational complexity, and all of these are an indication to me that your organisations are onlyjust starting its evolution towards agility.

Managing the unknown is hard

It’s ok for a team to start with Story Points and Velocity. There are many things that change when a team moves from the traditional project management practices of the past to the empirical practices of the future, and sometimes we need to pick our battles. One such battle is that of story points and velocity and in fact all of the gubbins surrounding it.

Perhaps you need to appease other parts of the organisation that are not yet ready for change. Perhaps you have a long journey and this is just somewhere to start.

Story Points & Velocity can be a good starting point!

Planning Poker

I am not saying that there is no value in Story Points or Planning Poker. When a team is just starting out they need to keep things simple and iterate towards better outcomes. We often start from typical traditional practices and Planning Poker becomes a good learning point. Story Points use rough sizing as a way to analyze the work and break it down.

Because really, the scores are made up and the points don’t matter. It’s the conversation that is a valuable thing. The shared understanding that the participants get by having some way to know when they don’t understand the same things. That is awesome.

However, agile teams try to use Story Points and Velocity for future predictability and this is a fallacy. While I would be OK with a team using it for a while, if an Agile Team is still using Velocity and Story Points after they have 5 or 10 sprints under their belt then I would have serious concerns about their ability to adapt to change and their sincerity towards that change. What I mean is that they just don’t understand their work or its nature; This is what I mean by immaturity, and not that something else is a sign of maturity!

Indeed as the Scrum Team using Story Points really has no consistent reference they are just shooting in the dark the same as they were before.

While they have gained an understanding of the goals, they still don’t have an understanding of the predictability and thus no confidence in their predictions. We need concrete data to build trust with stakeholders that we know what we are talking about.

We need confidence!

Velocity

Velocity was a way to assert that confidence with a plot of our delivered story points, and along with some clever calculations we asserted that we were likely to deliver about 20 story points. This was such a wholly improbable assumption that the vast majority of Scrum Teams talk about “carry-over” points and quiz me about how to represent that. Do you re-estimate and stick it on the backlog, does it move to the next sprint?

Scrum Teams have been basing their confidence to stakeholders on an agreed consensus that cant be compared and is susceptible to any change from the makeup of the team from the estimation room.

We need confidence!

Confidence Through Transparency

Confidence is gained by truly understanding the uncertainty of delivery and factoring it into our projections. How sure are you that you will be able to deliver? No really! what is your statistical level of confidence?

Confidence in the dace of uncertainty

In the empirical world where more is known than unknown, we don’t plan all of the work (it will change) and we cant tell you when things will be done.

Except when we can!

The Increment is the Confidence of Transparency of the Future – If we have a Scrum Team then I should be confident in saying that we will have a usable increment at the end of every Sprint. If that is true, then we can have 100% confidence that we can deliver the output from the last Sprint. It works, and it’s done!
The Product Backlog is the Confidence of Transparency of the Future – Since we have a backlog that has been ordered by the Product Owner, who is accountable for maximizing the value delivered I can be confident that what we have Done represents the most valuable things that we could have done.

With both of these being true we can have 100% confidence that we have the most valuable items that the business needs to be completed and ready to deploy. Every additional Sprint just adds to the quantity of value.

Cycle Time Scatter Plot lets you find your confidence

Using a cycle time scatter plot we can assess and find our confidence levels, and even create a Service Level Expectation, that allows us to measure progress against.

You can use this range of confidence levels to determine your current levels of predictability, and monitor the effect of changes that you make to your system on it. If you have an 85% confidence level of 16 days and you’re on 2-week Sprints then you have a problem.

This data is not hard to collect and find a full list of awesome metrics in the Kanban Guide for Scrum Teams from Scrum.org.

The post Story Points & Velocity are a sign of an unsuccessful team appeared first on naked Agility with Martin Hinshelwood.

The Product Goal is a commitment for the Product Backlog

Martin Hinshelwood - nkdAgility.com — Mon, 23 Nov 2020 14:01:00 +0000

In the 2020 Scrum Guide Ken and Jeff introduces the idea of the Product Goal. The Product Goal is a commitment to ensure transparency and focus against progress.

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfil the Product Goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

The Product Goal is the long-term objective for the Scrum Team. They must fulfil (or abandon) one objective before taking on the next.

The 2020 Scrum Guide

The Product Goal is an objective to try and meet rather than a guarantee. We may start on the journey towards the Product Goal and discover that there is a better place to go. While the Product Goal is there to give the Scrum Team focus towards an overall objective, it is also important to realise that it is not immutable. If the Scrum Team realise that the Goal is no longer valuable, or that some other goal becomes more valuable then they should change it.

Some Good Examples of a Product Goal:

“Reach 10,000 new users in 6 months”
“Improve the customer experience by improving the NPS over the next year”

The Product Goal should be a singular Goal that each Sprint Goal can be crafted towards. It should be short, measurable, and easy to understand. Everyone on the Scrum Team and the wider organisation should understand it and how the work that they are doing contributes to it. It is similar to the Visionary Goal that a Business Doctor I engaged helped me create for my business. Every product, every project, and every business should have a Visionary Goal. In Scrum, we call it the Product Goal.

Do you have a Product Goal?

The post The Product Goal is a commitment for the Product Backlog appeared first on naked Agility with Martin Hinshelwood.

Introducing Kanban for Professional Scrum Teams

Martin Hinshelwood - nkdAgility.com — Mon, 26 Feb 2018 15:00:08 +0000

A few weeks ago I was in Boston to visit the Scrum.org offices and learn to teach the Professional Scrum with Kanban (PSK) training class co-taught by Steve Porter and Daniel Vacanti. This is a new Professional Scrum training course created by Ken Schwaber, Scrum.org, the Professional Scrum Trainer Community and Daniel Vacanti who helped to develop the Kanban Method for knowledge work. The new class was just announced by Ken & Scrum.org and includes a Kanban Guide for Scrum Teams that describes Kanban within the context of the Scrum Framework.

TL;DR;

Now you can not only learn Scrum from those that created and maintain it, but you can add Kanban from those that developed it as well. This new class show how to take the core practices of Kanban and implement them within the context of Professional Scrum without changing Scrum. I have already posted on how you can flow work across the Sprint boundary and that was a direct learning from me attending this class.

This is a 2 day class that also has an assessment that will earn you a PSK certification. I’ll be teaching this class in combination with Chris McDermott, founder of Lean Agile Scotland, to bring some much needed Kanban team experience to the class. While I have significant experience with Scrum teams, I have only worked with a few Kanban teams.

Kanban Guide for Scrum Teams

The Kanban community and the Scrum community have been working towards the same end for some time. Since the mission of Scrum.org is to improve the profession of software delivery then anything that we can do to make that a reality is within scope.

Scrum is more than 20 years old and has been trawling some baggage with it. Since the creation of the Scrum Guide Ken & Jeff have been working to remove much of that baggage from the definitive and agreed definition of Scrum and they have done a fantastic job. You will not find a mention of User Stories, Story Points, or Velocity in the Guide. They are not required to create an empirical control system.

I am not saying that they are bad, just that they are merely complimentary practices that you can choose to use or not. And let’s be super clear, if you have an amateur team then you should be starting with User Stories, Story Points, or Velocity, they are good practices. For more advanced teams that are already delivering working software on a regular cadence you might want to change those practices out for ones that focus more on flow, and you might also choose to use User Stories.

You can read the Kanban Guide for Scrum Teams which is an extension to the Scrum Framework. The Scrum Framework is closed for modification and open for extension which is reflected in this new guide. The new Kanban extension adds the following practices:

Visualisation of the workflow
Limiting WIP
Active management of items in progress
Inspecting and adapting workflow

In order to adapt your workflow to maximise the flow of value to your customers we also need to add the following metrics:

WIP
Cycle Time
Work Item Age
Throughput

This is an implementation of Kanban within the context of Scrum and as such has a definition that might differ from other Kanban implementations. Have a read of the guide and see if it appeals to you. For me the ideas of limiting WIP are ones that I have always encouraged teams to do and velocity always seamed like a broken metric.

Professional Scrum with Kanban Training

Working with Daniel Vacanti has opened my eyes to throughput and how it can replace velocity and help answer many of the questions that I have been asking for some time. His training and this class made so much sense that I don’t know why we have not yet adopted these practices in mainstream Scrum. I think that is time for a change.

If you are interested in the same revelations that I had you can read the Guide, and if you like what you see then attend a Professional Scrum with Kanban (PSK) training class with Chris McDermott and I.

The post Introducing Kanban for Professional Scrum Teams appeared first on Martin Hinshelwood - naked Agility Ltd.

Work can flow across the Sprint boundary

Martin Hinshelwood - nkdAgility.com — Tue, 30 Jan 2018 20:12:00 +0000

There is nothing in the Scrum Guide that says that you can’t have workflow across the Sprint boundary. I’m going to suggest that not only can you, but you should as long as you don’t endanger the Sprint Goal.

TL;DR;

The definition of Done is an instrumental part of maintaining transparency of the past work and is not optional. The Sprint Goal provides focus and direction. In order to maintain flow we need to be able to reduce the batch size of the work, thus we must allow for work to flow across the Sprint boundary. If you have a Professional Scrum Team that is adept at creating Done increments of working software then introducing flow can improve the value delivered by increasing the throughput of the team.

Always remember that the Sprint is a container for Planning and not always for Delivery. Just like you can do Continuous Delivery in Scrum, so you can also introduce flow and Kanban. Less skilled teams can also benefit as long as you make sure that you meet the Sprint Goal and Done Increments are created to provide transparency of the past and build trust for the future.

Starting Work that the Development Team knows that it can’t finish

Although you will not find anything in the Scrum Guide that prevents you from flowing work across Sprints you should consider it an advanced technique. Most teams that I work with are not even at the point where they have Working Software at the end of the Sprint and they are often only just achieving their Sprint Goal.

I also believed the myth that we could not flow work across the Sprint boundary. It took a long conversation with Steve and Daniel to kindle a different idea, and long discussions over a beer to make it concrete. My argument went; “If you have to be Done by the end of the Sprint then how can you have any unfinished work?” My argument was wrong! I was confusing the need to have a Done Increment with all of the PBI’s being finished.

If you as a Development Team are practising Continuous Delivery (CD) then they always have working software. I would expect that a team doing CD would have every single element of their Definition of Done (DOD) automated and every Checkin/Pull Request meets the DOD. If that’s true, then when you get to your Sprint Review you just show the work that you have finished.

If you want Flow then CD is no longer optional for a Software Team let along a Professional Scrum Team.

Shipping software with Unfinished work can still be Scrum

There are a number of Engineering consideration that a Development Team will need to take into account if they want to focus on Flow. With CD comes the need to validate early and often, with automation, so that you don’t have to stop and check everything manually. There are a number of practices that can help:

Feature Flags – Often referred to as Feature Toggles this is a way to insert a switch into the code so that something is visible or not to the customer based on a switch. Advanced toggles might support “controlled Exposure” to customers, as well as A/B testing, and other features. Regardless it is generally accepted that you can’t leave all of your toggles in the code indefinitely. Once you have completed the PBI / Feature or tested your hypothesis you need to remove the flag through Refactoring.
Refactoring – The act of restructuring or rewriting code for clarity of purpose and future maintenance. One would never write a book or article and then just published it. You would normally do your first pass… re-read it and update for clarity. Maybe get someone else to take a look, and incorporate feedback. Same for code…
Test Driven Development (TDD) – Part of the general Test First movement TDD allows an engineer to prove that the code that they wrote fulfils some pre-defined purpose. It’s the only way that a coder can prove that code does at least what they intended. This practice also supports refactoring since I can continue to prove that the code after I change it, does what was originally intended.
Many more …

All of these are optional complimentary practices that help you achieve CD but it is not an exhaustive list. There are many other practices that will help, try them and see what works for your team.

While the Scrum Guide does not say that you need to do CD let alone the practices I have listed above, it does require that you create an Increment of Working Software at least once per Sprint. Anything less and you have no transparency of what was done. With no transparency, you lose your empirical process control, and without empiricism, you are not doing Scrum.

Unfinished Backlog Items are not the same as Undone work.

The post Work can flow across the Sprint boundary appeared first on Martin Hinshelwood - naked Agility Ltd.

Professional Scrum is for everyone in your organisation

Martin Hinshelwood - nkdAgility.com — Tue, 16 Jan 2018 13:25:00 +0000

Recently I worked with a new customer in Denver to help them move towards a greater degree of Scrum in their software development. The idea that Scrum is for everyone in your organisation is kind of new, but it reflects the modern understanding of the way people work, and the rejection of Taylorism and command and control. You cant use someone else approaches to get to agility, but you can learn from it.

Healthgrades have been doing Scrum for about 8 years but has recognised that they are struggling to organise around the delivery of working software. Like every other company, once you have something as complex as software to work on, and knowledge workers to do it,the old management styles of the 20th century are just like pouring water on a fat fire…

This is a common problem that I train Scrum Masters to respond to in the Professional Scrum Master (PSM) class, but the fundamental understanding of why this is wrong takes both practical and theoretical knowledge grounded in actual experience. This is why the Professional Scrum Foundation (PSF) class requires that students work in teams to build working software.

The real struggle of implementing agile is that of the old ways, Taylorism, the illusion of command and control, and the belief in magic.

Professional Scrum is for everyone in your organisation

Armed with previous experience with Scrum.org, the PSF class, and me; the CIO, CJ Singh, asked me to come along and train as many people as we could in the time that we had available. Turns out that looked like 147 people from the engineering department, and my did we had a lot of fun. While they have been constantly moving towards a greater degree of value delivery there were a lot of misconceptions built up about Scrum over the last 8 years… those misconceptions were creating a glass ceiling and inhibiting the flow of value to the business.

This is the second time that I have worked with CJ, and again he excelled at helping his team understand that it is the makers that are the ones that get things done. They are the ingenuity that delivers the value that is needed by the business and they are the ones that need to be nurtured. Without the makers coming up with ideas there would be no company, and there would be no ideas; no backlog.

I previously worked with CJ at Backcountry in Utah where I trained everyone in the company. I still get emails from folks from Backcountry, even 5 years later, and many folks considered the experience of going through the PSF class as “a game changer” for them.

The purpose of the PSF class is to not only to level set everyone on Scrum but to give them a very real understanding of what is required to get significant value from it. If, like at Backcountry (Utah), Healthgrades (Colorado), Fraedom (England), Teleplan (Norway), and HESA, I can get everyone in the organisation to participate something then interesting happens. There is enough of a catalyst, a tipping point, that starts the snowball of change rolling.

Conversations and discussion is the point

The conversations that take place over the 2-day class are ones that don’t normally take place and all of the Professional Scrum classes are designed to get people talking about their issues and what experiments might be useful to find the right way.

At Backcountry I had everyone from the CTO to the guy that drove the forklift in the warehouse. That’s right, everyone… including the CEO’s assistant… Because everyone in your organisation has good ideas, many are direct stakeholders. Getting them to feel that they are empowered to make suggestions and to have ideas is part of Agility. Getting the CEO to hear all of the questions, and discussion, around why things are not running as smoothly as they could be, and what would need to change to make that happen is invaluable. Getting the Stakeholders to understand what it takes to build software opens their eyes to the involvement they need to have in the process. Getting the developers to hear the business realities that create the pressures again changes the conversation. How can you possibly hope to change your organisation unless everyone is on board and going in the same direction?

As with all courses where one trains everyone there are usually many dissenters. Folks that don’t want to be there because they think that they know everything or they just don’t think it will be valuable. David was in the “were doing Scrum already so why bother” category, but it only took 4 hours of the class for him to realise how much his understanding had deviated from core Scrum. The fundamental understanding of how Scrum implements empiricism is something that not only do we need to know, but it’s nice to have a reset every so often so that we remember the reasons why.

Creating a bounded environment for change

So many teams I work with across the world forget, or never knew in the first place, why we have things in Scrum. They forget that we need the transparency of the past provided by the Increment of Working Software. They forget that without the Product Backlog we get no transparency on what we are doing next, and without the Sprint Backlog, we have no visibility into what we are doing now. They forget that without that transparency there can be no meaningful inspection of what is going on at each of the Events and no meaningful change to the way that things happen.

Many attendees of the Professional Scrum Foundations at all of the companies I have done it for, regardless of their existing knowledge level, come away with a new appreciation for Scrum, its Artefacts, its Events, and its Rolls. Even experienced Scrum Masters like Katherine has something to learn and find value in the reset. Its easy to become complacent with the organisational dysfunctions that are the “way that things are done here”. I worked closely with Katherine to make sure each of the 6 class that we ran went smoothly and facilitated the right discussions.

Just as Scrum creates a bounded environment so that we can all be going in the same direction in our work, so the Professional Scrum classes create a guided environment for discussion and revelation.

Iteratively tailored training not content

Each instance of the PSF class I learned new things about the organisation, its employees, and how it operated that helped me guide the classes to a better understanding of Scrum. I use the same material as every other accredited Scrum.org trainer worldwide, and I tailored the path. I learned which things we can skip over, and which we need to dive headlong into. Some of the experiences were traumatic, and the discussions heated, and by the end, there was not a single detractor from agility or Scrum in those that went through the classes.

Healthgrades now has 147 people are the pioneers, evangelists, and change agents that now feel empowered to make meaningful change.

One of the outcomes of the Professional Scrum Foundations, along with the new knowledge and excitement, is an organisational change backlog. One that has been created by those that are doing the work and understand the constraints and challenges of the work. The hope is that management then uses the Agility Guide for Evidence-based Management to facilitate changes in the organisation to get rid of those pesky impediments to value delivery that are out with the control of the teams.

Healthgrades now has a Backlog of things that need to change in order to facilitate meaningful change.

With these two things, agile torchbearers who feel empowered and a list of changes, I am hoping that Healthgrades can change their organisation and increase their ability to take advantage of market opportunities as they arise, and out-manoeuvre their competitors with ease. Refine backlog facilitate meaningful change.

The post Professional Scrum is for everyone in your organisation appeared first on Martin Hinshelwood - naked Agility Ltd.

Create your own path to Organisational Agility

Martin Hinshelwood - nkdAgility.com — Thu, 11 Jan 2018 13:28:00 +0000

Other scaled agile frameworks employ a cookie cutter approach to organisational agility. While I accept that they may have worked somewhere once, the likelihood that the same approach will work in your organisation is small. They were created to get a unique company from their existing state to their personal vision of where they wanted to be. To increase the likelihood of success you need a framework that guides you to changing your organisation in an incremental and custom fashion towards your own vision. Cookie cutter approaches will not work for you.

TL;DR

If we accept that our path to agility is unique and will always differ from others we can leverage the Agility Guide to Evidence-based Change to help guide us to a greater degree of organisational and business agility. We can use the same ideas that have created so much product value with Scrum and leverage them to create organisational value as well.

Create your Organisational Change Backlog and Organisational Change Team and create your own path to agility. Then train everyone in your organisation and have them identify, as only those that do the work can, the impediments to value delivery that you have in your organisation.

Create your own path to Organisational Agility

Every organisation, and indeed every department, is a little bit different and you need to tailor your approach to suit the culture that you have. A clear vision and an incremental drive is the starting point to enact improvements.

I have been working with a few companies in the last year to move them towards a greater realisation of their ALM and DevOps visions. In my world, DevOps is made up of your Processes, Practices, and Tools that you use to deliver on your products vision and achieve some amount of business agility. The greater degree of agility that your organisation can attain the larger the competitive advantage that you will have over your competitors. In today’s marketplace, there is no room for inefficient and wasteful organisations that are slow to change. As long as you are building software that your business uses to make money this is indubitably true. It really does not matter if you are selling that software, or that software runs the warehouse that allows you to deliver goods to customers. You rely on the function and features of that software to do business.

The first step to creating a direction for improvement is tocreate an organisational improvement vision. Think about where you would like to be and write it down. And don’t just think of the short or medium term, this will be a living vision of your end goal. Try to think of the ‘whats’ and ‘whys’ that you want to achieve rather than the ‘hows’. You want to set direction and not constrain the ingenuity of those working towards the vision. This vision then needs to be communicated to everyone in your organisation. Everyone needs to understand that you stand behind that vision and plan to enact it.

“The greatest resistance to moving towards the culture and process that you want is the culture and process that you have”

You also need to communicate, and often accept, that it takes time to change. Especially in Enterprise where the greatest resistance to moving towards the culture and process that you want is the culture and process that you have. Indeed if you are being truly iterative in achieving your vision the route to get there will likely change many times as your organisational culture adapts to the changes. The time it takes to reach your vision is directly related to the amount of support that you get in pursuing it. Bottom-up support is not all that is required to enact the type of organisational change that reaching towards business agility needs. You need full executive buy-in for the initiative and not just the usual lip service. They need to act in the change process, after all, it’s their company and if they are not interested in being more efficient and beating competitors then why should you?

If you get that top-down involvement you can often accelerate the move to a greater degree of business agility by short-circuiting some of the usual resistance. Public buy-in at every level removes a lot of the vision backchat that often accompanies chaotic change.

“Scrum is proven to deliver twice the features in half the time”

-Jeff Sutherland, Scrum: The art of doing twice the work in half the time

Now that we have our vision we need to be able to enact it. Time and again Scrum has proven, worldwide and consistently, to deliver on the ‘twice the features in half the time’, promise and it can be used not only for delivering a product, but also for delivering change within your organisation.

In order to enact our vision, we need a continuous improvement cycle where we:

measure the organisational value that we are getting using common metrics that we may need to tailor to our organisation
diagnose our organisation’s capability and determine areas for improvement
Improve based on the direct evidence combined with the organisational capability

This process allows us to create an organisational improvement backlog while leaving room to change dynamically as we create more organisational value. We can easily switch focus to other areas that will provide more value for less investment. You should focus only on your first few steps towards your vision to maintain your ability to change for as long as possible.

The Organisational Change Team – the guiding coalition

At this point you should read the Agility Guide for Evidence-based Change if you have not already as an understanding of the concepts in this document is necessary to understanding this approach. You need to understand that your engineering practices will need to keep pace with your cultural and process changes. You can’t leave any of these three pillars to lag or your pace of change will slow and may stall.

Key to moving forward at a sustainable and consistent pace is a guiding coalition that comprises senior representatives of engineering, commercialisation, and portfolio groups. This guiding coalition is the Change Team that will work through the organisational change backlog. You organisational change backlog should reflect the difference between where you are now and the vision that you want to achieve and the guiding coalition would be responsible for working through that backlog and showing improvements within the organisation to the change owner. These roles and accountabilities, just like for a Scrum Team, are key to being successful.

Guiding Coalition – The group of people that are going to take your organisation forward and enact the change.

Change Owner : The individual who is accountable and responsible for the Organisational Change Backlog. Might be the CEO or senior Product Owner.
Change Team : The Team responsible for delivering against the Organisational Change Backlog. This team should have everyone they need to activate the items that they take on.
Process Manager : The person responsible for making sure that everyone is effective within the bounds of the framework.

If your organisation is large then we may want to break our guiding coalition along the lines of the below Practice Domains and have a separate and relevant guiding collision that is accountable for that domain and for working together with the other domains to achieve the vision.

When you have a large enterprise or even just a large part of that enterprise, it is essential to make sure that you make progress in each of the practice domain identified above. Sometimes that will mean that you need to have a separate and focused guiding coalition for each of the diagnostic practice domains. This will enable progress, in parallel, across each of the disciplines.

Process – Process is typically owned by your Scrum Masters which may be part of your traditional PMO and should contain all of the key drivers for implementing the Scrum framework with your teams.
Productivity – Your engineering teams would be the most relevant and effective members of this domain.
Value – Value is a key factor of your Product Owners and as such their organisation should be the leading members of this guiding coalition.
Quality – Your commercialisation teams may be a key participant here, and with engineering practices high on the list of activities involvement from engineering would also make sense.
Enterprise – This domain should be owned by your leadership and sales teams. This is where you focus on the high-level organisational culture shifts that need to happen.

The ideas above for membership and accountability of the domains is by no means strict and should just be taken as a suggestion. In this process, we are accepting that every organisation is different and we will need to adapt the way we implement this organisational change framework to suit.

Each of the organisational change teams would be accountable and responsible for the delivery of measurable improvements to your organisation on a monthly cadence. While it may seem insurmountable it’s about scale and focus. Break those large changes down into things that are achievable and show valuable improvements. The change backlog will help us focus on, and monitor, the pace of improvements.

As we move towards our vision, after each step, we may need to improve, refactor, or completely redo our organisational change backlog as necessary to maximise achievable organisational value. Another practice that helps with this is communities of practice. Having an organised group of engineers share their knowledge across you teams will help each team assimilate the changes and improve their engineering practices in step with the changes. If you give dedicated time to these communities you should see a marked improvement in everyone’s knowledge and skills.

Avoid sabotage and train all your stakeholders

You should not underestimate the ability of the uneducated members of your organisation, at whatever level, to undermine and often derail the change process. All of your employees are your stakeholders to any organisational change, and its hard to do anything without the support of your stakeholders. On top of this one of your greatest challenges will be making sure that your message, and the agile message, does not get diluted with every telling. While at the executive level there may be a keen understanding of agile and lean and how to implement them the reality is that the further away the message must pass the less likely the message is to remain intact. Think of something as simple as the telephone game; how easily can the message get distorted. Then think of how complex your message of change is.

If you have a core message, like Scrum, that you can have told the same worldwide you can cut through the human need to change the message to one they want to hear. So instead of focusing on posters and booklets, it is far more valuable to spend time in workshops all learning the same thing. Especially if you can get a wide variety of people into those classes.

The most effective agile transformations I have encountered have all got consistent and broad-based training in common. Wither you train with an internally created course or through professional training there is value in everyone having the same understanding of the agile principals and the Scrum framework. When I have dont this for organisations it has visably empowered and exited the folks that work there and kick started the move towards agility. That is why the Professional Scrum Foundations class was created, for brawd training at all levels throiught the organiation. I have had everyone from the guy that drives the forklift in the warehouse, to the CEO of the company in the same room, working on teams to deliver working softwarea. The understanding on empiricism and the complexity of software developemnt that this provides is invaluable for getting folks moving in the right direction.

Get your stakeholders to create Orgnisational Change Backlog Items

The other outcome of the Professional Scrum Foundations class is as a feeder into the organisational change backlog. Who better than the people that are actually doing the work, at all levels, and who have just leanred about Scrum, to create Backlog Items? With the learnings of Scrum fresh in their mind they are eminantly perfect for identifying the Impediments in your current orgnisation to moving towards the new model. The last few hours of the class is dedicated to a workshop that gets all of your stakeholders thinking about what needs to change to move to the new way.

How do you create Backlog Items for your Organisational Change Backolg when every employee is a stakeholder?

The post Create your own path to Organisational Agility appeared first on Martin Hinshelwood - naked Agility Ltd.

If your backlog is not refined then you are doing it wrong

Martin Hinshelwood - nkdAgility.com — Tue, 09 Jan 2018 14:04:00 +0000

Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try to work on things that they don’t understand correctly. However, if you get to the Sprint Planning Event and your backlog is not ready, then you are doing it wrong. If what you build is not of good quality then you should read about Defenition of Done.

TL;DR

If you get to the Sprint Planning event and your Product Backlog Items for the next Sprint are not already of a size that can fit into the Sprint and fully understood by the Development Team, then you are doing it wrong. You are heading for the rocks from the start, and you have no map of the shallows to prevent it.

Although the Scrum Guide does not define Refinement as an Event, you should be doing it. You can come up with your Refinement event(s), or refine ad-hoc. Whatever you chose there is a simple measure of success. If your Development Team looks at something within the next 2 Sprints on the backlog and they don’t understand it, then you have work to do.

If you find that you can’t quite get things to fit and have to stagger iterations, or you are just not able to deliver at all, then a lack of refinement is usually at fault.

What does ready mean for a Product Backlog?

If the Development Team does not understand the things that they are being asked to do how could they possibly agree that the items can fit in a Sprint? You will often find teams that don’t do refinement confused as to why they cant get everything done in a Sprint. While we accept that in an empirical process like Scrum that we, know less up front than we discover as we go, merely taking a guess and hoping for the best is decidedly unprofessional.

“The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.”

-ScrumGuides.org

While we don’t need a definition of ready, we do need a working agreement between the Product Owner and the Development Team. If you are following Scrum, then the Development Team are the ones selecting for the Sprint, and they are the only ones that can decide what they can do. The Development Team should be empowered to refuse to take items from the backlog that either they do not understand, or are too big to be completed in a single sprint. In general, I would expect that a team take at least ten items into their Sprint, so they need to be sized appropriately.

Ready Backlog just means that the Development Team can select it with confidence.

How do you refine your backlog?

Refinement is not an explicit event in the Scrum Guide because it is something that can be different depending on the Product, Domain, or Technology. If you were to ask how much refinement you should do then the answer is “as much as you need and no more”. Too much Refinement is waste, as it too little.

“Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.”

-Scrum Guide

In the Scrum Guide there is the guide that it usually takes not more than 10% of a Development Teams time, and for a two-week sprint, this is reflective of a whole day per Development Team member. 10% may seem like a lot, but not only is it necessary it is a maximum guide and not a minimum. I have found that many teams that were not doing refinement in the past may need considerably more time to get their backlog into some semblance of order. Once it is in order, you are only maintaining a rolling two Sprint projection of what you might achieve.

I usually run at least the first refinement as a guided workshop. Run one before a Sprint Planning and most teams will see the value by the end of the next Sprint. For the Workshop, I get the Scrum Team (Product Owner, Development Team, & Scrum Master) into a room with any necessary subject matter experts and we merely open the existing backlog. Start at the top and ask the Product Owner if this is the next most important thing? If not, find something that is. Then have the Product Owner read and explain it.

Any time the PO deviates from the text that is in the Backlog Item, or adds more information, stop and have someone add that info to the Backlog Item. Ask the Development Team to estimate the item (will or will not fit is fine too as in #noestimates), “Does this look like it can fit with nine other friends into a single Sprint?”. If the answer is no, then you get to work breaking it down, reordering in the Product Backlog, and start refining again. You continue this process until the Development Team agrees that there is enough backlog refined for the next 2 Sprints.

This enables yourProduct Owner to be able to plan future releases and your Development Team to create an execution plan for the current one.

How do you monitor your refinement effectiveness?

During the Sprint Planning event, your Development Team should be able to quickly select a least 10 Product Backlog Items that go towards the chosen Sprint Goal and agree that they fit. If you can do this, and most of the time you get most (not all) of the Items delivered, then you are probably doing enough refinement. If you can’t, then you need to focus a little more on Refinement and making your Product Backlog Ready.

If ar your Sprint Review the Product Owner is always wanting to reject that Backlog Items are complete then there is unlikely to be enough refinement for the Development Team to understand what they are expected to do.

The post If your backlog is not refined then you are doing it wrong appeared first on Martin Hinshelwood - naked Agility Ltd.