Author: Robert Galen

I was at a conference not that long ago speaking and sharing on various agile topics. As often happens, a young man stopped me to ask a few questions after one of my presentations. We struck up a nice conversation that eventually slipped out into the hotel corridors.

We started talking about sprint dynamics within Scrum teams and I happened to mention that I usually coach teams towards declaring their sprints a success…or pause for meaningful effect…a failure. That we do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant basing it on whether the team achieved their Sprint Goal(s).

He was visibly upset with my view. He said that they (he was working at a well-known Atlanta company) had never failed a sprint. Never! They could not nor would not use that WORD in their culture. I asked him point-blank – have you ever failed a sprint? He said of course they had. Many times. But instead of using the term fail, they used the term ‘challenged’. That way, stakeholders wouldn’t get the wrong idea and question the skills or motives of the team.

We went round-and-round for another 10-15 minutes in our discussion, but we never really settled our differences. We simply agreed to disagree. Although it wasn’t a terribly wide chasm between us, I distinctly remember walking back to my room shaking my head. I simply didn’t understand the big deal about failure. About using the word. About a team saying…we failed. In my coaching practice and in my “day jobs”, I’ve been able to steer and evolve our views so that failure is not a bad word. I.e. failure is good. Failure is ok. Failure leads to improvement.  Failure is a part of life.

So in this post, I want to discuss failure from a few perspectives. The discussion isn’t intended to be exhaustive. Instead, I just want to share some thoughts and to get you thinking about failure…how you view it in your organization, what is your tolerance for it, and re-considering your normal reactions to it. I also think this leads you towards your risk handling as well, because I think the two are inextricably linked.

Coaching to avoid failure

In his blog post from June 20, 2011, entitled Coaching is Not Letting Your Teams Fail, Giora Morein makes the case that agile coaches should be leading or guiding their teams away from failure. He brings up the analogy of a Sherpa guiding mountaineers. And yes, in the mountain climbing example I will have to agree that failure is probably not the result we want.

However, in the non-life threatening cases I think I disagree with Giora. I wholeheartedly believe that failure can actually be good for a team. I also think the role of the coach is to help a team look at their performance through two lenses. The easier of the two is the success-lens. This is the lens where you give the team positive feedback; where you tell them that they need to repeat those practices that work for them. Indeed, what practices they need to amplify and do “more of” so as to achieve greater and greater results.

These conversations are clearly easier.

But what about the failure lens? As a coach, do you provide constructive criticism? Do you show a team where they miss-stepped? Both individually and as a team? I think so. But certainly not in a malicious or heavy-handed manner. I think if you’re effectively coaching a team you must explore their errors & mistakes with equal passion and energy to how you handle their successes.

And I don’t think you do this quietly, hiding behind doors and not externally acknowledging their challenges. No. I think you approach it in a completely transparent and matter-of-fact manner. Laying the groundwork that failure is appreciated and welcome. That from it, your teams look for improvement possibilities and move forward quickly towards delivering improved results.

Agile exposure

In agile teams, there are two key ceremonies that are focused towards success & failure results from a team. In Scrum, that is the Sprint Review (demo) and the Sprint Retrospective (lessons learned). Typically, the sprint review is exposed to the world, so you might want to be careful in how you couch your failures – so that stakeholders don’t misconstrue the impact or the effort the team is putting forth. Nonetheless, I believe you should declare sprints either a success or failure as part of the introduction to the teams review.

In Scrum, it’s the Product Owners role to determine this—and it’s relative to the goal(s) the team committed to at the outset of the sprint. Hopefully those goals were flexible enough to allow the team to adjust their work focus to creatively attain it.

For example, I think a very poor sprint goal is something around the team delivering a set number of user stories—or other indicators of by-rote execution.  I think this leads to potential sand-bagging on the part of the team to hit a numeric goal rather than thinking of the true problem they’re trying to solve. Instead, I think better goals revolve around achieving some sort of demonstrated behavior that solves a specific set of customer problems.  So success is measured against how well the team met the spirit of the goal and how well they applied the agile principles in their execution.

For example, I’ve seen teams that commit to 10 user stories, but who had an extra 3 days at the end of their sprint of idle time, fail their sprint. Sure, they delivered to their commitment, but their commitment was flawed. They sandbagged and over-estimated. They also didn’t make their additional capacity available to their Product Owner and ask for more work within their sprint time-box. Instead they planned ahead or gold-plated their deliverables.

