Uncharted Waters

Aug 11 2014   10:28AM GMT

Introducing the SCARE Method

Matt Heusser Matt Heusser Profile: Matt Heusser

Tags:
Agile

HerosAt Agile2014, yes, I gave two talks and helped select others; I organized tester dinner and came to Adam Yuret’s LeanCoffee as often as I could.

But the most powerful new idea I had might just have been a five minute lightning talk on the SCARE Method.

Introducing SCARE – And A Little Regret

SCARE stands for Sustainable, Cultural Agile Release for the Enterprise. The title positions SCARE in opposition to SAFe, the Scaled Agile Framework, and as a bit of a joke, which I regret. SCARE is not a joke; it is some of the best work of my career, a collection of patterns that I have implemented, seen work, and discussed with peers with similar experiences.

Of all the things I discussed at Agile2014, SCARE is probably the most powerful. Defining it in opposition to something else was probably a mistake.

Then again, that got 16 votes and got the idea on the lightning talk track. So there’s that.

But … what is it?

Scare works like this: Start by trying to build one single high-functioning, multidisciplinary team. On that team there will be no heavy-handoffs, no multi-projecting, no heavyweight process, no excess work in progress. That team is going to be able to execute.

The Project HeartbeatWhere do we start? On your most critical project. That system conversion, the new product, the next version. Within that project we find the heartbeat – the group that is constraining flow. Every day the core team is late, the whole project is a day late. Every day the project is late the company experiences a cost of delay from not shipping its most critical project and slows down the next project. This creates a ripple effect where a ten-person-day delay costs hundreds or thousands of person-days of effort.

Let’s be honest about that “team.” Finding that heartbeat as a consultant isn’t usually too hard: they know who they are. They are in different floors,  different buildings or areas, but the developers have the operations and business analysts phone numbers on speed-dial. They are checking in with each other at lunch.  When we offer to get them in one room and let them execute, they’ll breathe a sign of relief and make a comment about Sound Craftspeople.

Getting them all in one room using modern methods will offer thousands of percentage points of improvement for the project. Better than ROI numbers, we’ll actually get the project done. When the project is done, we’re done – we added double-digit organizational throughput for pennies on the dollar. We keep the team around, not releasing them to the winds to be assigned as “resources” to other “projects.” Instead we let that team pursue the next project as a team.

If we want more, we can take volunteers to build the next high-functioning project team. The old organizational structure stays in place, at least for a while, as traditional teams take on roles that are increasingly based on Maintenance, Ongoing Operations and Support Engineering, or MOOSE – roles where traditional, waterfall-like approaches can succeed.

That’s it.

This is sustainable because it iterates until it hits resistance, but teams continue even after the laggards refuse to “go agile.” It is cultural because we do a bit at a time, earn our success, and take volunteers. It releases agile into the wild, and has worked with companies with billions in annual sales.

It is also a method of Agile Adoption based on actual experience, that works a bit at a time (reducing risk) and can be customized for the context (not cookie-cutter!) and respects the way people want to work.

In other words, it is Agile.

I know, crazy.

Let’s talk about it.

1  Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Lisacrispin
    We've known a long time that what makes a project successful is getting some good people on it. 

    I would hesitate to use the term 'high-functioning team' because no new team is going to start out that way. IME if you focus on being "high-functioning' or 'hyper-productive' you won't make the necessary investment of time, training and permission to fail. Focus instead on producing the highest quality you possibly can at this time. Then everything else will come - but not quickly! Not fast! It will take years to build a truly 'high-functioning' team.
    50 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: