Transitioning to agile
ten success strategies
This paper presents ten success strategies when transitioning from traditional methods to agile software development methods. It is intended to be used by business executives as well as IT executives in preparing and planning for software development programs. The target audience also includes program managers, project managers, and Scrum Masters who will lead agile initiatives, and acquisition professionals who procure agile software development services. The success strategies were derived from interviews and other correspondence with program managers and agile practitioners actively delivering software on a variety of projects across the globe. Supporting information was obtained through: Standards Organizations (PMI, Scrum Alliance, Agile Alliance, Scrum.org, DSDM, IEEE, etc.), Research Institutions (Gartner, Standish, Forrester, etc.), Industry Case Studies, books, and information gathered from Internet sources. References are provided throughout.
Introduction and Background
Agile projects are successful three times more often than non-agile projects, according to the 2012 CHAOS report from the Standish Group (Cohn, 2012). In addition, in a 2008 independent study of over 7500 traditional and agile projects, QSM Associates concluded that, as compared with industry averages, the development teams utilizing agile practices were on average (QSMA, 2008):
- Thirty-seven percent faster delivering their software to market
- Sixteen percent more productive
- Able to maintain normal defect counts despite significant schedule compression
Given the resources (e.g., human, financial, etc.) applied to software development programs; this is significant to any organization. In order to achieve these benefits, it is important to understand that agile requires discipline. Moving to agile also requires a cultural shift and an organizational commitment. Management must entrust and empower people to make decisions and collaborate across the organization. When considering this new approach, it is important to recognize that agile is not a single method or process, but a combination of methods based on iterative and incremental development. Selecting the right strategies can set the pace for a successful agile program.
Since the advent of large scale computing in the 1940s, management has sought efficient methods to manage and control software development. In the 1960s, The Systems Development Life Cycle (SDLC) was introduced to meet these needs. Life cycle models initially included Waterfall and Spiral methods and evolved overtime to include Evolutionary, Incremental and Iterative builds (IEEE, 2006). Agile grew out of the latter build processes in the 1990s.
Many organizations embraced the Waterfall method early on due to its strengths: very manageable, allows for more control than earlier ad hoc/trial and error methods, and it provides comprehensive documentation for future enhancements. As the adoption of the Waterfall method grew, it became apparent that it had its own new set of weaknesses, including an inflexibility to adapt to change, an emphasis on individual actions versus the cumulative efforts of the teams, and others. One of the main problems with Waterfall is that the scope of work is determined at the onset of the program; and those fixed requirements are cascaded throughout the life cycle. This method did not accommodate the changing needs and priorities of the organization, resulting in programs that were either unsuccessful in meeting business needs as they evolved, or programs that were plagued with cost and schedule over-runs as teams sought to accommodate changes in direction – many ultimately failed.
Over the years, many have attempted to improve the success rate for software projects. Rapid Application Development (RAD), Rapid Prototyping, and Joint Application Development (JAD) increased success rates in the 1980s. These early collaborative methods paved the way for agile methods that emerged in the 1990s.
The Emergence of Agile
First introduced in the early 1990s, agile development methods gained significant momentum in response to their increased success rate over traditional methods. Early agile methods included eXtreme Programming (XP), Scrum, Dynamic Systems Development Method (DSDM), Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming (Wikipedia, 2013). Based on the success each achieved, and a desire to share the methods, representatives from each of these methods convened in February 2001. At the end of the meeting, A Manifesto for Agile Software Development (Highsmith, et al., 2013) was created (the Agile Manifesto can be found at: http://agilemanifesto.org/).
Today the Manifesto serves as a guide to several agile methods. Software development initiatives are now experiencing significantly more success using agile. In fact, according to the 2012 CHAOS report from the Standish Group, agile projects are successful three times more often than non-agile projects (Cohn, 2012). Exhibit 1 details the findings of this report.
Note: Standish did not report how many projects are in their database but said that the results are from projects conducted from 2002 through 2010.
The reasons many organizations adopted agile methods included (VersionOne, 2011):
- Accelerating time to market
- Enhancing the ability to manage changing priorities
- Increasing productivity
- Enhancing software quality
- Improving alignment between business and IT objectives
- Improving project/program visibility
- Reducing risk
- Simplifying the software development process
- Enhancing software maintenance/extensibility
- Improved team morale
- Reduced costs
- Improved engineering discipline
- Managing distributed team.
To achieve these benefits organizations are embracing agile at a very fast rate. In a 2013 survey of 4,048 individuals in software development communities by VersionOne, more than 84% of respondents said their organizations were practicing agile development in 2012, up from 80% in 2011(VersionOne, 2013); when considering this new approach, it is important to recognize that agile is not a single method or process. Wikipedia defines agile software development as “a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and rapid and flexible response to change. It is a conceptual framework that promotes interactions throughout the development cycle (Wikipedia, 2013).”
Due to the multitude of agile methods described above and emerging/hybrid methods, the need to simplify approaches becomes evident. Agile methods are covered in Success Strategy 4 – Embrace Agile Methods as follows.
Ten Agile Success Strategies
This section presents ten success strategies for transitioning from traditional to agile development approaches. The success strategies were derived from interviews with agile program managers and practitioners actively delivering software on a variety of projects across the globe. Supporting information was obtained through research based on several sources, including: Interviews with agile professionals (i.e., business, IT, and management), Standards Organizations (PMI, Scrum Alliance, Agile Alliance, Scrum.org, DSDM, IEEE, etc.), Industry Case Studies, books, and research institutions (Gartner, Standish, Forrester, etc.).
Success Strategy 1 – Secure Management Commitment
In order to be successful, management commitment must be secured and in place prior to beginning a program. This is true for an agile program or for any major organizational undertaking. The named executive, usually a program sponsor, is the individual executive who champions the program initiative and is responsible for providing the program resources and is ultimately responsible for delivering the benefits (PMI, 2013). The UK National Audit Office cites a “Lack of clear senior management ownership and leadership” as a major cause of project failure (Ryder, 2009). Having a single senior executive sponsor helps facilitate program success in many ways, these include:
- Serving as the program champion and removing roadblocks
- Securing and managing the program resources (budget, people, facilitates, etc.)
- Helping to secure commitment from both business and IT organizations
- Identifying stakeholders and helping to communicate their needs.
- Anticipating changes to the program based on organizational change
- Maintaining a line of sight and alignment with organizational strategies and helping the program achieve compliance
- Establishing a communications structure to facilitate communications top to bottom
- Identifying a capable program manager, product owner, and ScrumMaster
There are times when key resources may be unavailable. We recommend that when selecting lead resources that a proxy or deputy also be assigned. This person would follow closely and be ready to take over the responsibility in cases where the lead is unavailable for an extended time. If the responsibility to perform the tasks above is delegated, the delegate should be either granted the authority to perform the tasks described above (or a subset) or have quick access to executives who can help facilitate these needs. While executive commitment is paramount to the success of a program, it is also important to recognize the need for grassroots support as well. People at all levels of the organization can serve as change agents and should be engaged to help tip the scales of success in the right direction.
Success Strategy 2 – Empower Your Team
Agile, by its very nature, requires a structure where decisions are made often and quickly for each iteration. Given the quick turn and iterative nature of agile development, timely decision making is critical to successful implementation. Unlike traditional methods, agile provides significant transparency and reduces the need for exhaustive checkpoints. This transparency provides managers insight and presents an opportunity for team members to be empowered to make certain decisions without having to reach back through a series of approvals. Having the right resources on the team, including end-users, decision makers, and other key stakeholders helps facilitate the decision making process.
A product owner is the lead who brings the customer and business perspective. This person must be provided the decision-making authority for the priority of the content of releases. When transitioning to agile, organizations generally underestimate the impact of this consideration. Having an agile method requires that leaders are empowered to make decisions to keep the projects on track. If the organizational governance structure does not support this consideration, it is unlikely that success can be achieved.
Formerly, using a traditional approach, business representatives were primarily involved at the beginning (requirements phase) and at the end (acceptance phase). Using an agile approach, the business representative now has a key role — Product Owner. Unlike a traditional approach, where the development team takes the information from the business side and sets forth their own plan, often without knowledge of the business priorities, the Product Owner is involved throughout the life cycle.
The Product Owner leads the sequencing and maintains a prioritized backlog based on the current needs of the business. A Product Owner spends a significant amount of his or her time at the beginning of the program (generally 40%–50%). During this time, they help define the scope of the program, describe/clarify requirements and express them as user stories, and develop the initial prioritized backlogs. In subsequent phases, they typically spend 25%–30% of their time identifying, modifying, elaborating, and clarifying the requirements and user stories, while continually prioritizing work to align with current organizational needs, and providing guidance as needed. As the product is developed, the Product Owner should be readily available to provide clarification and remove roadblocks for the agile team, attend review sessions and provide feedback. The Product Owner is responsible for gaining acceptance of the user stories and maintaining communications with business stakeholders and executive sponsors alike. Finally, as in the traditional approach, they attend demonstrations and testing to verify the product performs as required.
The other roles, ScrumMaster and Agile Team, must also be empowered to become self-managing and collaborative across the stakeholder community. Unlike the traditional approach where all information is gathered up-front, on agile programs team members (both business and IT) collaborate throughout the life cycle. As the products are incrementally developed, prototypes, and demonstrations are used to facilitate the development of the right product. Changes are made near real time, and priorities are updated with each iteration. Collaboration and involvement of the stakeholder community at the appropriate times keep products on track and outcomes aligned with current needs.
Success Strategy 3 – Understand the Collaborative Culture
Whether you use a traditional or agile approach, in software development, there are very few information technology (IT) focused projects. Most projects are mission focused or support the business in some way and happen to have IT components. This statement is critical to help organizations understand the need to allocate business, technical, and management resources for collaboration. As such, the representatives from business areas need to drive agile programs; their participation is a cornerstone of an agile approach. At the heart of agile projects are three key roles: The Product Owner, The ScrumMaster, and the team (group of stakeholders, business and technical resources).
To facilitate the culture of collaboration, when practical, teams or at least the core members (Product Owner, Scrum Master, Team Leads), should be physically co-located or connected virtually. This means if physical co-location is not an option; the team should participate in all daily Scrum meetings through video conferencing. New technologies (Skype, Face Time, Web Meetings, etc.) enable virtual face-to-face meetings. By physically seeing individuals, conversations are enhanced by reading body language and observing physical cues. With global teams, given the time zone differences, this may not be practical. Recording Scrums or having a Scrum of Scrums at a mutually convenient time (on a weekly basis) may help facilitate the communications needed. Given the short iterations and continuous re-prioritization, it is important that people are networked together to communicate changes in a timely manner.
Agile teams, regardless of their contracting arrangement, should be integrated as a single team. Whether a group is contracted separately to perform independent testing or to provide management oversight, it is important to integrate the teams to reduce the potential for process delays. The nature of this integration is not to lose independence, but to provide access to all teams to facilitate their relative roles. For example, an independent management oversight team, if given direct access to the on-going work, will not only be able to provide real-time input, but can enable the team to apply corrective actions without delay.
Independent test teams need to be involved (and integrated) throughout the process. In the development of requirements, user stories, etc., the test team develops and/or reviews acceptance criteria and gains an understanding of the “definition of done.” This key concept “done” is described in Success Strategy 8. Integrating testing teams helps not only reduce lag, but often reveals process opportunities. For example, if independent test teams are understaffed, a backlog may be created in the testing phase, making integration and configuration management more difficult. If the teams have available time, work may be able to be conducted in a more proactive fashion, supporting downstream processes. If shortcomings are realized sooner, corrective action can be taken before issues emerge.
Success Strategy 4 – Embrace Agile Methods
Dave West, Forrester Research, recently wrote: “Organizations are adopting Agile through a combination of bottom-up adoption and top-down change. But the reality of agile adoption has diverged from the original ideas described in the Agile Manifesto, with many adoptions resembling what Forrester labels water-Scrum-fall. This model is not necessarily bad, but if application development professionals do not carefully consider and make the right decisions about where the lines fall between water-Scrum and Scrum-fall, they are unlikely to realize Agile's benefits” (West, 2009). CSC's experience has shown while applying agile techniques to traditional approaches is very helpful, the true value of agile is best realized going “all in.” Many organizations have experimented with agile by taking some of the best practices and applying it to the traditional approaches, and then documenting this task by tailoring to their Waterfall SDLC, resulting in a hybrid Waterfall/Agile (Salinas & Boyne, 2012) method. While this approach is more effective than Waterfall alone, unnecessary documentation is developed to map the methods and the full benefits of agile development may not be realized.
As discussed earlier, there are many different agile methods and as many Internet articles, books and other sources describing the pros and cons of each. When posed with this issue, CSC developed a survey and sent it to our CSC Agilists (a CSC internal community of over 1000 agile practitioners) and also reviewed information from research institutions (Gartner, Forrester, etc.). Based on the findings, we developed a library of agile delivery processes. As an example, CSC's Agile Scrum Development Methodology, as summarized in Exhibit 2 below, is based on Scrum, but also including best practices from RUP, DSDM, XP, Kanban, SAFe, DAD and PMI Agile Practices. This method is fully customizable for iterative and incremental software development. CSC uses Scrum as the primary method for new development or significant enhancements on maintenance programs.
CSC has also found Kanban to be an effective method for managing break/fix software maintenance type programs. Kanban, a technique taken from Lean Manufacturing, provides application development professionals with a way to improve flow, optimize batch size, and ensure execution success in situations where pure agile is less practical. It also can augment agile projects that involve more than one team, providing clear signposts to enable cross-team success (West, 2011). Kanban, Japanese for ‘signboard’ (as depicted in Exhibit 3), provides a visual process oriented system for managing multiple concurrent changes.
The method is often better suited to application maintenance support as the level of integrated changes and collaboration requirements while still needed, are different than Scrum. For more information on agile methods, please refer to http://www.agilealliance.org/ or http://www.scrumalliance.org/. For the Agile Manifesto and Principles of Agile Development, please refer to http://agilemanifesto.org/.
Success Strategy 5 – Develop a Roadmap and Initial Plans
It is important to note that agile is a software development method and it does not replace organizational planning and strategy. As with traditional software development approaches, agile is a component of the overall planning process. Hubert Smits of Rally Software Development Corp. developed a white paper in 2006 that describes “5 Levels of Agile Planning (Smits, 2006).” This section leverages the levels provided by Smits and includes additional information and insight based on research and interviews.
Level 1: Product Vision – The Product Vision represents the future state of the product, organization, or supporting business processes. This vision is developed by the sponsor or Product Owner to communicate what the future state will look like at the end of the project. They share how the system/process will change and in what order the business desires these changes (establishing priority). They also describe a high-level estimate of what it will take to complete the project (establishing estimates and commitments). The periodic review of the different planning levels will help to facilitate changes in the needs/desires/priorities of the business and are reflected in updated versions of the plans at all levels.
Level 2: Product Roadmap – A Product Roadmap is created to communicate the overall product plan to a wide range of stakeholders. The roadmap, usually depicted as a picture or timeline, describes the functionality planned for delivery. A product roadmap will evolve over time to reflect the current direction of the product. The product owner will oversee updates to the roadmap based on current needs and priority of the organization. We recommended that roadmaps are reviewed top-down at least quarterly; and bottom-up as a part of planning each release. The challenge with roadmaps in agile is that they should be updated to communicate the current direction, with the caveat that as business priorities change, so will the roadmap.
Level 3: Release Plan – The Product Owner is responsible for release planning and leverages the Product Roadmap as the starting point for the Release plan. The product components and features are documented in Epics and decomposed into user stories. The user stories are prioritized, estimated, and placed in a release backlog. As features from the product backlog are grouped into releases, the Product Owner can refer back to the roadmap to verify the sequence aligns with the overall plan. Initial Release planning should cover the first 2 or 3 releases. Because continuously re-planning is a core feature of agile, it is important not to plan too far out initially. This may set expectations, like Waterfall, that all of the planned capabilities would be available before new capabilities are built.
Level 4: Sprint/Iteration Plan – For each sprint/iteration within the release, a planning session is held to apply the prioritized backlog items to the upcoming iterations. The velocity is reviewed from prior sprints and resource availability is confirmed and then planning commences. The user stories may be reviewed before or during the session and detail is added to assist in the estimation. The combination adding detail to the user stories, reviewing velocity and resource availability helps the team to commit to and deliver features planned during that iteration.
Level 5: Daily Plan – The ScrumMaster facilitates a daily stand-up meeting (Scrum). In the Scrum Meeting, three key questions are asked: “What did you do yesterday? What will you do today? Do you have any obstacles?” These three questions help the ScrumMaster and Product owner manage the iteration plans, apply or seek additional resources and communicate progress to the appropriate stakeholders.
Success Strategy 6 – Acquire an Agile Coach and Train the Team
Agile software development represents a major change in how organizations manage business and IT initiatives. As with any change, the path is difficult; trying to do it with resources that have no experience greatly impacts your ability to be successful. CSC's experience has shown that at a minimum having an experienced Agile Coach, ScrumMaster, and at least 20% of the team with agile experience greatly improves opportunities for success.
In a Waterfall approach there are often quality assurance leads or process engineers to manage and monitor that the processes are followed correctly. In an agile approach, an Agile Coach is used to manage and monitor the processes. Experienced agile coaches bring (Brown, 2009):
- Deep Knowledge of agile – Experience with both the techniques and principles behind them.
- Broad Experience – An Agile Coach should bring experience with a number of organizations and have experienced issues and successes.
- Impartial Perspective – Organizational change is not easy. It may be more difficult for an insider to break from their former role and be seen as a change agent.
- Coaching skills – Agile brings not only new tools and processes, but also a new culture of collaboration. An Agile Coach can support individuals and groups trying to come together for the first time.
- Reinforced Learning – While many agile programs begin with training, the OTJ reinforcement of skills helps institutionalize processes.
As stated above, a single experienced agile coach is not enough, the team needs an infusion of experience at different levels and training for others. Agile Coaching is an established profession. We strongly recommend all organizations consider hiring an experienced Agile Coach to help with your transition; following the transition, the responsibilities are often assigned to the ScrumMaster.
There are many types of training and levels of certifications available. We suggest that both management and the team receive training. We have found the agile certification programs (e.g., Scrum Alliance, PMI, Scrum.org, DSDM.org, etc.) to be very useful. Since agile development is new to many organizations, it is important to provide training to as many as practical who will be involved in the process. This can range from awareness training (something as simple as a 10-minute YouTube video) to full formal certification training. Exhibit 4 provides guidance on the training available and the roles that may best benefit from these sessions.
Success Strategy 7 – Start Small and Gain Early Successes
Conventional thinking for any organizational change is to start small with pilots, learn from them, and then progressively introduce the change into rest of the organization. Introducing agile into your organization should be no different. Nothing could help an agile program gain more traction than showing early tangible successes. And conversely, nothing can derail a new process faster than challenging it before it is mature. A recent Forrester white paper suggested, “selecting a project where access to the business is easy and strong working relationships already exist (West, 2009).” After the process has matured, only then does it make sense to challenge the process with more difficult work. Mike Cohn, owner of Mountain Goat Software and one of the founders of the Scrum
Alliance, in his 2010 article “Choosing to Start Small or Go All In when Adopting Agile,” provided the following benefits of starting small (Cohn, 2010):
- Starting small is less expensive – New initiatives generally run at a slower pace initially and then gain traction. Committing fewer resources initially helps control costs by allowing the team to focus and learn from trial and error on a limited cost exposure basis. Future projects will realize benefits even faster based on lessons learned that are brought forward from these early initiatives.
- Early success is almost guaranteed – By carefully selecting the initial project and team members who will work on it, while maintaining a small scope, you can generally expect success.
- Lower risk – Having your entire organization begin using a process that is not mature may result in confusion and ultimately in failure. If you start to transition your organization too early and you make a mistake, you will increase the opportunity for resistance.
- Starting small is less stressful – Having resources with agile experience as described above, should lower the concerns of others in the organization. New processes are inherently stressful; having the entire organization feel that stress is avoided by starting small.
- Starting small can be done without re-organizing. Having only a few people join a pilot team is less disruptive to an organization. After realizing the benefits and successes of agile methods, it may or may not be necessary to re-organize.
Starting small may also reveal new challenges. For example: If an agile team needs support from non-agile teams, joint planning sessions needs to be held to address these dependencies early in the process. The predecessor/ successor relationships and requirements from each of the teams (agile/non-agile) must be well understood, aligned and planned for in order to achieve success.
Success Strategy 8 – Establish Agile Performance Measures
A key difference between agile and traditional approaches is that traditional approaches focus on delivering a list of baseline requirements, while agile continuously assesses, reprioritizes, and re-plans the requirements to be worked on for each iteration. The focus of agile is to work on current business priorities versus conforming to a set of baseline requirements that may not reflect the current business direction. Based on these differences, new management and measurement techniques are introduced with agile. This section describes the core measures.
Using a traditional approach, the constraints of cost, scope and schedule are generally fixed on scope with a tradeoff between cost and schedule variables. Many of the measures are around the delivery of a fixed group of requirements. With a fixed scope and generally longer durations, earned value analysis measures are very easily applied. With agile, the schedule is fixed and cost and scope become the variables as the scope is re-prioritized with each sprint/release. Many argue that earned value analysis for agile, while it can be done, becomes an “administrative task and there are better alternatives available for agile projects (Griffiths, 2007).” Velocity, described below, has been used by some organizations to help compute earned value metrics (ETC, EAC, etc.).
Agile introduces new terms for measuring performance: Story Points, Velocity and “The Definition of Done.” At the heart of agile estimating is a story point. A story point is a relative scale of effort required by the team to implement a user story. Agile Scrum does not use time (1 hour, etc.) to estimate work; it uses relative abstracted metrics to quantify effort. Common estimating methods include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), or the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.). The important thing is that the team shares an understanding of the scale it uses, so that every member of the team is comfortable with the scale's values.
Prior to determining an estimate, CSC recommends that the user story be “groomed.” Grooming is a process that allows the entire team to review the story and come to agreement that the intent and acceptance criteria are well understood so that it can be estimated. As an example, for a major U.S. Government client, our agile team meets 1-2 hrs on Mondays and Fridays to groom stories at least 2 to 3 sprints ahead of the current sprint. This allows the team to see what is being planned and have input into the story development. We have found that if you groom well, then estimating becomes much easier and consensus is achieved sooner. As with all meetings, grooming sessions must be facilitated to maintain focus and be productive.
Following grooming, the estimation process continues. The Product Owner is critical to both grooming and estimating. They must be available to answer questions to help the team in determining an estimate. Although they participate in the estimation sessions, they usually do not vote on the estimate as that may bias the outcome. The stories are reviewed against that scale chosen above, and concurrently each team member shows their estimate of effort. If there are differences, they are discussed and a metric is applied.
Velocity is the number of story points completed over a given period of time. For example, if the team completes an average of 10 – 5 point stories a week, then their velocity is 50 story points a week. 50 now becomes the capacity for subsequent (near-term) releases. The measures are often presented in a burn down chart and progress maintained in a Kanban board. As depicted in Exhibit 5, a burn down chart is a graphical representation of work left to do versus time.
During a pilot phase, velocity is initially determined and it is refined over time as the team innovates and interactions mature. Although story points and velocity are the basis for measuring performance, since story points are determined by the team performing the estimates, it is not valid to compare velocity across teams (each team may measure differently).
As scope is re-prioritized throughout the life cycle, how does one (i.e., management, stakeholders, team, etc.) know when you are done? The “Definition of Done” is a major consideration for agile programs. It needs to be negotiated up-front and refined over time. Given the potential differences in agile programs, each team will need to develop their own “Definition of Done.” Each phase (e.g., Release, Sprint) may require its own Definition of Done. Key considerations for this may include (Alverdyan, 2011):
- All acceptance criteria of the user stories are met
- Code meets the Coding Standards of the organization
- Code is either reviewed or produced with a pair-programming method
- Required documentation has been developed and peer reviewed
- Functional tests are performed independently by team members other than those working on the implementation of that feature
- Automated acceptance tests are prepared for the feature and are Green
- Integration tests of the affected areas are conducted and passed
As new standard processes emerge and others are replaced the definition of done needs to be updated to reflect the current state.
Success Strategy 9 – Create Agile Contracts
As described above, agile software development is adaptive and continually changing. One of the key considerations for acquiring and managing agile services is to develop an external list of work products and services to facilitate the maturing and changing processes. Since the detailed scope evolves over the course of an agile project, particular attention should be paid to describing the way in which the solution will be defined and delivered. So instead of focusing on “what” will be delivered, describe in as clearly and unambiguously as possible “how” the solution will be defined and delivered. Similar to coding business rules outside the core software, Contract Deliverable
Requirements Lists (e.g., deliverables, work products, artifacts, etc.) and other components may be better managed outside of the core contract.
Agile development produces a number of artifacts that may be more valuable in a repository other than a formal MS Word document. These may include engineering artifacts (requirements, user stories, use cases, etc.); design artifacts (conceptual, logical, physical designs); code and test artifacts (plans, cases, scripts); or management products (plans, acceptance, etc.). The key is to embrace technologies that support the processes and information by focusing on the content required and provided, rather than the container. This will result in more efficient resource utilization as people are developing content rather than preparing external documents. Version control, reuse, and administrative time should be also considered before requiring a product to be produced as a single document if the information is available and better utilized in another form.
Many of the artifacts from a traditional Waterfall approach will not be appropriate on agile programs (and vice versa). Working with the project teams, acquisition professionals can develop the appropriate measures and institute management controls to facilitate success. As different as things are there are many similarities. In a CSC white paper that was delivered to the PMI® Global Congress in 2011, “Balancing Agility with Conformance on Complex Government Programs,” the authors provide detail on how established methodologies, such as SEI CMMI® and A Guide to the Project Management Body of Knowledge (PMBOK® Guide) readily support using agile methods (Zaleski, Bostian, & McDyer, 2011).
Success Strategy 10 – Adopt ALM tools to Facilitate Interactions
Application Lifecycle Management (ALM) tools support application life cycle processes from planning and governance, through development, and into maintenance. Agile ALM tools integrate the agile processes and a governance structure on top of the considerations that traditional ALM tools integrate (e.g., requirements/traceability, design, build, test, and release management, change, and configuration management). Some ALM tools also integrate build with production monitoring and issue and defect management.
The ALM landscape is continuing to evolve. In a recent Gartner study, agile was cited as a key driver for a move to ALM — in particular for scaling agile to larger projects and distributed teams. Agile elements include task board, burn down, velocity and other reports, user stories and continuous integration. Pure agile teams are often looking for focused tools that support the practices common in agile development, and the leading providers also have strong support via training and education materials (Murphy & Duggan, 2012). Companies topping the charts included: Microsoft, IBM, Atlassian, Rally Software and Collabnet. With HP, VersionOne, Thoughtworks, and PTC-MKS (Integrity) closing in. As with all tool selections, it is important to understand the development environment, languages, tools already available, and other factors when selecting an ALM tool.
Integration of planning and development is a critical aspect of agile development. Because of continuous integration and delivery, agile programs generally have a lot more “moving parts” than traditional programs. Given the continually reprioritized backlogs and the speed of development, it is imperative for the planning and configuration management products to be aligned and integrated. Because agile values individuals and interactions over tools and processes, an agile ALM tool must do the same. In the Thoughtworks® white paper regarding key practices for agile ALMs, they recommend that the best tools for agile ALM must support the five key organizational practices and must (Teng, Mitchell, & Wathington, 2011):
- Enable teams to discover and evolve their process ‘on-the-fly’
- Support the unique needs of every project, as well as the organizational needs for consistency
- Facilitate constant collaboration among practitioners and stakeholders at all levels
- Automate testing and deployment to enable continuous delivery
- Provide complete transparency and visibility for leaders, without creating work for project teams
Organizations that embrace the five key organizational practices of Agile ALM and provide appropriate tools to support them increase their agility and their ability to compete. They create better, more exciting software, and get it into their users’ hands faster. Through better software, they discover new ways to engage and create value for their customers. They try out new ideas quickly, and they continuously adapt in-line with customer feedback, shifts in the market, and changes in business strategy (IBID).
In order to achieve agile's benefits, it is important to understand that agile requires discipline. This document presented ten success strategies for transitioning from traditional to agile development approaches. Based on research and experience it is strongly recommended that organizations consider applying these strategies along with strong business and IT management disciplines to position agile projects for greater success.
Agile Software Development (2013). In Wikipedia, the free encyclopedia. Retrieved from 2013 from http://en.wikipedia.org/wiki/Agile_software_development
Alverdyan, N. (2011). The Definition of Done. Retrieved from http://alaverdyan.com/readme/2011/01/the-definition-of-done-dod/.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile Software Development, Retrieved from http://www.agilemanifesto.org/.
Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Twelve Principles of Agile Software, Retrieved from http://www.agilemanifesto.org/principles.html.
Brown, R. (2009). The Value of an Agile Coach, New York: Agile Coach Journal, Retrieved from http://www.agilecoachjournal.com/index.php/2009-10-15/scrum/the-value-of-an-agile-coach/.
Burn Down Chart (2011). In Wikipedia, the free encyclopedia, Retrieved from http://en.wikipedia.org/wiki/Burn_down_chart
Cohn, M. (2012). Agile Succeeds Three Times More Often than Waterfall. Retrieved from http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall
Cohn, M. (2010). Choosing to Start Small or Go All In when Adopting Agile, Retrieved from http://www.mountaingoatsoftware.com/articles/choosing-to-start-small-or-go-all-in-when-adopting-agile
Griffiths, M. (2007). Using Earned Value on Agile Projects, The Project Management Hut, Retrieved from http://www.pmhut.com/using-earned-value-on-agile-projects
Highsmith, J. (2001). History: The Agile Manifesto. Retrieved from http://agilemanifesto.org/history.html.
IEEE (2006). IEEE 12207-Standard for Information Technology—Software life cycle processes, New York: The Institute of Electrical and Electronics Engineers, Inc., p 50.
Lean Kit (2013). Kanban Board Graphic, Retrieved from http://leankit.com/product-tour/.
Murphy, T. & Duggan, J. (2012). Magic Quadrant for Application Life Cycle Management, Stamford Connecticut: The Gartner Group, Retrieved from http://my.gartner.com/resources/218000/218016/magic_quadrant_for_applicati_218016.pdf?li=1.
Project Management Institute (2013). The Standard for Program Management – Third edition. Newtown Square, PA: Author.
Ryder, N. (2009). Eight Causes of Project Failure, Retrieved from http://www.pmhut.com/eight-causes-of-project-failure.
Quantitative Software Management Associates (2008). The Agile Impact Report - Proven Performance Metrics from the Agile Enterprise, QSMA for Rally Software Development Corp. Retrieved from www.rally_dev.com
Salinas, E., & Boyne, L. (2012). CSC Hybrid Waterfall Agile Development for the Federal Space, Published as part of the 2012 PMI Global Congress Proceedings —Vancouver, Canada.
Smits, H. (2006). 5 Levels of Agile Planning: From Enterprise Product Vision to Team Stand-up, Retrieved on 25 from https://www.rallydev.com/search/site/5%20levels%20of%20agile%20planning.
Teng, E., Mitchell, C., & Wathington, C. (2011). Agile ALM White Paper: Redefining ALM with Five Key Practices, Retrieved from http://www.thoughtworks-studios.com/sites/default/files/resource/redifining_alm.pdf.
VersionOne (2011). Agile Development: A Manager's Roadmap for Success, Retrieved from http://www.versionone.com/pdf/Agile_Managers_Roadmap.pdf.
VersionOne (2013). 7th Annual State of Agile Development Survey, Retrieved from http://www.versionone.com/pdf/7th-Annual-State-of-Agile-Development-Survey.pdf.
West, D. (2011). Why Kanban Matters: Putting In Place The Right Signposts For Effective Delivery, Retrieved on from http://www.forrester.com/search?tmtxt=agilewaterfall#/Why+Kanban+Matters/quickscan/-/E-RES58522.
West, D. (2009). Ensure Success For Agile Using Four Simple Steps, A Simple Approach To Agile Adoption And Implementation, Retrieved on from http://www.forrester.com/home#/Ensure+Success+For+Agile+Using+Four+Simple+Steps/fulltext/-/E-RES54037.
West, D. (2009). Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today. Manage The Water-Scrum And Scrum-Fall Boundaries To Increase Agility, Retrieved from http://www.forrester.com/search?tmtxt=agilewaterfall#/WaterScrumFall+Is+The+Reality+Of+Agile+For+Most+Organizations+Today/quickscan/-/E-RES60109.
Zaleski, P., Bostian, C., & McDyer, C.J. (2011). Balancing Agility with Conformance on Complex Government Programs, Computer Sciences Corporation © 2011, Published as part of the 2011 PMI® Global Congress Proceedings—Dallas/Ft Worth, Texas.
© 2013, James F. Carilli
Originally published as a part of 2013 PMI Global Congress Proceedings – New Orleans, Louisiana