If also seen teams that commit to 10 stories, but deliver 7 have a very successful sprint. In it they work hard against complexity and adversity. They’re incredibly transparent and engage their Product Owner in making daily adjustments on priority vs. their new understanding of capacity. And as a team, while they didn’t deliver the originally perceived quantity, what they did deliver aligned with their goals and met the spirit of the Product Owners intent.

Both of these cases should be discussed in the teams’ retrospective and ways to improve discussed. Not small ways and not ignoring the first teams’ behavioral problems. No. All of it—the good, the bad (mistakes & failures), and significant improvement ideas will be discussed in order for the team to decide what points are worthy of their improvement focus in the very next sprint.

But is failure embraced?

Continuing with my earlier coaching example, I remember not that long ago I was talking to a group of our Scrum Masters at my “day job” iContact. If you don’t know about Scrum, the Scrum Master is the primary coach & guide and agile leadership voice within the agile scrum team. They’re also responsible for maintaining core agile values within the team and for the teams’ overall performance. What I mean by that is—guiding the teams improved performance over time. Continually asking questions like—is their team improving in their overall performance? Is their velocity improving? Is their work quality improving? Is their teamwork and collaboration improving? And, is their focus on delivered customer value improving?

So my point to the Scrum Masters was I felt we hadn’t failed in quite a while. I defined failure in this case as a sprint failure or a stop-the-line incident where a team basically ran into an impediment and needed to re-plan or re-align their sprint.

They all agreed with me that things had been going smoothly. And I received more than a few questioning stares as to why that was a problem. I tried to be careful in my reply, but my concern was that we might be playing it too safe. That we were becoming complacent in our agile practices and that we weren’t stretching ourselves enough. We weren’t taking chances. And we weren’t taking risks.

I explained that these traits are fundamental to the growth and advancement of agile teams. And the fact that we weren’t seeing failures indicated that we’ve plateaued in our growth and performance. I felt this was a problem…and I asked if they could drive more failures from the teams.

Can you imagine the remainder of this discussion?

Here I am the Director of R&D at a successful company talking to my team of Scrum Masters and asking them to drive more failure—to influence their teams towards more risk-taking and inspire more stretch goals. The point I’m trying to make is that I truly embrace failure. That I’ve learned to view it as a critical success criterion and that its absence is a problem for me. I wonder how many organizations and leaders have the same view.

The notion of “Failing Forward”

One of my favorite authors is John C. Maxwell. He’s relatively well known as a leadership coach and he’s quite a prolific author—having written more than 50 books on various leadership topics. He’s got a strong Christian background to his life and writing, so if you’re not so inclined, don’t let that put you off. He’s mastered the art of leadership.

A few years ago he published a book entitled Failing Forward—Turning Mistakes Into Stepping Stones to Success. In it he emphasizes failure as a truly transformative factor in our personal, professional, and team-based lives. But he carefully frames failure with a leaning forward posture. That is—instead of viewing failure as a negative end-state and feeling sorry for ourselves, we should embrace it as a positive learning experience. That you would be “leaning forward” in your failure—leveraging the lessons learned to improve.

I don’t think Maxwell is simply blowing positive smoke in our direction here. History is clearly littered with examples of successes that were inspired, forged, and hardened in the fire of failure—Thomas Edison being a famous example as he persevered to invent the light bulb.

In my agile coaching I consistently use the terminology “fail forward” when I discuss team-based failures. Yes, I want a team to be honest with themselves and acknowledge they failed. But I also want them to embrace their mistakes instead of getting defensive, blaming others or denying it entirely. And I want their posture to be leaning forward. Eager to try something new that will drive different results. Not afraid of failure.

I find that using this terminology helps teams to ‘get’ the nature of failure and to behave appropriately. But beyond terminology, project and functional leadership need to fully support the idea too—meaning the entire leadership team needs to be supportive of failure. There…I said it.

Wrapping Up—But, I’m a bit strange…

All of that being said, I wonder if I’ve got a strange and largely minority view towards failure? I wonder if the right response is to indeed be fearful of it.  To deny its existence.  To spend countless hours trying to predict it.  To never mention it in public. Are those and similar actions the right responses?

