Blog

The Perfect Definition of Done

In addition to whatever else it may have to offer, Large Scale Scrum (LeSS) has resting inside it an idea that is powerful in both its simplicity and scope. Its the idea of the perfect Definition of Done.

According to LeSS Rules, The perfection goal is to improve the Definition of Done so that it results in a shippable product each Sprint (or even more frequently).[1]

The big idea here is that we can use our Definition of Done as a measure or indicator of how well we’re doing on our road to integrating teams, providing rapid, end-to-end responses to customer need and market change, and becoming truly agile. Examining the Definition of Done can help us see and navigate through the incremental steps to achieve this agility.

The idea becomes clearer when we look at four basic steps that are suggested for defining your Definition of Done:[2]

  1. Establish all the actions needed to ship to end customers
  2. Work out what can be done in a sprint
  3. Step back and look at the “undone work” that will be left
  4. Come up with your first incremental improvement goal for expanding the Definition of Done to decrease the undone work.

Those four “simple” steps may include many impressive barriers and encompass a lot of hard work before we achieve the perfect Definition of Done, and in some cases we may not get there for a very long time. But I believe those few steps do express what we’re trying to achieve. You need, of course, to include empowerment, eliminating hand-offs, continuous improvement, and so on. But the fact is, driving toward perfection in your Definition of Done will necessarily involve these principles and practices. They represent the means by which you’ll get there.

There are a couple things I especially like about this approach to defining and maturing the Definition of Done.

First, the idea is scalable.

It’s scalable because the concept applies equally well to an individual team, a whole set of teams working together on a large product, or an entire organization. Regardless of where you are in the game, this approach can be applied. Even an individual team member can look at the current scene and ask themselves, “Am I contributing to a silo? What can I do to improve flow along with the scope of what I contribute?”  At the entire organization level, we can ask, “What’s our cycle time to customer delivery for the entire organization? Can we broaden our Definition of Done to also include measuring outcomes?” And, “Can we include our customers even more deeply in initial product definition? What incremental steps do I take in that direction?” Questions that again, any single team can also ask of itself.

A second thing I like about this idea of the perfect Definition of Done as a measure of and guide to agile maturity, is that it is non-judgmental.

That may sound like an odd thing to say.  Here’s what I mean: Both Scrum itself, as embodied in the Scrum Guide, and LeSS are clear about the goal of having potentially releasable product every sprint.  But the way Larman and Bodde have laid out these suggested steps to creating the perfect Definition of Done, they have implicitly conveyed it in these terms:

  • What’s the specific ideal state – in terms of end-to-end production in a single sprint, for this organization we are dealing with?
  • What can we do now?  How close can we come?
  • What’s the next step we can take to get closer to the ideal?

To me this communicates that, while not compromising on what true agile development at scale means and the value in knowing what it should look like and moving relentlessly toward it, we may not achieve perfection overnight. What is important is that there is an alignment on the goal, and an intensity in moving in that direction. In the end, the market, along with the group’s own desire to produce and contribute, will determine what pace is necessary and achievable.

Any agilest would do well to familiarize themselves with the concept of the perfect Definition of Done, as described in LeSS. It’s in a way the simplest of lenses, one through which a team’s, a unit’s or an entire organization’s agile maturity can be brought into focus, and the optimum road forward viewed with greater clarity.

Of course broadening one’s view of the Definition of Done associates with how broadly the Product is defined, both initially and over time. But that is topic for another time.

[1] Large-Scale Scrum: More with LeSS (Larman and Bodde, 2016 Addison Wesley)

[2] Ibid

Coaching Rightness

As an Agile Coach, you are anxious to add value.  You have armed yourself with all the indicators of team dysfunction, all the techniques for managing conflict, all the bad behavior patterns to watch for in Agile ceremonies and ways to address them.  But with all this knowledge of what can be wrong with a team and how to fix it, there is one tool, stuffed in the corner of your tool bag, that can get neglected: recognizing what is right.

