Tag Archives: Agile Culture

Enterprise-level Agile Implementation

I was recently asked to help a consulting firm who is working with a client having trouble with a very large enterprise-level Agile implementation.  It seems that the company had gone head-over-heels into Agile across the whole company and the senior executives were unhappy with the way it was going.  Many projects were going off track and senior management didn’t feel like they had much visibility and predictability to see if all the development efforts were really well-aligned with the company’s business strategy.  I think this is a typical problem that many companies face for large-scale, enterprise-level Agile implementations.

The problem is that large companies typically have some kind of management infrastructure such as a PMO  for managing projects as well as some kind of project portfolio management approach to align projects with the company’s business strategy and that existing management infrastructure probably isn’t totally compatible with an Agile development approach.  The choices are:

  1. Dismantle the existing management infrastructure and simply implement Agile at a development team level with no guiding management infrastructure.  That typically results in problems  such as projects going out of control and not being well-aligned with the company’s business strategy.
  2. Implement a new top-to-bottom Agile management approach such as the Scaled Agile Framework.  This is a good solution but requires a major redefinition of the company’s management infrastructure and some companies are just not ready to make that kind of gut-wrenching change.
  3. Implement a “bridge” between the existing management infrastructure and the Agile development approach using a hybrid management approach overlaid on top of the Agile development process.

The most important point is that you can’t ignore the need for these higher levels of management and implement Agile as a development process without defining some way that it integrates with the company’s overall business strategy. The choices look something like this:

Enterprise Level Agiie Business Strategy

This can be a difficult thing to do because standard Agile methodologies such as Scrum do not provide much guidance above the development team level and there are a number of choices at each of these levels.  At each level, there is a choice of implementing a more Agile or a more traditional, plan-driven management approach.  It is somewhat like a chess game as shown in the diagram below:

Enterprise Agile 2

Here’s how I would position some of the frameworks for filling this need:

Enterprise Agile 3

The three frameworks shown above are:

  1. My own Managed Agile Development model
  2. Scott Ambler’s Disciplined Agile Delivery model
  3. Dean Leffingwell’s Scaled Agile Framework (SAFe)



Developing an Agile Company Culture

Developing an Agile company culture can be a major obstacle to successfully implementing an Agile development approach; however, it doesn’t have to be that difficult. Some people make the mistake of thinking that you have to change the entire culture of a company in order to adopt an Agile development approach. I don’t believe that is either necessary or appropriate in many cases; a company’s culture should be designed around whatever business they are in and that may or may not be well-aligned with implementing an Agile development approach. See my previous blog post on “Agile and Corporate Culture” for more discussion on this:


Agile works best in companies that are in the business of developing products or where software product development is somehow very directly related to their primary business. In other companies where the relationship is more indirect, it can be much more difficult to implement an Agile development approach because it may not be as well-aligned with the company’s primary business objectives. An example is Walmart…Walmart’s primary business is driven by reducing costs. I’m sure that software development plays some role in that but it is much more indirect than a company like Amazon.com whose business is very directly leveraged by software development. It should be very easy for a company like Amazon.com to implement an Agile development approach and far more difficult for a company like Walmart to do the same thing.