To that end, I’m closing this post with a request of all readers. I’ve put together a small, focused survey that I’d like you to take. I know, I know, you’re busy. But I really think your insights will be helpful here.  The survey is focused on gathering a view towards organizational, group/team, and individual acceptance of failure and risk. I’m trying to get to a root understanding of acceptance and also the root cause for those views. While I’m particularly interested in agile teams, don’t let your lack of agile experience prevent you from responding.

Enter Survey Here…

I also request that readers weigh-in with your blog comments too. What I’ll do is collect comments and survey responses, consolidate them, and share them in a future blog post.

I wonder if the survey will be a failure?

Don’t forget to leave your comments below.

There was a wonderful commercial I remember from years ago where a matronly woman named Clara Peller judged hamburgers by the amount of beef she found in them. Often she was disappointed in her quest and shouts “Where’s the Beef?” in frustration. Wendy’s was the chain who came up with the advertising idea and to this day the line has become a catch-phrase for value delivery and customer expectations.

I guess Clara was onto something though. In my experience, business’ often miss the beef when they’re trying to deliver value to their customers—particularly in the software product arena. I don’t know why that is exactly. Sometimes I think the developers are too abstracted from their customers. They can rarely touch or observe them. Or understand their true challenges. So they’re guessing when it comes to needs—then sort of throwing the software “over the wall” for feedback.

Quite often they are under the gun to deliver a smorgasbord of features. Almost as if no one knows what the customer needs, so they shotgun scatter solutions hoping to hit their needs. Fingers crossed. While this may be somewhat successful, it also results in delivering low value features that dilute the focus of the team and increase product development costs.

Wouldn’t it be wonderful if we could focus entirely on “The Beef” in application development? Spending most of our energy focused on delivering high-value and high-need solutions to our customers. Cutting through the clutter of disappointment and ambiguity and simply working on what matters most?

While it sounds like a fairy tale, the agile methods aspire to just this purpose. But it’s not easy to achieve and the effective Agile Project Manager plays a wonderful role in this quest. In this post, I want to share some ideas on how to focus the team towards value delivery.

A Prioritized Backlog!

One of the first mechanisms that drive value is the Product Backlog—the simple prioritized list that drives what agile teams are building. Every team should be laser focused on prioritizing their backlogs in 1..n order. There can’t be three or four priority one features—there can be only one; then two, three, and so on.

Trust me; your customers and stakeholders will want to play infinite games with priority. I’ve seen cases where they have groupings in a spreadsheet that are prioritized and then sub-features broken out within each of them. They’ll insist that they can’t decompose the value out any further as they try to overload priority. This (1a, 1b,..1z) approach allows them to escape true prioritization and selection, also indicating their innate inability to make hard choices regarding what’s truly most important. Don’t let them do that!

An effective product backlog is always in linear and priority order. The team will always deliver the highest priority features first. They will work on them first, finish them first, ensuring the customer is engaged as appropriate.

And since the customer is the final arbiter of priority, they shouldn’t really complain about this approach. It’s just that we’ve historically allowed them to give us large lists of features without making this distinction—so they’ve gotten a bit lazy.

When encouraged (forced) to prioritize, I’ve never seen a stakeholder who couldn’t do it.

Customer-Driven Value

Prioritization can also be driven by perceived value—change that to should be driven. One technique used by many agile teams is the notion of Value Poker. It’s a variation of the popular Planning Poker technique that is used for User Story size estimation. But instead of determining size of stories in story points, we use Value Points as the determinant.

In this case you use a deck of cards labeled from 1-10, one being the lowest value and ten the highest. For each User Story or Theme of stories you ask a group of various customers and stakeholders to ‘vote’ on their view to value of the Story. You take a round-robin approach discussing the ‘why’ behind the highest and lowest values—letting the team express their views towards value nuance.

Once the discussion is over, you re-vote and re-discuss until you narrow the value as much as possible. Sometimes you gain agreement across the team. Sometimes you simply get a range.

You might even compartmentalize values from the different perspectives of the team. For example, the quality and testing folks’ might value a particular story as a five, while the business folks’ value it as a three and development or technology folks’ as a one. All of their valuations provide important data as to how you cross-functionally value the feature.

