Context Considered: Focusing Agile Investments for a Better Return

 Leadership/Team Feedback Loop

Leadership/Team Feedback Loop

Organizations invest a lot of money, time, and energy in Agile. Arguably we’re decades into the Agile game. We should be pretty good with this Agile stuff by now. So why are we not consistently seeing good results? Why do some Agile initiatives fizzle out? Why do some organizations abandon Agile in favor of the next big fad? In other words, why are we not seeing the bang for the buck?

Maybe it’s because we are so caught up in Agile as a idea that we don’t focus our investments on the relevant parts of Agile that matter most. Agile ain’t cheap. So why invest in those parts that don’t matter? The trick is to identify which do.

Agile ain’t cheap. So why invest in those parts that don’t matter?

Agile practices and how they are employed can support many outcomes. That said, some practices are better at supporting specific outcomes than others. For example, a shared team space tends to support the outcome of "we're all on the same team" better than the agile practice of automated testing. It's not that automated testing is a bad thing, it's just that it is not as effective in driving a one-team mindset. On the other hand, automated testing might be generally more effective at driving quality than a shared team space. (Shared team space can go a long way towards improving quality, but it's not as targeted as automated testing.) What I am driving at is that some Agile practices might matter more than others when you consider the context of the outcomes you wish to achieve.

Perhaps even more confusing is that the outcome that matters most to the organization might not be the outcome that matters most to a specific team. For example, the organization might choose improving quality as a goal, but an individual team might choose faster delivery due to a specific market opportunity. You see, context matters. Only when there is an inappropriate misalignment of goals or execution between organization and the team is there dysfunction.

So how do you consider context? Well, first step is to establish a meaningful organizational strategic improvement goal. A meaningful goal should address the greatest opportunity or risk that the organization faces.

agile-fluency-model-v2-simple-portrait-page.png

How do you check goal alignment between the organization and the team? Basically, ask the teams what matters most to them. A tool such as the Agile Fluency Diagnostic™ can generate good conversations about Agile proficiencies and their benefits and which fit best with the team's needs. (The Agile Fluency Diagnostic is a facilitated self-diagnostic that generates insights regarding default team behaviors. If you are interested in learning more about the Agile Fluency Model™ and its companion diagnostic tool, Jim is a licensed Agile Fluency Diagnostic facilitator and would be happy to answer your questions.)

How do your re-align if there is inappropriate misalignment? First, make sure that the misalignment is a problem. Organizational goals and team goals might be justifiably different. Also, the initial goal may be an invalid hypothesis. The key is to establish clear goals, execute, and then assess the impact. Check to see if you achieved the outcome that you wished. Were there unexpected and undesirable outcomes? Inspecting the outcome and adjusting course by revising the hypothesis is a basic tenet of Agile.

By focusing on the Agile practices that fit best with the outcomes that matter most we get better results. Better targeted investments generate better returns. Given that time, money, and capacity are limited, it's wise to be a good Agile investor.

Decouple Release Timing from Sprint Boundaries

Decouple Release Timing from Sprint Boundaries

I'd like to clear up a bit of confusion about the relationship between releases and Sprints in Scrum. When I first came upon Scrum many years ago, I mistakenly thought that the opportunity to release the product coincided with the end of a Sprint — a simple mistake based on my misunderstanding of the rule stating that the Scrum Team delivers a potentially releasable Increment of "Done" product at the end of each Sprint.

My initial interpretation of this rule was that the Product Owner would typically call for a release after a series of Sprints, each of which produced a potentially shippable increment of the product, as represented by the Planning Snowman in the attached drawing. My thinking went that what we today call a minimal viable product, or MVP, would only be realized after some number of Sprints. In other words a release cycle would go something like Sprint, Sprint, Sprint... Release. In the years since, I have frequently seen this same interpretation among the teams that I coach and the students in my workshops.

I was jolted out of my misinterpretation within the first week as Product Owner on my very first Scrum Team. As it happened, a customer, on seeing a rudimentary version of the product during the first Sprint, insisted upon using it. I was aghast.…

Read More

4 Things - Transforming Harley Davidson

4 Things - Transforming Harley Davidson

Today, in reading the Wall Street Journal, I learned of the August 19th death of Vaughn Beals, former CEO and Chairman of Harley-Davidson, Inc. Reading his obituary reminded me that if it wasn’t for Beals and his executive team it’s highly likely that Harley-Davidson would have succumbed to bankruptcy in the 1980s. Instead, Beals famously turned Harley-Davidson around, fending off bankruptcy and creating the Harley-Davidson that we know today.

Read More