Paul Gorans (IBM Global Business Services) and Philippe Kruchten (University of British Columbia) published A Guide to Critical Success Factors in Agile Delivery. This guide discusses the values, benefits and challenges of agile and proposes critical success factors for implementing agile delivery in the federal government.
InfoQ interviewed Paul about implementing agile practices, how agile impacts acquisition and procurement, scaling agile communication and the usage of reviews in agile.
InfoQ: What made you decide to write this guide on implementing agile delivery. To whom is it targeted?
Paul: Our IBM Center for the Business of Government had heard about the success of one of our IBM Agile programs with a U.S. Federal Agency that I had helped transition to an Agile approach, and the formal implementation of my Agile Competency in IBM Global Business Services, Federal. They recommended that I write a guide to help other Agencies understand some of the Agile basics, and the critical success factors that I feel are required for Agile delivery, and address a few U.S. Federal specific aspects that we are often asked about (e.g. how do you conduct 508 testing in Agile?).
InfoQ: What in your own words does it take for organizations to effectively implement agile practices?
Paul: Executive sponsorship from the business/mission and CIO. If you have that, then you have the ability to address all factors required for Agile success, including the ten that we included in our guide.
InfoQ: Changing the acquisition process is one of the success factors in the guide. What makes this so important for agile delivery?
Paul: In both commercial or federal entities, I have seen acquisitions ask for "Agile", while asking for traditional IT phases and gates, or including measures of evaluating vendors or performance exclusively on low cost as opposed to value delivered. That signals to me that the term may have been written into the proposal at the last minute at the request of a stakeholder, but all parties may not yet be on the same page. It makes potential partners/vendors unsure of what the client is asking for, vary the responses, and make it harder to evaluate proposals. For any acquisition (regardless of the approach taken), procurement should be on the same page with what the business wants (often a solution to a business problem that includes IT), the leading practices that best help them to achieve that goal, and what is required by all parties involved for success.
InfoQ: The agile delivery guide suggests to implement more verbal communication and dashboards. Is this something that can be scaled? Can you give examples how this can be done in larger organizations?
Paul: Yes. Both verbal communication and dashboards can be scaled. On projects with many agile teams, a communication plan should be developed that is fit to the program (note that I often relay the fact that traditional project management practices are still relevant in Agile, but PMs (or Scrum Masters) need to rethink the level of detail they are written at and how they are conducted). The verbal components of that are the daily standup meeting on each agile team, and a cross team (e.g. Scrum of Scrums) after the Agile team stand-up meetings within a program, to raise awareness of impediments and seek support for impediments that impact all teams.
On our IBM projects, I have implemented an IBM-only daily standup/status that allows our Agile project leads to directly communicate with our Project Executive (PE) and key delivery managers. It assures that the Project Executive is seldom surprised by anything going on, and affords the PE an opportunity to directly interact and mentor many junior project managers for a bit on a daily basis, and provides he or she information for them to communicate with their executive level clients or partners. Using other follow-up, written emails and one page status should be fit to purpose in support of those verbal communications as well.
Regarding dashboards, wiki's can work for some communications, however there are now many Agile tools or suites of tools that scale to multiple Agile teams, programs and organizations. This allows both developers and executives to see the same detailed or aggregated information as soon as it is available from one repository. Stories, build statistics, impediments, burn down charts,can be seen from any desktop, regardless of where the various teams and stakeholders are physically located.
One constraint to scaling tooling for end to end visibility is that multiple functional areas within an organization are often responsible for acquiring and managing tooling for their traditional function (e.g. requirements, testing, configuration management, deployment). That again requires executive support to work across business and IT groups to define a solution that provides end to end value.
InfoQ: An agile way of working asks for different kinds of reviews as the guide mentions. Can you elaborate on that?
Paul: The review of a story by the product owner as it is completed, or a demonstration of a group of stories by a broader set of stakeholders at a Sprint review are reviews (of a working product). An Agile approach, even for a large project that is decomposed into many Agile teams, and lean support teams, still provides an opportunity for other reviews, but to be efficient those reviews should happen more iteratively. For example, this may require that staff responsible for standards to review design decisions, or code (including output from automated code quality tooling) as it is produced for each release, iteration or story. That requires stakeholders to change how their staff works on a daily basis to support the needs of Agile teams (daily interaction with teams in review/feedback cycles as opposed to checkpoints that could result in costly refactoring).
On larger projects, I also recommend reviewing the prioritized capabilities that are planned for a release period (fixed time, fixed resources) with the executive stakeholders. Far too often, teams start off conducting Agile delivery, without setting some expectation of what can be delivered by a given end date, or without doing some high level estimating first. Then, at that point, they may be way off, and may not have planned for enough Agile capacity to support the executive stakeholder needs and commitments. There are techniques that we have used for years to conduct "just enough" estimating up front as opposed to waiting to estimate after generating a sample velocity (that validation is still critical after a couple of Sprints). This provides stakeholders some indication about what can be delivered, and helps to earn the trust of stakeholders that may not be convinced of the value of an Agile delivery approach.
InfoQ: How can organizations use this guide when that want to adopt an agile way of working or improve the results of an ongoing agile adoption?
Paul: I recommend that they use the guide as they either consider implementing an Agile approach for the first time, or as a quick evaluation of their current implementation of Agile. They then should write down the gaps that they believe they have and develop plans to address them. Then, for gaps that they don't believe they can address themselves, they should secure the assistance of a partner with capabilities commensurate with their need.