In Part 1, I talked about some of the problems I’ve observed in large enterprises converting to Agile. Now, let’s talk about some solutions to those problems.

I’ve been reading around the internet about scaling Agile to enterprises, and there are a lot of passionate and one-sided arguments about the pros and cons of different approaches to this. Some folks claim that the techniques for scaling Agile really just create Waterfall with an Agile skin. But I like to take a pragmatic approach, and experience has shown me that in a really large organization, pure Agile probably isn’t possible. So what would work to alleviate the problems I outlined above so that large businesses can reap at least some of the benefits of Agile?

For one thing, a large enterprise does have to have some centralized governance of its IT projects and architecture. Trust me, I once worked for a company that didn’t, and it wasn’t pretty. Here are some suggestions for scaling Agile, followed by a hypothetical scenario as an illustration.

Develop an IT strategy – You can’t do this in a vacuum, of course. The organization has to have an overall strategy before that can be translated into projects for different work streams. Once you have identified measurable goals for the company, then you identify how IT and the other parts of the organization are going to work together to achieve that strategy. Too many companies still think of IT as a separate thing that exists just to do what they’re told by the business. In an Agile environment, this is absolutely self-defeating. All the contributing parties have to be at the table from the beginning, working together to develop a cross-functional approach to problem solving and opportunity generation.

Do enterprise architecture – EA is one of those terms that can mean a lot of different things. According to definition, it’s about more than information systems. It’s really about all aspects of a company’s structure and how that structure delivers the strategy. But for most organizations, EA still primarily refers to the design and planning of IT hardware and software to optimize the effectiveness of IT resources. Each program/strategic initiative/project should start with enterprise architecture. What is the current state, what is the desired end state, what is the delta, and what is the plan for getting there? These are the questions that EA must answer before launching teams into a new development project. Otherwise teams must make it up as they go along and may well be working in non-compatible technology silos.

Budget realistically – Most organizations have financial control structures built around the old Waterfall way of doing things. First, you create a project charter and get approval to proceed, then you define scope in detail and develop estimates, then you get approval to move forward with development. As the project moves forward, scope changes will occur, which will be balanced against value to adjust the budget if necessary to achieve the project goals. To budget an Agile project, the team must understand the requirements well enough to develop themes and epics. If the objectives have been well defined and the EA has been done, the team will have the context to tee-shirt size the effort involved. In either the Waterfall or the Agile scenario, this process only really works if the participating teams are given reasonable time to develop estimates, if the complexity of dependencies is taken into consideration, and if management trusts their teams well enough to accept their estimates. Many organizations get into a fatal downward spiral of distrust, where teams pad estimates because they know they will be drastically cut, and management cuts estimates because they know teams pad. In my experience, when this occurs, the original team estimates generally turn out to be much closer to reality than the chopped down budget that management imposes.

Communicate – In my opinion, communication is where a lot of otherwise good processes fall apart. Effective Agile requires communication and trust across an organization. And the more teams a project touches, the more important communication is. There are a few communication-killers that organizations must eliminate to enable good communication.

• Information hoarders – those chaps in a large company who equate knowledge with power and hold on to information instead of sharing it.
• Authoritarian communication – a few people in management hold the keys to the data, the metrics, and the reports, but they don’t share relevant information with the rest of the organization, which results in teams not having the success metrics and data that they need to prioritize their work and deliver real value.

One of the tricks that Waterfall project managers learned was to create a communication plan for projects, a tool that Agile projects would do well to utilize. A communication plan is a simple matrix identifying stakeholders, their interest in and influence on the project, and the planned communication with those stakeholders. It really helps hold down the constant stream of ad hoc communications if people receive regular, predictable communications.

The Dream (a simplified scenario)

Imagine a company that sells telephony solutions to businesses. Sales are good, but the company isn’t hitting revenue goals. Analysis reveals inconsistencies in the way quotes are priced and lower margin than target. The sales application in use does not provide adequate pricing guidance and controls. So the company management decides that the sales application should be modified to provide a mechanism for limiting discounting by sales users. The company directors are asked to evaluate this program and provide scope and budget for the necessary work to enable this change.

A month later, the IT director reports that his teams can implement the change in 3 months (6 2-week sprints) with 2 feature teams utilizing the existing sales application framework. The sales director reports that she will need to provide training to her sales team which will require 2 trainers to develop and schedule training, plus the time for 80 sales users to attend the training. Also, the sales director and the finance director need to work together to develop an updated compensation plan for sales so that the correct behaviors are being incented. They think this will take 6 weeks of coordinated effort and one accountant to manage it. The HR director is concerned that the change may cause some turnover in sales personnel and estimates that he may need to hire up to 8 new salespeople to backfill. The estimate to implement this change comes to almost $800k. The CEO is a little surprised, but she trusts her teams to make realistic estimates. Since the project is projected to result in $3 million in increased revenue annually, the benefit is clear and the project gets the green light to proceed. The sales director, IT director, finance director, and HR director immediately schedule a weekly meeting so that they can coordinate and plan their respective teams’ activities.

What did they do right? Clear goals translated to specific team actions, trust and communications, and realistic budgeting. You can probably guess that they all lived happily ever after.