There’s something I started to notice around 2011, but didn’t quite understand until recently. Now I think I have a handle on it.
From time to time I hear agile coaches describe a particular client company as a place where agile thinking never penetrates, or where agile methods are never properly adopted. It seems as if most of the larger markets have at least one such company or governmental organization.
One (that I know of) is known in its local market as “the place where agile goes to die.” Coaches in other markets have been less poetical in their descriptions, but many of them are aware of at least one client company that has a similar local reputation.
Many larger organizations are considering adopting an Agile scaling framework to help them extend contemporary practices beyond the proof-of-concept stage. Plenty of people stand ready to help them choose an appropriate framework. Or maybe it’s more accurate to say, to help them choose the framework the helper wants them to choose.
I put together a short ebook that addresses the problem of choosing a framework from the point of view of someone who has no product to sell and doesn’t care whether you use a framework at all. Maybe it will help you and maybe it won’t, but either way it’s cheap, and it doesn’t try to sell you anything. See https://leanpub.com/choosing-an-agile-scaling-framework.
The bad news for a smart-alecky blogger is that it’s getting harder to find examples of companies that handle their IT function foolishly. But that’s good news for the IT industry!
Submitted for your consideration: The simplest way to solve a problem is not to solve it at all, but to define it out of existence. Many of the challenges we face in corporate IT may be caused by traditional organizational structure. If it is true that structure begets function, then we may be able to define some of these challenges out of existence by changing the organizational structure.
Premise: Agile principles depend on biologically hard-wired limits on the effective size of collaborative human groups. For this reason, agile methods as such do not scale to “enterprise” levels.
It’s a commonplace that large organizations tend to be stodgy and bureaucratic, and smaller ones tend to be innovative and flexible. When we see a large organization that seems to be innovative and flexible, we are amazed. The press springs into action to report on the existence of this Highly Unusual Thing. It’s an oddity, a curiosity, an anomaly, a freak of nature. The organization is cited as a case study in business books and academic papers. Executives in other companies try to mimic what they think they see the exemplary company doing.
Having participated in various change initiatives in organizations of all sizes (from around 20 people to around 240,000), it strikes me that size alone does not lead to stodginess. I think there’s something more fundamental: Identity. That is, the sense of identity on the part of the individual members of the organization. Do people feel like members of the same organization, all aiming for the same goals, or do they feel like members of a local tribe: Team, work group, department, division, etc.? As an organization grows, what factors might contribute to one sense of identity versus the other?
Most people who do coaching work in the IT space focus on one of three areas: (a) technical practices, (b) process improvement, and (c) organizational dynamics or “human factors.” It’s not unusual for a person to have skills in both process improvement and organizational dynamics. It is rare for the same person to work at both the level of technical practices and the level of process improvement, and even more rare for that person to be engaged for both purposes at the same time.
I’ve observed a sort of disconnection between process improvement initiatives at the organizational level and improvements in technical practices at the team level. I don’t know if the reason for this is, in part, the separation, first in formal education in universities and technical schools, and later in coaching, consulting, and training services, between technical practices on the one hand and process improvement and organizational dynamics on the other. Whatever the cause or causes, the situation appears to be that improvements in technical practices and improvements in process are treated as separate and disconnected issues.
I think the two are connected. Technical debt is more than merely an annoyance for maintenance programmers who have to deal with a challenging code base. A mass of tightly-coupled code can make it very difficult, time-consuming, and expensive to implement general improvements.