[Editor's Note: After reading this blog posting, test your knowledge of the topic with the five question quiz at the end of the posting!]
In my blog post, “Agile Adoption across the Enterprise: Still in the Chasm,” I make the claim that agile adoption within development and IT has crossed the chasm into the mainstream, but agile adoption across the enterprise has not. Meaning in most companies, agile principles have not been adopted outside of non-development organizations. As a result, within a company doing agile development, there is often extensive misalignment of the various organizations/groups.
In this blog I want to focus on the misalignment problem. In future blogs in this series I will address how different non-Development groups within the enterprise can adopt agile principles to provide better alignment throughout the value chain.
The Misalignment Problem
The following illustration highlights examples of the kinds of enterprise value-chain misalignment that I frequently see within companies I visit. Do any of this sound familiar?
Legal
Perhaps your legal group still writes contracts that shift all risk to the other party (e.g., fixed date, scope, and budget). Locking down date, scope, and budget over constrains the team’s ability to maneuver and is not conducive to operating in an agile-like way.
HR
Maybe HR still focuses on annual performance reviews because they want to make sure the company is in a legally defensible position should a personnel issue occur. Providing slow feedback at a cadence (once a year) that is so grossly out of step with the cadence of agile development seems like a poor fit for an agile organization.
Finance
What about finance? Many finance groups require annual budgeting where every dollar is pre-allocated to specific projects up to 15 months in the future. They’re quick to remind you, too, that you will be accountable to ensure that each dollar is spent in that way! I can hardly image a less agile-like way of allocating money: Let’s guess up to 15 months out what all the projects are and exactly how much we will spend on each project and when.
Development Partners
There’s a good chance that your (third-party) development partners build things their own way, even though you use agile. Is it their preference to coordinate with your work at the very end, when they hand you the full deliverable? Again, it’s hard to be agile in a world where late integration and slow feedback are the norm!
Marketing
Marketing might still be telling you they have to know the complete feature set and delivery date upfront so they can plan their marketing activities many months in advance. Look, the folks in marketing have to do their job, and the questions they are asking are important. We all just need to be realistic in what can be decided very early on in a product development effort when we have the least information (most uncertainty) we will have.
Operations
How often does IT/development have customer-valuable work ready to deploy but is delayed in doing so simply because the operations group is still deploying on its own schedule? It would be difficult to claim the company is getting the desired value from using agile if it produces world-class software each iteration and has no ability to get the software into the hands of its customers in a timely way.
Sales
Maybe the sales team is pushing work into the system (into development) as fast as it possibly can so the salespeople can meet their goals and realize their hard-earned commissions. If salespeople are out cutting deals without regarding to development capacity, their commitments will quickly exceed the development work in process (WiP) limit of the organization.
Customers
Customers can cause misalignment problems as well, especially when they make special requests for features, but do so expecting to lockdown date, budget, and scope. They think that passing the risk on to the vendor makes them more robust, but what they are really doing is making the whole effort more fragile. We need to engage with our customers in an agile-like way to avoid setting everyone up for failure and disappointment.
Management Team
Last but not least is the management team. Too often those in management expect the IT/development teams to be agile while they continue to work in a non-agile-like way. Talk about sitting on both sides of the fence at the same time! “Hey, you guys in IT/development, go do agile but we will operate in the same way we have always operated in the past.” This only serves to put the project in a compromised position from the moment work begins.
Moving Forward
With such misalignments running rampant within companies, the long-term successful use of agile is in jeopardy. In future posts in this series I will address how various non-development organizations can embrace agile to better align the enterprise value-chain for the fast, flexible, flow of work.