Organizational Learning Always Precedes Agile Maturity

I’ve become increasingly convinced that a lack of learning is one of the largest inhibitors of agile transformation results.  One can argue that we are at, or nearing, the end of the knowledge era.  Knowledge is ubiquitous.  Simple possession of knowledge is not sufficient for either the individual or the organization.  Today’s rapidly changing business climate requires the coalescing of knowledge and experience into rapid learning that can be applied to problems and opportunities we can leverage for business value—quickly.

The amplification of learning is a key principle in lean and agile methods.  However, this is where traditional organizations making the switch to agile can very easily get in their own way if they’re not deliberate with their intentions.  Some of the best learning is obtained through failure.  For example, Thomas Edison failed several thousand times while attempting to find the correct material to create a filament for his incandescent bulb.  That means he learned several thousand ways of incorrectly creating an incandescent light bulb.  Large organizations strive to improve profitability and success through minimizing risk, which often results in a palpable fear of failure.  This fear can metastasize in an organization and impede learning and innovation.

So, how does this apply to agile transformations?  I’m sure everyone reading this blog has either read or heard someone say, “agile is not something you do; it’s something you are—a state of being.”  While I believe that’s true, it’s also a new way of working, one that comes with risk and inherently challenges the status quo.  Very frequently I sense an attitude in organizations that agile is “something the developers do” or “a new process that is being adopted in IT.”  The problem with this naïve thinking is that it will ultimately erode the results an organization might obtain, and frequently leads to failed agile initiatives.

For maximum impact and long-lasting results, agile should be embraced throughout the entire value stream.  This means from front-end customer contact (through Sales, Marketing, and Product Management organizations) all the way to the back-end of the value stream (IT operations and post-production support).  To do this requires a fundamental shift in how organizations are structured and operated.  It doesn’t have to happen all at once, but it does have to happen on a larger scale than the team level.  In fact, perhaps we should favor the scaling of agile values over the scaling of agile processes and practices.  Rather than, or perhaps before, asking how we can scale agile to the enterprise level, we should be exploring how we can scale agile thinking to the enterprise level.  Remember, individuals and interactions over processes and tools?

On the individual level, team members are sent to agile courses and are expected to deliver twice as much in half the time with a quarter of the budget.  Yet, when the course ends they are thrust back into an environment that has been structured to minimize risk and optimize predictability through rigid processes, massive reporting hierarchies, and unwieldy governance.  People tend to take the path of least resistance.  Therefore, especially when the pressure is on, they will do what’s necessary to get their jobs done.  Unfortunately, this often means working in the same manner they have always worked (status quo).

I think many of us can identify with these issues in some fashion.  It’s easy to become complacent, apathetic, and complain.  We see the problems around us.  But, what exactly can we do about it?  How can we, as individuals, impact change on a larger scale?  First, it’s important to understand that agile methods are exceptional at illuminating dysfunction.  I’ve heard individuals say, “how can we possibly deliver a working and fully-tested feature in two weeks?”  My response is typically, “working the way you currently are, you probably can’t.”  Expecting a major improvement in delivery without simultaneously experiencing disruption is unrealistic.  When organizations and teams begin implementing agile they will undoubtedly experience issues and frustration.  They will also make mistakes; this is learning.

The important thing to focus on is minimizing the probability that the same mistake will be made twice.  Too often the callous finger of blame is pointed at agile as either not being applicable (it just doesn’t work in our situation) or as the root cause of the issues.  We need to help our organizations understand that agile is not the root cause of many of these problems.  Make your first question, “What about this situation might be giving us pain?”  You will often find that you are clinging to practices that are grounded in traditional thinking but that run counter to the 12 agile principles outlined in the agile manifesto.  Challenge your teams to discover why they are having issues.  Retrospectives provide an excellent avenue to amplify learning.  And don’t be afraid to actually try something.  Learning is a verb; you must act on knowledge gained to realize improvement.

To help our organizations improve we need to conduct retrospectives at many levels within the enterprise, not simply at the team level.  To amplify learning we must help everyone, including the wider organization, become reflective.  Retrospectives can be applied to every level throughout the organization, especially at the leadership level as the organizational hierarchy plays a major role in enabling success.  If you’re a leader (and everyone certainly can be if they choose to be) and you’re not performing the actual front-line work of creating products and/or services that your customers consume, remind yourself often that you DO NOT deliver value.  Rather, you are a primary enabler of value delivery.  Help keep the organizational machinery well-oiled and finely tuned.

Finally, take personal responsibility for helping your organization learn and grow.  Use your network to help you do this.  In one organization I worked with I created a monthly forum where well-known agile thought leaders were invited in to present new ideas to the organization on a wide range of topics.  I did this as a hosted web conference that was recorded and archived for those unable to join live.  Providing this access to thought leadership was inexpensive and helped others immensely.  It also helped the presenters by providing additional exposure and even gained a few of them business engagements at the company.  Don’t be shy in reaching out to these individuals as most are approachable, personable, and eager to help.  You simply need to ask.

Try some of these practices to help your organization increase agile maturity.  Become a thought leader yourself and strive to learn all that you can.  But don’t stop there.  Propagate your learning to others.  You don’t need to do this through formal classes.  It can be done in simple hallway conversations and daily interactions.  Organizational learning is the aggregate of the actualized knowledge of every individual within the organization.  In its absence agile maturity will stagnate.

This entry was posted in Agile Adoption, Agile Coaching, Agile Management, Agile Methodologies, Scaling Agile. Bookmark the permalink.

One Response to Organizational Learning Always Precedes Agile Maturity

  1. Cesar Brod says:

    Brian, what an excellent article! Would you mind if I translate it into Brazilian Portuguese and publish it in my blog http://dicas-l.com.br/brod ? Of course I will reference both your article and VersionOne. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>