Transitioning to Agile: Seven Strategies for Business Executives

28 March 2014


The call to action is clear: Agile projects are successful three times more often than non-Agile projects (Cohn, 2012), but as an executive where should you focus your attention to facilitate a successful start-up and an eventually successful Agile program? In order to help answer this question, I began my research with a few informal discussions and then broadened the search by conducting interviews with several program managers on Agile projects across the globe. I then collected supporting information from product and services companies, standards organizations, books, Internet searches, and research institutions.

In my research I found a common theme: In order to achieve Agile's benefits, 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. Selecting the right strategies can set the pace for a successful Agile program. The seven strategies below came up in almost every interview, and I hope that they help you and your organization successfully transition to Agile.


Strategy 1: Provide/secure management support

An executive sponsor must be in place prior to beginning a program. This is true for an Agile program or for any major organizational undertaking. The named executive provides oversight for the project, secures the finances, and is ultimately responsible for delivering the program benefits (PMI, 2013). The U.K. National Audit Office cites a "lack of clear senior management ownership and leadership" as a major cause of project failure (Ryder, 2009).

Executive sponsors generally have multiple concurrent responsibilities; therefore, they may not be available as needed. Since Agile requires timely (often daily) decisions, it is recommended to identify a deputy along with the primary sponsor. This delegate should be either granted the authority to act on behalf of the sponsor or have quick access to thr sponsor so that needs are facilitated in a timely fashion. While executive support 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. If a project is without a sponsor, following the budget should lead back to the responsible executive.

Strategy 2: Empower the business to drive the work

Information technology is a business resource, not vice versa. Representatives from business areas need to drive Agile programs; their participation is a cornerstone of the Agile approach. Lack of business involvement manifests itself in many ways. In the 2013 PMI Pulse of the Profession, a lack of strategic alignment was cited as the major source of project failure -- over 44 percent of projects failed because of lack of alignment (PMI, 2014). This lack of strategic alignment is largely due to business and IT resources not working collaboratively together.

In Agile, a product owner is the business lead who brings the customer and business perspective. This person must be provided the decision-making authority for the priority and content of software releases. When transitioning to Agile, organizations generally underestimate the impact of this consideration. Using an Agile method requires that business and IT leaders alike are empowered to make decisions and collaborate to maintain strategic alignment and keep the projects on track. If the organizational governance structure does not support this consideration, the threat of project failure is increased significantly.

Strategy 3: Embrace Agile methods

Many organizations have experimented with Agile by taking some of the best practices and applying them to traditional approaches, and then documenting this task by tailoring to their Waterfall SDLC, resulting in a hybrid Waterfall/Agile method. While this approach is more effective than Waterfall alone, unnecessary documentation is created to map the methods, slowing down the process and inhibiting the team's ability to fully realize potential benefits (Salinas and Boyne, 2012). The true value of Agile is best realized by going "all in."

Different Agile methods work better in different situations. When selecting an Agile method, it is best to select a more popular method. This will make it easier to get resources, resulting in lower training costs and facilitating a faster start-up. More than 73 percent of organizations in the Eighth Annual State of Agile Survey sponsored by VersionOne use the Scrum method or a variant (VersionOne, 2014). While Scrum is a very popular method for new development, it may not be the best method for maintenance and break/fix type development. Many organizations are using a Scrum variant like ScrumBan, linking the best of Scrum and Kanban methods for break/fix. Regardless of the method selected, be sure everyone is on board and trained and that the appropriate structure is in place to support the process.

Strategy 4: Develop multilevel plans

It is important to understand that Agile is a software development method and it does not replace organizational strategy and planning. As with traditional software development approaches, Agile is a component of the overall planning process. Hubert Smits (2006) of Rally Software Development Corp. authored a white paper entitled "5 Levels of Agile Planning." The five levels are provided below:
  • Level 1: Product Vision -- Communicates the vision of the end state
  • Level 2: Product Roadmap -- Presents a summary of the overall product plan
  • Level 3: Release Plan -- Leverages the road map for the release planning
  • Level 4: Sprint/Iteration Plan -- Planning session held to apply the prioritized backlog items to the upcoming iterations
  • Level 5: Daily Plan -- ScrumMaster facilitates a daily stand-up meeting (Scrum)