The key point is that since Walmart’s primary business is through conventional brick-and-mortar retail stores, they have to develop a culture that is well-aligned with squeezing costs out of every area of their operations and managing a large number of retail stores very efficiently and effectively. Those are the primary drivers of their business and that may not align very well with an Agile development approach. If you were to set out to implement an Agile development process inside of a company like Walmart, would you try to get them to give up their entire corporate culture and adopt a different corporate culture that is more suitable for hosting an Agile development process? I don’t think so, but there are some fundamental aspects of any company’s culture that can be dysfunctional are most critical to adopting an Agile development approach. Here are a few of what I think are the most important factors:

  • Transparency and Trust – In many large corporations, there is somewhat of a contractual relationship between the business users and the people who deliver Information Technology solutions. The business users may be under intense pressure to reduce costs and want to get firm commitments from the solution providers on the costs and schedules of projects. That is one of the major factors that has can be a big obstacle to implementing an Agile development approach – sometimes it even creates somewhat of an adversarial relationship between the two organizations. The key to getting past that obstacle is:
    1. Companies need to realize that this is not an “all-or-nothing” proposition to totally give up all control of projects to become Agile. There are many ways to blend traditional project management principles and practices with Agile principles and practices to develop the right balance of agility and control. See my blog post on a Hybrid Agile framework here:http://managedagile.wordpress.com/2013/07/22/a-hybrid-agile-development-framework/
    2. Developing a spirit of trust, partnership, and collaboration between the two organizations can require some strong executive-level leadership to break down some of the traditional barriers that exist inside of companies. The strongest driving force for making that happen is that it requires a more collaborative partnership approach to focus on rapid innovation.
  • Focus on Continuous Improvement and Innovation – A focus on process improvement and continuous innovation is certainly not new to Agile. It has been around a long time and many companies have successfully adopted continuous improvement approaches based on Six Sigma and other methodologies. I published my first book in that area called “From Quality to Business Excellence” in 2003. What I found was that in the companies that did Six Sigma well, it may not even be noticeable that it was Six Sigma. They may not have a lot of the hoopla like black belts and green belts that are normally associated with Six Sigma and it was so deeply engrained into the way the company did business, that it may not even have been called Six Sigma.The companies that did it well took a systems thinking approach to adapt it to their business while the more superficial companies simply did it mechanically “by the book” and treated it as just another “Program du jour”. I think a similar thing is happening today with Agile. Companies who take the time and effort to understand Agile at a deeper level and adapt it to their business are probably more likely to do it successfully.
  • Respect for People and Self-organizing Teams – This principle is also not new to Agile. It was a key element of Dr. Deming’s principles that form the basis of the Total Quality Management (TQM) approach and I can remember a strong focus on this when I worked at Motorola in the early 1990’s. It’s another thing like Six Sigma that some companies forget about when the pressure gets intense to deliver business results. They sometimes take a superficial, brute-force approach to try to drive business results rather than taking a systems-thinking approach to understanding the factors that drive business results and the role that people play in achieving those goals.

If you only focus on those three things about a company’s culture, I think you will have a pretty good foundation for implementing an Agile development approach and those three things are somewhat common to all companies regardless of what business they’re in.

By the way, here’s an interesting footnote to this article: Walmart has recognized the importance of e-commerce to their business and has formed a new division called “Walmart Labs” to address that challenge. Here’s an interesting article on that topic:


Agile Product Backlog Grooming “Iceberg”

An understanding of the Agile Product Backlog Grooming “Iceberg” is important. A typical Agile approach of Product Backlog grooming is sometimes focused primarily on limiting the backlog to only about 2-3 sprints ahead and doing grooming only as needed to get stories ready for development. That is a big difference between a “pure” Agile approach and more of a hybrid approach that blends an Agile development approach within a somewhat plan-driven envelope. If your project can be totally adaptive and doesn’t require a plan, you can probably live with that approach and completely define the Product Backlog “on the fly” as the project progresses. However, in many situations (particularly in large enterprise-level projects), there is a need to have a plan (either at the release level or project level) for the project. It’s very difficult, if not impossible, to limit the backlog too much and also be able to have some kind of plan of where the project is going.

For that kind of environment, I like the idea of thinking of the Product Backlog as an “iceberg” as shown in the diagram below (I believe this iceberg Idea was originally created by Mike Cohn):

Product Backlot Grooming Iceberg

