The Agile Journey Begins – or Ends – Depending on your Culture

 After the Webinar – More Insights from the DevOps Experts, part 1

We recently conducted a webinar called Dev Ops in the Enterprise with Forrester Principal Analyst Kurt Bittner, Gene Kim, co-author of “The Phoenix Project and CollabNet’s own Laurence Sweeny.

The audience engagement was fantastic and we received many insightful questions from our listeners. Here are a few I hand-picked from the audience for Kurt Bittner around: The Agile Journey Begins – or Ends – Depending on your Culture.

Doug: What are some best practices in measuring/surveying the current culture?

Kurt:  Agile practices require cross-functional teams. An organization that has very strong role silos and strong role sub-cultures will struggle with Agile.

Agile works best with flat organizations with a servant-leader management culture.  Organizations with a strongly hierarchical, top-down culture will also struggle with Agile.

Agile also works best when there is transparency and cooperation between the business and the application delivery organization.  Organizations with an adversarial or contractual relationship between business and IT will struggle with agile. Contractual relationships are characterized by the need for contracts and signoffs to record commitments, especially where those contracts are used to transfer risk or to establish an audit trail for denial of responsibility.

Agile requires a learning culture, one able to learn from missteps or mistakes. A culture of blame that punishes failure and largely deals with it by searching for the responsible party and then punishing them will create a culture of fear that is extremely risk averse and unwilling to do anything with an uncertain outcome.  Since most outcomes are uncertain these organizations get very little done beyond the status quo.

Doug: How does one obtain the proper buy-in on necessary changes?

Kurt: There must be a recognition at the top of the organization that the traditional approach is not working, and an imperative need to change.  Leadership must create an environment in which innovation and learning are valued and rewarded. The focus must shift from protecting and rewarding the status quo to seeking out opportunities to improve, and rewarding results. The organization must be willing to break down existing silos and to dismantle the siloed fiefdoms that often permeate traditional organizations.

In addition, obstacles must be removed from Agile teams.  Operations should be streamlined so that appropriate development and test environments are available whenever they are needed.  Teams need appropriate tools right from the start as well – IDEs, SCM, continuous integration, and test automation. They need to be able to develop and test from the first day.

There is also a natural shift in focus from projects, temporary entities that have a defined start and end, to products that are funded and staffed as long-term initiatives. This also means that resources tend to be dedicated and not shared between initiatives.

Finally, the business needs to be fully engaged. They need to stop thinking of their involvement in developing applications as a part-time side project but a full-time commitment. The initiative needs to be important enough to the business for them to fully commit to being involved.

Doug: What are some lessons learned from implementing changes?

Kurt: Having environments available early in the project is really important. Standardizing environment configurations and being able to provision them on demand (sometimes called infrastructure as code) is very important for having those environments available quickly and eliminating hard to diagnose defects that emerge from mismatches in configurations between dev, test and prod (the classic “it works fine on my machine” bugs). Continuous integration is also a key enabler. Reducing batch size and branch duration is also key.

Engaging with the business is key; they need to be active participants, not engaged at “arms length” as they have been in the past. In some organizations the relationship between business and IT is so bad that this is going to be a challenge.  The only real answer to this is evidence of improved delivery.

Lots of organizations fall into the “training trap”. They announce that “agile is the way” with great fanfare and even, in some cases, beautiful posters and “Agile newsletters”. They then send everyone to a training class, perhaps one resulting in becoming a certified Scrum master. They track how many people have taken the training and passed the test, and that’s about it.  Training can establish a baseline understanding but it doesn’t usually achieve anything.  People have to learn by doing.  They have to be allowed to try and fail and learn. They need to be shown new ways of working by people who have already been through it.

Governance models reinforce behavior. If you measure projects using a schedule-driven set of milestones, the project will revert to a waterfall approach. You have to measure progress in terms of business value delivered in order to change behavior.

Architecture matters.  If the application is a traditional legacy system “mud ball of code”, with tight coupling and poor modularity, it will be very hard to deliver in small increments.  Not impossible, but very hard.  Agile works better with mobile and cloud applications because the architectures of those applications tend to be loosely coupled.  Loose coupling allows different parts of the application to change independently, allowing for faster delivery.

Doug: How does one get past the mentality of “There isn’t time to change how we do things, since we are already behind and the customers want us to move forward”?

Kurt: The Japanese poet Ryokan said “If you want to find meaning, stop chasing so many things.” The first thing you need to do is to reduce WIP.  Most of that WIP is probably waste right now anyway.  If you reduce the batch size, limiting the amount you are doing in parallel, you can then focus on trying to improve.  The reduction in waste caused by too much WIP will give you the time and resources  you need to get better.  The challenge is recognizing, and getting the business to recognize, that a lot of what you are doing now is just waste.  As once manager with whom I used to work wisely said, sometimes you need to go slow (at first) to go faster.

What type of Agile culture does your organization have?  

Follow me on Twitter @dribback, @collabnet