Each of the levels presented above is important to the overall success of the organization's initiatives, regardless of the software development method chosen.

Strategy 5: Acquire an Agile coach and train everyone

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 people who have no experience greatly impacts your ability to be successful. Starting with a minimum of an experienced Agile coach and ScrumMaster with Agile experience will greatly improve 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 manages and monitors the processes. Experienced Agile coaches bring deep knowledge of Agile, broad experience, impartial perspective/change agent, coaching skills, and reinforced learning (Brown, 2009).

A single experienced Agile coach alone is not enough; the team needs an infusion of experience at different levels and training for everyone -- including key stakeholders and management. Agile coaching is an established profession, and it is strongly recommended that all organizations consider hiring an experienced Agile coach to help with your transition.

Strategy 6: 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. Mike Cohn, in his article "Choosing to Start Small or Go All In when Adopting Agile," provided the following benefits of starting small (2010):
  • It is less expensive -- committing fewer resources initially helps control costs.
  • Early success is almost guaranteed by selecting trusted project team members and maintaining a small scope.
  • Lower the risk; if you start to transition your whole organization too early and you make a mistake, you will increase the opportunity for resistance.
  • Starting small can be done without reorganizing. Having only a few people join a pilot team is less disruptive to an organization.
Starting small may also reveal new challenges. For example: If an Agile team needs support from non-Agile teams, timing of releases may not align. Joint planning sessions are needed 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.

Strategy 7: Create Agile contracts

Acquiring Agile services is different than traditional (Waterfall) services. 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 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. 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 use as people are developing content rather than preparing credenza-ware documents. Version control, reuse, and administrative time should also be considered before requiring a product to be produced as a single document if the information is available and better accessed and used in another form.

Summary

In order to achieve Agile's benefits, it is important to understand that Agile requires discipline. This paper presented seven executive strategies for transitioning to Agile. They are:
  • Strategy 1: Secure/provide management support
  • Strategy 2: Empower the business to drive the work
  • Strategy 3: Embrace Agile methods
  • Strategy 4: Develop multilevel plans
  • Strategy 5: Acquire an Agile coach and train everyone
  • Strategy 6: Start small and gain early successes
  • Strategy 7: Create Agile contracts
Based on my 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.

References
Brown R. The Value of an Agile Coach. October 2009. New York: Agile Coach Journal. Retrieved from http://www.agilecoachjournal.com/index.php/2009-10-15/scrum/the-value-of-an-agile-coach/.

Cohn M. Agile succeeds three times more often than Waterfall. February 2012. Retrieved from http://www.mountaingoatsoftware.com/blog/agile-succeeds-three-times-more-often-than-waterfall.

Cohn M. Choosing to start small or go all in when adopting Agile. November 2010. Retrieved from http://www.mountaingoatsoftware.com/articles/choosing-to-start-small-or-go-all-in-when-adopting-agile.

Project Management Institute (PMI). PMI's Pulse of the Profession: The High Cost of Low Performance. February 2014. Newtown Square, PA: Project Management Institute.

Project Management Institute (PMI). The Standard for Program Management, third edition. January 2013. Newtown Square, PA: Project Management Institute.

Ryder N. Eight causes of project failure. December 2009. Retrieved from http://www.pmhut.com/eight-causes-of-project-failure.

Quantitative Software Management Associates (QSMA). The Agile Impact Report - Proven Performance Metrics from the Agile Enterprise. May 2008. QSMA for Rally Software Development Corp.

Salinas E and Boyne L. CSC hybrid Waterfall Agile development for the federal space. 2012. Published as part of the 2012 PMI Global Congress Proceedings. Vancouver, Canada.

Smits H. 5 levels of Agile planning: From enterprise product vision to team stand-up. March 2006. Retrieved from https://www.rallydev.com/search/site/5%20levels%20of%20agile%20planning.

VersionOne. Eighth Annual State of Agile Survey. 2014. Retrieved from http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf.
 


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (2 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.