When you’re a hammer, to you everything looks like a nail.  When you’re an Agile Coach, you of course must find things to coach, right?  Sometimes the most courageous thing a Coach can do is not exposing the deep, unspoken problem that everyone is afraid to voice.  Sometimes the bravest thing you can do is to believe in them, focus on what is right about them, and their own ability to act.

What, after all, are you trying to do for this team?  You are trying to make them self-determined, self-organizing, confident enough in themselves to be decisive, and to trust and collaborate with each other.  You’re trying to increase their rightness.

The team’s capacity to address things that are wrong is proportional to how much rightness they have.  In a truly high performing team, wrongnesses don’t stand much of a chance.  They evaporate quickly in the bright light of the team’s smooth operation.  For such a team, looking hard for things wrong would itself be a wrongness, introverting the team away from its forward motion.

It is by making the team more and more right that you accomplish their independence and competence.  When you focus your attention on what is wrong, what needs fixing, you will inevitably find it.  There are an unlimited number of things that you can and will find.  You are the hammer, seeing nails everywhere.

Don’t misinterpret that to mean that a dedication to continuous improvement is a bad thing.  Not at all. A good Coach seeks to improve the team’s ability to continuously improve itself, and their capacity to do so.  That is measured in and enabled. by the team’s pride in quality and confidence that comes with success.

Recognizing and strengthening rightness is more than giving acknowledgements in standup or reviews.  There are number of specific actions you can take to do this.  For example:

  • Having members of the team demo and discuss their contributions to the product at Reviews
  • Taking them to client sites where they see their product in action, helping organizations in major ways
  • Introducing them to clients who tell about the value of the product to them
  • Probing with powerful questions not just in sorting out a situation or relationship needing fixing, but to bring about awareness of achievement when something goes right, that the team member or team just did something that was actually quite remarkable
  • In retrospectives, being just as rigorous about root cause analysis of things that went right as those that went wrong, and logging actions to reinforce them. Maybe nobody quite noticed that when the system was down and they took a hack day, they ended up with their most productive sprint ever.

But the first and foremost thing you can do is look.  Look for the strengths in your team.  And look for what you can believe in about each one of them.  If you can do that, and realize that the real power is theirs, and that you are just there to help them unleash and channel it, you’ll be a great coach.

Business Value – The Holy Grail

Business value delivery is at the heart of Agile, and search for its real meaning has become a sort of Agile Holy Grail.  Yet when you step far enough back from any of our software development practices, we still seem, at the end of the day, seem to mostly operate within the zone of simply “delivering features the customer likes.”  I suppose if you want to stop there and maintain that mindset, then that is one way to play the game.

But if we want to broaden our horizons, move out our sphere of responsibility, and play a trusted role in more organic organizations, we need to look further.  The, for me astonishing, possibility, is that there may be one very simple step that teams and organizations can take to do so.

A good practice is for Business Managers or Product Owners, as a usual part of an initiative, to sort out the leading and lagging indicators that they will track to see if their business objectives have been met.  Methods like impact mapping can help with doing this.  The basic idea is not all that new.  It’s even part of older requirements engineering disciplines, under names like “success measures.”  It was just never much practiced in my experience.

What would be new, at least in many organizations, would be to share these indicators with the development / delivery team as a standard part of the process.  Invite them into the process, at least as observers and perhaps even as contributors of possible lagging indicators.  The idea:  allow the team the opportunity to understand and assume some ownership as well in achieving the actual business value sought by the organization.  This approach could apply regardless of whether the product had to do with software.

With that the picture starts to look more complete.  And to be honest, it resolves a little bothersome thought about Agile that has sometimes nagged at the back of my mind.  In the zeal to flatten organizations and become highly cross-functional, I sometimes sniff a tiny motivation to “finally get out from under the wings of the business” and to seize the opportunity to take the lead role in steering the business.  The fact is there are great business leaders.  They exist.  By broadening our role in the game, as systems people, by the simple step just described, we dramatically improve our ability to collaboratively help them help the business endeavor achieve high goals.  With that comes joint satisfaction.  It also makes gaps in that leadership more transparent, providing the opportunity for them to be addressed, and the opportunity for well-intended business people to evolve to better ways of working, right along with us.