The “iceberg” idea is that as you pull items off of the top of the iceberg, other stories that are at lower levels in the iceberg move up to take their place. The process of developing stories and moving them up the iceberg goes on continuously to feed the development process. A Kanban process with different stages of definition for stories fits this process very well. (Thank you to Michael Hurst for suggesting that) Here are a couple of suggested guidelines for this process:

  • You never want the development team waiting for stories to go into development. The number of stories that are fully groomed and ready to go into development should always be far enough in advance to keep the queue from going empty and to prevent developers becoming idle waiting for stories to develop.
  • There are logical stages that the grooming process for the rest of the backlog goes through and those stages should align with whatever planning objectives you need to meet. For example, if there is a need for release-level planning or project-level planning to forecast a plan and an estimated schedule, the Backlog needs to be sufficiently-defined and defined far-enough in advance to support that objective.
  • Product Backlog grooming can be a very time-consuming process and the time for grooming of what’s coming next needs to be built into the current sprint or it may not get done in time to keep up with the development effort.
  • Using people on the team efficiently to do backlog grooming can be a challenge. The developers who are going to take responsibility for the development of the stories need to be involved in the final stages of grooming prior to taking the stories into development so that there is a common understanding of the intent for the stories. However, it might be a significant drain on the team if the entire development team became deeply engaged in the very early stages of backlog grooming – a large portion of that effort can be done by the Product Owner and/or a Business Analyst working with the Product Owner supplemented by inputs from the development team as needed.

The Relationship of Agile and Corporate Culture

It’s important to understand the relationship of Agile and corporate culture. Adapting an Agile development process to a corporate culture can be a very difficult thing to do because changing a well-established corporate culture is not easy. If you ignore this problem and implement an Agile development process without attempting to integrate it with the overall business environment that it is part of, it’s not likely to be totally effective. The predominant thinking seems to be that you have to force the whole company to be Agile in order to adapt it to an Agile development process; I don’t believe that is the best solution in many cases. A company’s culture should be designed and optimized around the business and markets that company operates in.

One of my favorite books on this subject is “The Discipline of Market Leaders” by Treacy and Wierzema. It identifies three primary “value disciplines”

  1. Operational Excellence – Companies who focus on operational excellence succeed or fail by offering products and services more efficiently than their competitors can offer them. McDonald’s and Walmart are examples of companies whose primary value discipline is operational excellence. They do the same thing repeatedly at a low cost; that is what “operational excellence” is and it is reflected in their culture.
  2. Product Leadership – Companies who focus on product leadership succeed or fail primarily by innovating products to meet market needs faster and better than their competitors. Apple and Samsung are examples of companies whose primary value discipline is product leadership. Constant innovation is very important to these companies and they might be dominated by engineers who wear jeans and sweatshirts to work.
  3. Customer Intimacy – Companies who focus on customer intimacy succeed or fail primarily by providing a high level of personalized service to their customers relative to other competitors. Ritz Carlton Hotels is an example of a company who is driven by a culture of customer intimacy – their employees are trained that customer needs and customer service always come first and their processes need to be flexible to adapt to customer needs.

The idea of value disciplines is that a company can’t be deficient in any of the three areas; however, no company can be all things to all people and the company needs to choose one value discipline as the primary area of focus to excel in. The value discipline that is chosen as the primary competitive differentiator tends to define the whole company and its culture and values.

How do these value disciplines align with an Agile development approach? Obviously, the Product Leadership discipline has a very strong alignment. Companies who are in a business that demands Product Leadership as a critical success factor will have little difficulty in adapting to an Agile development approach because there is a natural alignment with the primary success factors in their business. Operational Excellence is probably the one that is most difficult to align an Agile Development approach with. In these companies, there are several alternatives:

  1. Ignore the misalignment and just implement Agile as a development process without attempting to align it with the business. That’s not likely to deliver optimum results, in my opinion.
  2. Attempt to force the company to change its culture to be more Agile. That may not be successful either and also may not be the best solution for the company’s business
  3. Develop an “Adaptation Layer” between the Agile development approach and the company’s business environment. This approach is probably the most practical and most likely to be successful in many cases. It might consist of putting a thin plan-driven “wrapper” around an Agile development approach to integrate it with the company’s business.

My Agile Project Management Training provides more details on this approach and provides some case studies of companies who have taken different approaches for solving this problem.