This post originated from an RSS feed registered with Java Buzz
by Michael Cote.
Original Post: PeopleOverProcess.com: "Enterprise Scrum"
Feed Title: Cote's Weblog: Coding, Austin, etc.
Feed URL: https://cote.io/feed/
Feed Description: Using Java to get to the ideal state.
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.
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.
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."
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.
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.
Previous Topic