I would love your thoughts on this.  We have all the theory and methods to simply begin doing this and let it become a de facto integral part of any Agile process.  And of course, inspect and adapt on making it work better.

Agile Scaling Conversations from the San Diego Global Scrum Gathering

The San Diego Global Scrum Gathering was a great success!  Between the formal presentations and the Open Space meetings, the topic of scaling, including Large Scale Scrum (LeSS) and comparisons with the Scaled Agile Framework (SAFe) and just basic Scrum, was an area of high interest as you might imagine.

No “final answers” of course, but here are a couple observations that emerged from conversations featuring a mix of coaches well versed in SAFe, LeSS, both, and neither.  It was a dialogue grounded in, but not jaded by a wealth of practical enterprise experience mixed with genuine agile passion.

One general conclusion offered was that some type of SAFe-based approach might be a workable step into agile development for large, complex, and conservative organizations where a full-on assault of the organizational structure would be a non-starter.  There was overall consensus that SAFe does not challenge the existing organizational hierarchy near as much as LeSS.  Craig Larman, in his presentation on LeSS, reinforced its emphasis on moving organizational structure away from local optimization.  Don’t ask how to do Scrum in a large, complicated organization, he said.  Ask why do you have such an organization?

Not that it was all about LeSS vs Scrum.  In his 5 Steps to Disruptive Innovation, Sanjiv Augustine provided a set of clearly articulated steps for transforming to a Product-Centric organization.  And there was the one very veteran coach who observed that after much familiarization and work with both frameworks that he now finds himself tending back toward simply Scrum and basic, incremental Scaling.

Alistair Cockburn observed that with models pushing vision and expectations heavily downward while trying to provide a space for empowerment and agility at ground level, the middle layer of management buffering those teams may take a beating.  In fact, he noted one agile implementation that collapsed upon the departure of just such key figure.  Backtracking with him, Cockburn discovered that this was exactly what had occurred.  The buffer was gone and the delivery teams ended up reverting.

I would be very interested in your thoughts on this topic.  The problem and opportunity of Agile transformation is certainly upon us.  Wouldn’t it be great to have an openly referenceable body of knowledge on empirical paths to success, and speed of transformation, based on some key organizational characteristics?  That would certainly be adaptive and transparent.

Splitting User Stories

According to a survey of over agile 2,000 practitioners by Mike Cohn, at Mountain Goat Software, one of the top three challenges faced in writing user stories was spending too much time trying to split stories in a meaningful way at the cost of building something.

And a survey specifically targeted at splitting stories identified these 4 key concerns:

  • How to split stories so that they show value but can be delivered in an iteration
  • How to avoid the temptation to split stories between functional areas (e.g. dev and test)
  • How to spend the right amount of time splitting stories so you’re not doing it all the time at the cost of getting something built
  • How to not get lost in the 50+ ways to split a story that are out there

Mike lays out a model for splitting that brings some simplicity, structure, and clarity to the topic.  He suggests that internet sites that give 30, 50 or more different ways of splitting stories just create confusion, and that there simply aren’t that many different ways to look at the problem usefully.  He boils it down to what he calls the SPIDR model:*

Spikes – You may need to break out some research.  This one is actually the choice of last resort when using the others in the SPIDR model doesn’t seem to resolve the problem.

Path – If there are multiple possible alternative paths possible within the user story, maybe you can break them into separate stories (not necessarily one for every single path).  For example, the thinnest happy path, the one option path, etc.

Interface – Maybe your first user story will be just for Android, etc.; maybe you’ll provide a very bland user interface with limited features

Data – Maybe in your first iteration on best vacation site, you’ll just pull in data about museums, then later data about historical tours in the area, then outdoor activities available, etc.

Rules – Maybe in the first pass, you qualify potential customers based only on credit rating, Might not be shippable, but you learn a lot.  Then you qualify them according buying profession, then buying habits, etc. He also includes regulatory and non-functional constraints in this bucket.

