"Enterprise Scrum"

Rather than just bookmark the links, I thought I’d call out a few interesting threads around “Enterprise Agile,” or, in this case, Scrum. In the past year or so, as large companies have adopted Scrum and other Agile techniques, there’s been some adaptation on both sides. The chief notion, as new people pick up the practices and ideas is to somehow prefix the word “Enterprise” in front of “Agile” or one of it’s implementations, like Scrum.

There are some interesting posts about the tension around this in scrumdevelopment:

• From Ken Schwaber, on the topic of BigCo people like Microsoft and IBM “taking Scrum to the next level”:
  

  I knew that there would be those who would not get Agile and Scrum.
  However this type of marketing and facile representation of what we do
  is very disappointing. Yet, watch for more of the same as IBM (with
  their recent donation of parts of RUP and documentation of Scrum) gets
  into this through the Eclipse foundation and Microsoft gets into this
  with VSTS. One has to wonder at the mismatch between large,
  hierarchical, command and control organizations providing guidance on
  Agile.

• And this recent thread on “enterprise scrum”, Ken again:
  

  If the people at Microsoft that are using Scrum to build product contributed, I’d be delighted. If the process people at Microsoft get piling on to Scrum to prove their importance, I’ll continue to regard it as irrelevant but potentially disruptive.

The Checked out Enterprise

In a seemingly unrelated post the other day, Anne charted out some reasons why Web 2.0 won’t be an easy fit in the Enterprise. In essence, I think she captured in a much more concise way the “problems” I was trying to get at in my last Agile-related post. In summary:

• Most enterprises are top-down by design and desire.
• You get power in most enterprises by withholding information and using it when it most profits you.
• Specialization at the person, not role, level is norm in most enterprises, and new specialization rarely “win.”

As Ed Daniel pointed out in a post on agilemanagement about the Dysfunctional Agile post, I’m more interested in the “transformation to agility and the issues around that in relation to entrenched legacy models that are looking at being transitioned focused on large orgs” than the “happy-path” discussions of Agile. I think Anne’s line of thinking provides a high-level outline of the causes of those “issues.”

Now, the two questions are:

1. What scope do we need to draw around the application of Agile in large organizations? How far into the rest of the organization do we need to worry about? Put another way, how leaky is Agile outside of development?
2. For whatever vertical and horizontal depth the first question asks, what is the current state of practice and what works for changing it to Agile’s favor?

To my mind, the chief problem hinges off the specialization problem. Due to specialization, very few people are allowed, or want to think that they have responsibility for the entire project: delivering and, implicitly, making sure the software sells and brings profit to the organization and, thus, each person.

So much in Agile-think hinges off every person involved “checking in,” being open, up-front, and TCB‘ing without being told to. In my mind, large organizations are anathema to “checking in.” I don’t think the problem is intractable, but I certainly think that there’s plenty of tools yet to be documented for going up against the checked-out enterprise.

(As a side-note, check out the huge jump in messages on agilemanagement: from the 50-100 range for most of 06, to 372 in Aug. 06.)

Update: right after posting this, I came across this post from Gary Pollice on process in software development. In it, he outlines many of the goals and purposes for process in large organizations. That exploration of the simple question “why?” is great.

Disclaimer: IBM is a client.

Tags: change, enterprise, ibm, msft, peopleware, scrum