stand the test of time, providing direct support for both their current IT infrastructure and their Agile goals. Many enterprises fail to consider how Agile tools must coexist alongside existing tools/processes and future business plans. Key questions to ask when making this evaluation include:
- How well does the ALM vendor's product roadmap align with your organization's Agile objectives and how do mis-alignments, if any, reflect the vendor's ALM vision and the priorities of the vendor's existing customer base?
- Can the ALM product's architecture scale effectively in line with your business plans?
- Does the ALM product support the needs of geographically distributed teams and is its licensing scheme aligned to a global, mobile delivery model?
- If a Software as a Service (SaaS) solution is an option for your organization, what service levels must the vendor commit to in order to meet your business continuity requirements?
- Does the ALM product treat each project as an "island" or does it provide an organizational view of your entire project portfolio?
- If your organization is still in the process of adopting Agile methods or must partner with third parties who employ a different process, can the ALM product support Agile, non-Agile, and hybrid projects alike?
- What support does the ALM product provide for traceability, risk management, IT governance, and other processes that are not explicitly Agile?
Throw Away the Playbook and Find the Right Help
Adopting an off-the-shelf Agile methodology, such as XP, Scrum, etc., across the enterprise without tailoring it to specific needs is almost always disastrous . This is attributable to the fact that most Agile methods are woefully lacking in guidance for critical pieces of the development lifecycle, notable examples being requirements elicitation, user-interface design, and dependency management. [iii],[iv] Agile methods also offer scarce guidance on organization-level functions, such as governance, quality management, risk management, and business continuity. Often, we see organizations trying to replace processes with popular Agile methods without updating other elements of their delivery model to complement Agile principles.
For instance, a leading electronics retailer recently admitted to us that its teams were using Agile methods, but that the organization had virtually lost its visibility into project priorities. How can this happen when teams are collaborating closely with the business and capturing requirements as stories? The answer, as it turns out, was that while the client's IT organization was aggressively adopting Agile methods, it had simultaneously abandoned its existing PMO and many of its portfolio management practices. Result: the classic problem of trying to fit a square peg into a round hole.
Beyond acknowledging that adherence to Agile "by the book" is less important than business results, it is also important to recognize that the people who taught you Agile, and are perhaps providing consulting support for your pilots, are usually the wrong people to help deploy Agile throughout the enterprise. This is because learning Agile and getting your feet wet with pilots is a knowledge, skills, and concepts problem, whereas, rolling out Agile broadly across the enterprise is a change management problem.
When identifying individuals to lead your Agile transformation effort, look for people who:
- Exhibit an overt focus on business results.
- Have a demonstrated track record of major, enterprise-wide change management initiatives.
- Are familiar with issues specific to enterprise IT environments and are fully versed in Agile and traditional methods.
Our Own Worst Enemy?
Now let us turn to the role the Agile community plays in all this. To date, passionate and often rhetorical arguments have dominated many of the discussions taking place at Agile conferences, on message boards, and other venues. This has led