Maybe this approach isn’t perfect but I’d say it’s a straightforward framework to follow that I think meets the 80/20 rule at the very least.  Another model worth looking at is Richard Lawrence’s  How to Split a User Story  (www.richardlawrence.info)

I would say deep and mysterious is not Agile.  If it starts to seem like user story splitting is a dark art, or one requiring multiple advanced degrees, take a step back.  Try applying one of these straightforward frameworks and see how you do.  Empower yourself and gain some confidence.

Hope this helps.

* Using SPIDR To Split Any Story, Mike Cohn (2017) https://www.betteruserstories.com/training/videos/2

Skills of the Agile Coach – Facilitation

Scrum Masters and Agile Coaches are responsible for maturing their groups of people into high performing teams.  That also means highly collaborative, confident, self-organizing, mutually supportive, high morale teams with a dedication to continuous improvement; teams that are willing to innovate and take chances while also being responsible for their commitments, to each other and their customer.

That’s a lot! And it’s great when it “all comes together.”  But what about when it doesn’t? Agile and the Scrum framework provide the opportunity for high performing teams to emerge and operate, but they don’t by themselves guarantee that this will happen.  Good, smart people can require assistance to mature and thrive as Agile team members.  As W. Edward Deming said, “The individual has been crushed by our style of management today.”  Sometimes the person needs some help digging out.

This being true, we see that knowing and administering the mechanics of the Scrum ceremonies is the very least of what a Scrum Master must be able to do.  But when it comes to helping an entire team in various stages of dysfunctionality mature to a high level of productive collaboration, exactly what skills are required?

We find ourselves looking at a skill that is in no way specific to Scrum or Agile, but also requires a servant leader mindset in order to do execute it well.  We’re talking about the overall skill of facilitation.

Consider these basic facts about facilitation and facilitator skills:

  • Facilitation is the process of enabling groups to work cooperatively and effectively.
  • Facilitation does not mean “solving a problem” or “doing it for someone”. It means doing something that makes a process, like dialogue, run a little better and smoother.
  • Facilitation keeps things focused, drives broad participation, and helps the group to achieve more from the discussions that they would on their own
  • Unfortunately, good dialogue does not always happen on its own. Facilitation can be required to enable dialogue to progress, remain safe and productive
  • Facilitators act as process leaders: they don’t have the sole decision-making authority, nor do they contribute to the substance of the discussion. The facilitator’s aim is to lead the group process; to help the group to improve the way they communicate, examine and solve problems, and be more self-reflective.
  • One key part of the facilitator role is to make the process explicit and so promote the awareness of dialogue.

But wait you say – that’s what a Scrum Master is supposed to do! Interesting isn’t it?  Knowing the mechanics of Scrum falls into the “Scrum is Easy” part.  Leading by example with an Agile mindset and using facilitation skills to help your teams learn to actually collaborate well, means helping them with the “Doing Scrum is Hard” part.  Which is where they really need you.

Be a great Scrum Master or Coach.  If you don’t already have them, acquire the skills to effectively facilitate Agile teams.  The satisfaction you get from seeing your teams reach higher levels of communication and collaborative production will be its own reward.

In upcoming blogs, we’ll take a look at some specific facilitator techniques and a few things an Agile team facilitator should know.  We’ll also look at how facilitation compares and integrates with coaching, mentoring, and training.

High Performing Teams

Our next blog post introduces the concept of a High Performing Team in Agile through a video from our President and Founding Principal, Art Moore.  Be sure to like, comment and subscribe!

Shuhari and The Evolution of Agile

Shuhari (Kanji: 守破離 Hiragana: しゅはり) is a Japanese martial art concept, and describes the stages of learning to mastery.

Shuhari has for some time been associated with learning how to be Agile. Alistair Cockburn introduced its use in the context of learning software methods in general in his early book Agile Software Development.

According to Wikipedia, Shuhari roughly translates to “first learn, then detach, and finally transcend.” Continue reading