A recent article by James Shore and Diana Larsen, Your Path through Agile Fluency: A Brief Guide to Success with Agile, has generated some buzz. I have tremendous respect for the authors, as well as for the people I’ve seen posting positive comments about the piece. To be honest, though, I’m having a lot of difficulty buying into it. I don’t want to offend any of those people. On the other hand, they might just dismiss me as stupid and not be offended at all. Either way, here goes.
The gist of the article appears to be that we can effect organizational improvement in a large company by driving change from the level of individual software development teams. The major problem with that idea, in my opinion, is the bottom-up approach. The authors suggest beginning the organizational transformation initiative from a single software development team and then extending the cultural change outward. They also want to tie together the various parts of the organization by reaching out from the team. I suspect this is because their own professional background is in the area of software development, as well as the fact that both of them have enjoyed a measure of success with the approach, at least up to the second "star." But the approach doesn’t address the core structural problems in companies; it only works around them somewhat.
In most companies software development is carried out by an IT department that operates as a cost center. IT is a support function in the organization. I’m aware of the talk about all businesses now being software businesses, that cars are not cars but rather rolling computers, and so forth. I interpret that sort of thing as more metaphorical than literal. Software is integral to many products and services, but that doesn’t make a company that sells a product or provide a service into a "software" company as such. Software is necessary, but internal software development isn’t. It isn’t necessary that a company carry out its own business software development at all. Software development teams are support groups subject to outsourcing. They aren’t so central to the organization that they can be the core of deep cultural and structural change.
Companies have settled into a conventional organizational structure that separates IT from the rest of the business. This structure exists for historical reasons and not for carefully-considered business reasons. A more pragmatic structure would place strategic IT assets of enterprise scope under the control of the central department while placing business application development and support directly within the business units that need and use the applications. Such applications have no meaning independent of the business activities they support. Therefore, there should be no administrative separation between the people who carry out the activities and the people who provide the software support for those activities. To an extent, the proposal in the article represents a work-around to that problem, but stops short of suggesting that the people who ought to be together actually be put together formally, rather than merely "collaborating" across existing administrative boundaries.
The structural problem won’t be solved by starting inside a single team inside a cost center that executive management thinks about only occasionally and usually regards as an open drain connected to the budget; a team whose manager and whose manager’s boss and whose manager’s boss’ boss are too low on the totem pole to decide anything about anything. Trying to effect organizational change from that starting point seems a fool’s errand.
I know that temporary, local optimizations of team effectiveness are very feasible. I know, too, that sometimes the improvements can bleed over into a larger portion of the organization than the team itself. Sometimes we can influence stakeholders to be proactive and participatory, but we can’t make that the official policy of the company. I do that sort of work myself, and I’ve seen it happen. I also understand that our successes in that arena can lead us to believe or hope that we can drive the positive changes forward in the organization and make them stick forever. But that doesn’t seem to be the pattern.
The real "fix" for most software delivery problems in corporations is to restructure the organization so that the central IT department takes care of strategic assets of enterprise scope, and lines of business take care of their own application needs. That would automatically put "the business" and "the team" in the same lifeboat, plugging the same leaks and kicking the same sharks, working with the same budget and for the same boss, dealing with the same customers, with no need to go through stages of "fluency" over a period of years. The key point is that everyone who ought to work together is actually together; the specific processes and practices they use have less impact than the structure has.
That is not a change that can be effected from within the IT department itself. It has to be driven from the top down, and from a level of management that very few IT-focused consultants ever see. Organizational transformation consultants like John Kotter or Maureen Metcalf would never approach things in the way James and Diana propose, with good reason.
If I’m looking at all this in the wrong way, I’d like to understand how that’s so.
Dave, I don’t think you’re representing their article correctly when you write early on that “the gist of the article appears to be that we can effect organizational improvement in a large company by driving change from the level of individual software development teams”. That’s not what the article says…what it says is that they’ve seen teams *evolve* through the stages through deliberate practice. That’s a lot different approach than “driving change”.
You also write that “The authors suggest beginning the organizational transformation initiative from a single software development team and then extending the cultural change outward.” I can’t find anywhere in the article they suggest that. They never use the phrases “organizational transformation” or “cultural change”. What they do suggest is that through deliberate practice of three- and four-star level principles and behaviors, an organization with four-star teams and organizations might *emerge*. Emergence is a completely different approach than “driving organizational transformation”, and they acknowledge that the journey they’re proposing is really difficult.
There are a lot of people in this industry that are preaching “agile transformation”, and I think that Diana and James are offering a welcome alternative. Choosing the level of fluency you want to achieve and deliberately practicing to get there has a lot more long-term potential than “driving transformation” – from the bottom up or the top down.
Dave,
Much liking the bulk of your opinion here. But I can’t agree with your identification of the “real fix” being structural changes. As you yourself say earlier in the piece, “This structure exists for historical reasons and not for carefully-considered business reasons.” I’d argue the “historical reasons” are in fact manifestations of the historical mindset (a.k.a. the Analytic mindset), dating back to FW Taylor and Max Weber, if not Newton, or even Aristotle.
Structural changes will only come about through a wholesale replacement of the “historical” memeplex with one better suited to effective organisation.
– Bob
Bob,
Thanks for the comment. I’m afraid we don’t disagree after all. (But don’t worry – there will be other opportunities!) The replacement of the historical memeplex sounds like a mechanism to effect structural change. Actually, it sounds like a very good mechanism; certainly more promising than just hoping something good will emerge “somehow, someday.” As usual, the devil is in the details, but that’s another issue.
Cheers,
Dave
Bob/Dave I’m intrigued by the conflict in your positions on this subject, and if you don’t mind, I’d like to unpick it a little further, as I’m very keen to discover ways of achieving the agility within mid-sized organisations (500 to 5000 people) who’s main focus isn’t software development.
My assumption from this very thought provoking discussion is that Dave your assumption is that:
“We can use a mind set shift (based on seeding meme’s into the organisational memeplex) to achieve the structural change we desire.”
and that Bob your assumption is:
“While shifting the organisational mindset (based on seeding meme’s into the organisational memeplex) structural change will occur naturally to achieve the mindset we desire.”.
In either case who is setting the desired state and who initiates the changes? i.e. top down, bottom up, both or neither.
Jeff,
Thanks for offering a thoughtful reading of Jim and Diana’s article. I see your points and I agree that I misinterpreted the article in certain ways. I suspected I might be misinterpreting it at least to an extent, and I was hoping to get some explanatory feedback.
Your statement that there are a lot of people preaching “agile transformation” resonates with me. As I began to read the article, I was getting a feeling of “Oh, no, not again!” Interesting that you found the same article to be “a welcome alternative.” Again and again and again: The assumed centrality of software development at the team level, with positive changes spreading outward from there. You say you don’t see that anywhere in the article; I see it everywhere.
Per a follow-up discussion on Twitter, I learned that they haven’t actually seen teams evolve through all four stages. They’ve definitely seen teams evolve through the first two, and maybe the third at at times. The fourth stage may be more speculative…an attempt to see where the evolutionary path might lead. For that to happen, I think conditions in the organization have to be right for it. It won’t “just happen.” To get the conditions in place, I think we have to do more than focus just at the team level.
Regarding “driving change” vs. “emergent change,” consider the matter from a systems thinking standpoint. We want to see a certain change in the emergent properties of a system. We think that by tweaking certain variables, we will see that change emerge. That is a form of “driving” change, in my view. (Maybe people react to the word “drive” because it sounds a bit command-and-control-ish.) I would be interested to know what the authors see as the mechanism by which the particular changes they propose would lead to the particular outcome they foresee. This is unclear to me at the moment.
Cheers,
Dave
The authors of the article that you mentioned are Agilists, and they do a lot of Agile consultancy, their job is to promote Agile no matter what.
Mind you, Agile is not the same in two different companies – each Agilist has his or her own method – which is another problem.
Agile also has some limitations (although I’m sure that any Agilist will claim that these are not limitations but rather “features”).
PM Hut,
The article on the limitations of agile looks pretty well thought-out. I’m not in complete agreement about the nature of collective ownership, but generally it seems to be a pretty good summary.
On the other hand, one can say that any characteristic of any system is a “feature” of that system. Whether a characteristic is positive or negative depends on context. The same features of “agile” that can be problematic in some situations are ideal for others. It’s good to have this in our toolkit.
Cheers,
Dave
There are many ways to improve an organization’s “productivity”. Stop taking 6 months to decide what to do, for example. A Lean or Kanban approach would quite likely find such an improvement. This improvement would not improve the organization’s agility, and might not improve the lives of the people much at all.
As you know, Agile doesn’t just mean “go fast by any means”. It may not mean going fast at all. It implies embodying a certain set of values, a certain set of principles. For a while organization to be Agile, it would embody those values and principles everywhere.
Agile requires a certain interplay between the organizational elements, largely about controlling scope, selecting for high value, and releasing software frequently.
An insufficiently skilled team cannot write software in such a way that it can be released frequently, and cannot write software in such a way that it is easy to slice apart more valuable bits from less valuable. If they lack this skill, then the business-side people do not get fast enough feedback to enable them to perceive the value of fast release and the value of splitting stories into small bites.
It is possible that they might “believe” these things anyway, although I think it is unlikely, as they’ll try it and try it and the lack of technical skill will make it not work.
In this way, the technical skill to build in the agile fashion is fundamental to Agile’s acceptance.
Ron,
Thanks very much for your comment. I see your points and agree. Thanks, as well, for the insightful comments in the Twitter thread on this subject.
I think maybe where I’m not entirely on board with the article (and other discussions in the community) is the notion of an “agile organization,” given that by definition “agile” relates specifically and exclusively to software development activities, and software development activities in the majority of companies are a support function not central to the business model. I can see how some of the values and principles could be beneficial beyond just that area. What I’m missing is the connecting tissue between applying agile values and principles at the level of a software development team and creating what you might call an “agile organization.”
I think in principle the idea of an “agile organization” is compatible with ideas from other schools of thought, much as you express with your same elephant metaphor. As Ross Perot used to say, the devil is in the details. Is there a practical, direct path from agile-at-the-team-level to “agile organization?” None is presented, AFAIK. Or is it that agile development teams would be a natural fit with an organization that succeeded in replacing the “historical memeplex” (see Bob Marshall’s comment above)? Which direction(s) of improvement is(are) more likely to result in desirable outcomes, and what would the mechanism(s) of such a transformation look like?
I’m still not sure. I think it’s a question worth exploring, though.
Cheers,
Dave
Thanks for your thoughtful post, Dave. I’m putting together a blog entry in response.
I do want to address your comment above right away: “Per a follow-up discussion on Twitter, I learned that they haven’t actually seen teams evolve through all four stages. They’ve definitely seen teams evolve through the first two, and maybe the third at at times.”
That conversation wasn’t with me, and I don’t see anything in Diana’s feed. I feel like you’re putting words in our mouths, or attributing someone else’s comments to us. This bothers me. Can you clarify?
Thanks,
Jim
Jim,
Right, the exchange on Twitter wasn’t with you, and I hesitated before mentioning it for that reason. No offense intended. I think it was Ron who suggested the model you described might have been more speculative, but that in itself would have been speculation, too.
Dave
I’ve responded to Dave’s critique here: http://jamesshore.com/Blog/Lack-of-Fluency.html
Jim,
Thanks for writing that. For me, it clarifies matters very well. I think we’re actually on the same page.
Cheers,
Dave
[…] stages, each with its own benefits, costs of adoption, and key metrics”. Dave Nicolette responded that “the gist of the article appears to be that we can effect organizational improvement in […]