Lack of fluency
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.