This logic might be applied to multiple stakeholders as well. For example, the North American stakeholders might value a feature at six, while the EMEA stakeholders think it only a three. In all of these cases, discussing VALUE as a distinct attribute helps the team in prioritizing and in deciding how much fit & finish to apply to individual features.

A Variation

 A truly effective variation on the Value Poker technique is to give every voting or contributing partner a ‘pool’ of funding to spend as part of their voting. So not only are they voting on a value, but they have to invest a portion of a fixed pool of dollars on the feature as well.

Quite often monopoly money or a similar fun equivalent is used for this purpose.  Let’s say everyone gets $5,000 to spend on their features as we play priority poker. In one particular case, a business stakeholder votes a nine for a feature.

In order to emphasize the importance, they put up $1,500 on the feature or about 30% of their available funds. In fact, they only spend their pool against a total of seven features. While they continue to prioritize subsequent features, they’ve clearly communicated their views towards value. In fact, that $1,500 feature ends up being the #1 priority with a total value pool of $12,000 across the entire voting team OR 25% of the available pool.

So here’s an interesting question. If you’re implementing this feature, what does #1 Priority convey vs. #1 Priority AND 25% of the value pool? From my perspective, there’s a large difference. This feature is a much more significant portion of the value and requires particular care in execution. I hope you see the difference.

Minimal Marketable Feature (MMF)

Often in agile teams, singular stories don’t have sufficient mass or impact to effectively be valuated by the customer. Earlier I spoke in terms of a theme of stories. This is a common way of bundling stories together that have value and meaning as a collection. Not only does it help in developing sets of meaningful functionality, but if you prioritize at the thematic level, it simplifies your prioritization. It also has more meaning from the customers’ perspective.

A variation on this theme (pun intended) is the Minimal Marketable Feature or MMF. This concept originates in the Kanban and Lean spaces. Essentially, it’s the same as a theme, but it brings to bear the notion of deliverability, marketability, and overall customer usage.

Quite often an MMF is larger than a theme. It could be equivalent to a user story epic and require several sprints to complete. However, once complete, the team will usually physically deliver the MMF to the customer—for example, pushing it into the production environment.

Tracking Value

One of the wonderful additions to your tool-set as an Agile Project Manager is burning down (or up) the value of stories, themes, or MMFs. You’ll want to setup a burndown chart in a well visited location that burns down team delivered value. As with all burndown charts you’ll want to keep everyone’s eyes on progress and interacting with the team over progress and flow.

You’ll want to calculate total value for a release or project. Then setup your burndown on an iteration-by-iteration basis.

If you’re getting healthy agile behavior within your team, you’ll see value being delivered in a front-loaded fashion. You should also see healthy done-ness and quality attributes as these high-value features are delivered. In fact, I usually expect teams to factor in value as part of their overall quality and testing strategies.

Wrapping Up

Agile Project Managers don’t just care about by-rote execution of tasks or stories. No! Instead they focus their teams on a multi-faceted and nuanced view towards customer, value-driven execution.

Not only are they hoping to deliver value first, but they’re also hoping that by doing so, the customer may achieve a “good enough” view towards incrementally delivered product increments and allow the team to stop the project earlier than planned.

Stopping after delivering the features and functionality that truly matters the most to them. Sort of gaining their value and then moving onto their next highest value-driven project. It’s this sort of value-trimming that can truly make an agile team stand-out from their traditional counterparts and move so much faster.

 Don’t forget to leave your comments below. 

I’d like to begin this post by trying to describe some of the anti-patterns or characteristics of non-transparent work behaviors. This list will probably not be complete, but it should give you a sense of the other side of the fence.

• There are several show-stopping defects in your current code base and you are either not tackling them with your best people or hoping their intermittent nature won’t surface inopportunely before general release. So essentially you are throwing a few bodies at the problem and hoping nobody truly notices.
  
  

If you’re transparent, you must acknowledge and manage quality—being willing to “stop the line” if things aren’t’ right and fix them. This takes courage and commitment.

• Your team is working incessant over-time; making more and more mistakes as they go—daily adding rework and risk to the project on a daily basis. Not everyone on the team seems to think you’ll miss the deadline and nobody in management is willing to “admit defeat”, so all project status reports are still shown as GREEN and the project as “doing fine”.

