Is Your Oven The Right Temperature?

A large number of organizations attempt to to have their software developments go “Agile” for a variety of reasons.  The sheer number of discussions in Agile discussion groups is a reflection of this craze. Many of these attempts fail and fail miserably.

A careful read of the Agile Manifesto makes it clear (to me) that the signatories anticipated a certain type of environment  for Agile software development to thrive in.  Consider the following principles:

  • Principle 4: Business people and developers must work together daily throughout the project.
  • Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Each principle implies a lot about the type of ecosystem in which Agile software development has a chance of being successful. Many organizations that are trying to do or be Agile are only aware of a set of codified practices and are oblivous to the principles that I just mentioned.  Unfortunately, the Agile manifesto itself doesn’t explicitly address the ecosystem needed for Agile to have a chance of being successful.  Organizations that are interested in Agile software development need to actually look to other sources for information on how to cultivate such an environment. Sources such as Argyris, Deming, Drucker, Weinberg, Ackoff, Senge, Hackman, Pink, Mintzberg (to list a few) are a great place to start for anyone who is interested. If you are a manager and most of these names are not familar to you, I would strongly suggest that you look them up.  In fact, if you get nothing else out of this post, I hope you just start a reading list.

The fact, however, is that many (if not most) large organizations have systemic structures (politics, hierarchy, funding models, appraisal systems, control systems etc etc) in place that are at odds with the structures needed for Agile software development to actually succeed.  Several thought leaders in the Agile space have largely given up on “the large organization” and have suggested that it’s waste of human potential trying to create the conditions for Agile to succeed in such environments.  Others have fused other methods such as Lean Thinking and Theory of Constraints to create a more holistic approach.  I’ve especially found the work of Bob Marshall (@flowchainsensei) and Rightshifting to be particular motivating for me in this regard.  Let’s take a look at few examples of organizational structures typically found in the large organization and the challenges they present to Agile.

Political Structures

The larger an organization, the more of an influencer “politics” is.  People protect their territory (which often includes other people) at the expense of the overall good of the organization.  Transparency is lost as a result of folks continually manuvering. Alliances form beind the scenes and nothing gets done.   In a highly political charged environment, Agile will struggle.

Funding Structures

If your organizations sees technology as an auxillary function (a cost center) that provides utility services then technology will be funded in a such a way.  Very often that funding leads to the execution of projects.  I’ve written in the past about projects and products so I won’t rehash that here.  But, in a nutshell, if your organization delivers projects, it may be challenging (or impossible) for your organization to be Agile.  (I realize that the manifesto uses the word, project. Don’t let that mislead you.)  On the other hand, if your organization sees technology as a strategic lever with the understanding that product development is primarily an exercise in discovery, then Agile may work for you as you’ll find that you work be doing projects.

Accounting Structures

This is related to the previous structure but it still warrants being called out explicitly.  Cost accounting or throughput accounting?  Your accounting structure can impact your ability to truly work in a Agile way. What accounting structures do you have in place?

Hierarchical Structures

Traditional organizational structures are largely Taylorist in nature. Managers (and this includes all titles involved in the management) are brought in to ensure that people (very well educated and compensated people mind you) are doing the right things.  I’ve also written about this recently and so I won’t repeat what I said.  I’m saddened by how many managers are unaware of the role of the manager in an organization.  Your organization will struggle with Agile if the organizations view on hierarchy and management remains Tayloristic.  If you don’t plan on making a true commitment to enable self-directed teams (see Hackman and Kimball) and network-based structures, then Agile is probably not for you.

Decision Making Structures

Heavily centralized or heavily decentralized ? What is prevalent in your organization? Do people have to run everything up the chain of command for approval before they can actually do their jobs?  Is information centralized in a “special few” (think Director of Agile Coaching) roles in the organization and nothing happens if they are not involved?  Is leadership at all levels promoted or does your organization just pay lip service to such an idea.  Are ideas valuable based on the title of the individual who came up with the idea or are all ideas considered equally?  If your organization doesn’t make a concerted effort to push information out to as many people as is possible to enable quick decision making, Agile may not be for you.

It has been said that “culture eats strategy for breakfast”.   A study of the Toyota Production System reveals how important the culture of an organization is.  I believe the same to be true for any organization interested in the Agile thing. Having teams try to do it on their own is (a) a local optimization and (b) not Agile.  An organization interested in Agile (and continuous improvement in general) needs to make a commitment to changing it’s existing structures if it realizes that its structures impede its ability to “do Agile”.

Your can have the perfect cake batter, but if you don’t bake your cake at the right temperature, you won’t have a cake.  Is your oven (organization) at the right temperature?  If no, what are you doing about it?  Can you do anything about it? Better yet, should you do anything about it?


About Ebenezer

culture hack. contrarian. change artiste. speaker. writer. silo-connector. entrepreneur. totally human. ff at your own risk. :-)
This entry was posted in Organizational Learning, Software Development and tagged , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s