If you’re transparent, you resist the lack of character & courage to tell the truth about project state for fear of ramification. Instead you routinely tell it “like it is”, and look to make healthy adjustments from “where you are”.

• You began this project three months ago and the business stakeholders were ecstatic when you kicked it off. They even threw a party. But then they “went away” and you haven’t been able to clarify and reconcile numerous requirement questions with them along the way. You’re having your release demo tomorrow and now they all seem to have the time to come and check out the results. The “Great Reveal” is at 3pm and it should prove to be exciting.

If you’re transparent; folks need to be willing & sufficiently engaged to participate and evaluate, in real-time to the good AND the bad of your project state. They need to literally get in the game with you and become involved in moving the project forward— guiding the project towards success.

• You are struggling to deliver the fixed set of features in your latest release. You know which features are at risk, but can’t have the discussion to drop any of the features because the business insists that ALL are 100% required. As a result, you slipped the release date five times and eventually delivered a release with low quality, 14 weeks later than your initial commitment. Oh and did I mention that seven of the most critical features were missing?

If you’re transparent, you acknowledge adversity, look it square in the eye, and make adjustments to your goals. You do so from a position of business value and priority—realizing that everything isn’t equal. You realize that delivering something has great advantage over oscillation.

Now that you have an idea of situations and responses that can be linked to transparency, let’s delve further into more definition.

What is transparency?

From my perspective, it’s the honest and open dialogue about the current state of software development within a project context. There’s no real value in telling you what you want to hear. No providing misleading or hiding information. I have the phrase “It is what it is” running through my brain whenever I think about transparency. What you need to do is show off all the gory details of a project for the world to see, digest and then constructively and realistically react to these details. For example:

• Show your open defect counts and their rate of increase/decrease
• Show your number of sprint escapes or rework that cascades into the next sprint
• Show your project feature-set burndown for the release
• Show your teams’ sprint burndown
• Open the door to your daily stand-up meeting; ask the team not to filter anything as a result of attendee mix
• Open the door to your sprint planning sessions
• Open the door to discussions around what to do about your highest priority feature that is  struggling to see the light of day
• Run a company-wide retrospective for your latest release; taking feedback on all aspects

As an Agile Project Manager, you want to create situations where your progress is simply – transparent in as many situations as you can. There’s the notion of Information Radiators in the agile methods that are intended to serve this purpose. They don’t comment on state as either good vs. bad. They simply radiate it for everyone to see, digest, and react to.

What does transparency create?

Transparency creates congruent conversations which drives congruent actions. Imagine one of your teams having the following burndown chart for an existing sprint and your progress is right in the middle of the “danger zone”, where it’s obvious that “things” aren’t going too well. 

 I’m actually delighted when this happens. And when a stakeholder attends one of our daily stand-up meetings and quietly listens to the discussions. Afterward, they pull me aside at the sprint burndown chart and ask—“We’re not doing so well right now, are we?” And I say “No.” But beyond that, they ask for more information and recommendations for corrective actions—“What do we do now?”

Ah, now that opening leads into all sorts of prime conversational real estate:

• We can and should start looking to jettison content from our sprint goal if possible. No, not the highest priority things, but the lowest. Additionally, can we reframe stories so that we can still hit the goal, with less scope?
• Another point is to get the team engaged in the discussions. In fact, they’re behind in their own commitments for the sprint—so they need to be engaged. What ideas do they have about root cause and corrective adjustments? Can they move work around the team or attack things differently? Do they have any impediments that they want to disclose?
• Does the experience of the team come into play? Is the wrong person attacking this work? And would an assignment change, shifting work around, help us to recover?
• If it’s related to defects, is this an ongoing trend? Is it related to exhaustion or excessive overtime? Does the team lack core, requisite skills? Or domain experience? Or are they simply sloppy in their professionalism?

You see, transparency leads us away from obscurity and into clarity. It’s all about delivering our goals. If there is a risk, our mantra should become – How can we deliver the most value? Short-selling quality should not be an option. Working like dogs is also not an option. Making scope compromises based on early detection and early, mature, and considered reactions to reality is the only option.

Reactions must be made, tightly partnered with your business stakeholders, in a non-confrontational, but truly collaborative fashion. Agile Project Managers must do everything they can to effectively guide their project stakeholders and teams in THAT direction!

Don’t forget to leave your comments below.