An Enterprise Strategy for Introducing Agile: Part 2 – A plan of Action

As Agile methodologies gain wider acceptance, they will be taken up by larger numbers of organizations. The question of how to introduce an Agile methodology into an enterprise with the least amount of risk will become more and more common. The two approaches that are typically talked about are Top-Down, where senior management take the initiative to introduce Agile, and Bottom-Up where developers and testers take the initiative to introduce Agile.

The truth of the matter is that both of these approaches have flaws. The successful approaches that I’ve witnessed have used some combination of both the Top-Down and Bottom-Up approaches. Agile software development practices can force large changes in the corporate culture, and making the change to an Agile organization is only possible if there is support from all parties involved.

Ultimately, there needs to be some coordination of both these efforts. There needs to be some planned approach to deal with concerns raised by those who do the work, in addition to those who lead the organization and make the strategy a reality.

From The American Heritage® Dictionary of the English Language, Fourth Edition:

strat•e•gy n. pl. strat•e•gies
1.1 The science and art of using all the forces of a nation to execute approved plans as effectively as possible during peace or war.
1.2 The science and art of military command as applied to the overall planning and conduct of large-scale combat operations.
2. A plan of action resulting from strategy or intended to accomplish a specific goal. See Synonyms at plan.
3. The art or skill of using stratagems in endeavors such as politics and business.

I’m working under the the second definition: “A plan of action … intended to accomplish a specific goal.“. In this case the specific goal is the complete rollout of an Agile methodology to an entire organization.

This plan of action is broken down into three different phases. I’ve separated out the different phases based upon scope of influence ever increasing outwards, like ripples on a pond. In the Pilot phase only a limited number of individuals are directly affected and the projects are limited in scope and risk. In the Launch phase an entire department (many people, and multiple projects) may be effected, but the rollout at this point is still confined within the department. The final phase is the Enterprise Rollout phase where individuals in across multiple departments are affected and projects involve significant budgets and risk to the organization.

Each phase is outlined below with a description and a list of activities that are commonly performed. For each of the activities, I’ve also associated a number of the questions that need to be addressed. The reason that I’ve listed the questions (without the answers) is simply because every organization is different, with different problems, personalities and requirements. Some organizations will have to answer many of these questions in order to be successful, while others will only need a few.

Phase 1. The Pilot
The Pilot phase is mostly concerned with the immediate rollout of Agile practices to a known team. Concern is often centered around how best to adopt Agile practices and answering practical Agile questions such as how granular should backlog items be, how do we write stories, how do we integrate QA, etc.

They pilot phase will typically last between 6 months and a year and will involve only a small number (between 5 and 10) of experimental projects. These projects will have similar profiles. They will be limited in budget (which implies limits in duration and staffing numbers), scope and risk. These projects will typically be focused on delivering functionality to an internal client [limiting external exposure], and will have few (if any) dependencies.

Activities undertaken (and questions that need to be addressed) during this phase should include:

  • Introduce Agile software methodologies to several small teams using coaches. Should the coach be CSM certified? Is it possible to certify an existing project manager and then have him/her act as the Scrum Master? How many teams can a Scrum Master manage at a time? How large should those teams be?
  • Introduce Agile practices and terminology to the teams. What terminology should the team use? Scrum, XP or some combination of both?
  • Identify likely cultural issues and organizational impediments. Is there some group or individual who feels most threatened by the introduction of Agile methods? Is there a Methodology or Software Development Process group?
  • Identify tool issues. Are the tools quick, efficient, reliable and leave the code base in a known state? Or are the tools clumbersome and require extensive baby-sitting? Do the tools meet the needs of the team, or is there an alternative solution which better meets their needs? Is the choice of tools made by the developers, or by some third party that isn’t responsible for delivering code?
  • Identify likely IP issues (Opensource tools, GPL code). Does the organization have a fear of GPL code? Is there a tendency for the organization to re-develop tools that already exist in the marketplace?
  • Identify Management issues. How do functional managers (ie QA Managers, Software Analysis Manager etc) fit into a Agile model? Who should be the Product Owner be, and what should the team do if the Product Owner doesn’t want to engage with the team?
  • Identify and resolve reasons for initial failures. What made some of the initial Agile project successful? And how should the failed projects be addressed?
  • Physical location and layout. How important is collocation to Agile projects? Can teams retain their offices and communicate via IM and/or email? What about teams in different locations or time zones?
  • Present Agile to interest parties and Senior Management. Who should know about the benefits that Agile software development can bring? How should they be educated, in a series of lectures? By presentations from the team?
  • Have Senior Management promote Agile SW.

Phase 2. The Launch
The Launch Phase is focused on how best to rollout Agile methodologies to a much wider audience in a uniform and consistent manner. The natural consequence of this is that the Launch Phase is characterized by substantial codification of the organizational understanding of Agile. This codification will try to address issues such as how long should an iteration be, what tools should Agile teams use, and what formats should Agile teams use for reporting progress.

Projects in this phase are usually much larger [than those in the Pilot Phase] in terms of budget, scope and risk. A larger budget means that these projects will also have a larger number of staff and longer durations. The types of project addressed in the Launch Phase will typically be a cross-section of projects that are typically undertaken within a single department. They will likely address many different aspects of the organizations business such as projects to address new functionality, software maintenance, database maintenance and reporting.

Activities undertaken (and questions that need to be addressed) during this phase should include:

  • Codify the Organizations understanding of Agile. This includes establishing:
    1. Usage of common Terminology. What does a Sprint mean, or an Iteration? What is the Scrum equivalent of Iteration 0?
    2. Usage of common metrics. What scale should the teams use for estimating story points, a scale from 1 to 10, a scale from 1 to 5, or something else? What is the meaning of velocity and should the organization compare velocities between two different teams?
    3. Usage of common Tools. What source control tool should the teams use? Should all the teams be using some form of Continous Integration, and if so which tool? What about IDE’s and code coverage tools?
    4. Usage of common reporting formats. Should the teams present their results as Burn Down charts? Is there any value to Gantt charts, or M$ Project?
  • Formally Establish a coaching model. What is the organizational coaching model? How should coaches be brought on board and what career path should they follow?
  • Establish an office layout/collocation policy. Are teams co-located? Is there sufficient space to create team rooms, and is there an expense involved with collocating teams?
  • Establish Agile Forums within the Organization. What are the best ways to ensure different teams are communicating their experiences? Should this be an informal event, or should there be some ceremonial process?
  • Establish Agile project selection and project scoping (size and cost). What projects are there that would be suitable for Agile software development? What criteria should be applied to the project selection process? How should you use Agile methods to estimated the size and cost of these projects.
  • Present Agile methodologies to interest parties and Senior Management. Who within the organization would help promote Agile methods? Who should be educated about the benefits that Agile methods can bring to the enterprise?

Phase 3. The Enterprise Rollout
The Enterprise Rollout Phase is characterized by focus on: communication between projects in different departments; the management, organization and running of very large projects that comprises of multiple scrum teams; and issues related to compensation, responsibilities and promotion. These challenges will be the most difficult to resolve and will require considerable persuasive and political skills.

The projects that are typical in this phase of Agile adoption are large and expensive with the potential for a great deal of risk. They may be projects that have multiple scrum projects and managed with a Scrum-of-Scrum, or may involve some element of distributed software development. The Enterprise Rollout phase is usually much longer the either of the previous two phases. It is possible for projects in each of the previous phases to be initiated and completed within a 6 to 9 month period (depending upon the number of people impacted, the types of issues raised etc). Projects in the Enterprise Rollout phase, however, may last anywhere from 1 to 2 years.

Activities undertaken (and questions that need to be addressed) during this phase should include:

  • Encourage internal communication regarding Agile. What is the best approach for encouraging internal communication between different Agile teams, an Agile Forum? Or perhaps an email list is sufficient.
  • Anticipate change and have a plan to evaluate changing circumstances. A new application is getting more traffic than anticipated. How can you exploit that to your best advantage?
  • Review and Align Compensation Model with Agile teams. Is everyone on the team adding value? How should project managers who don’t facilitate a team (Scrum or Scrum of Scrums) be compensated? Is an architect who mentors a team more valuable than one that does not?
  • Review HR and Hiring policies. Are your existing hiring practices sufficient to find skilled staff that work well in an Agile environment? Does the team have any say in who joins the team? Or who should leave a team?
  • Establish parameters around very large projects with Agile. What qualifies as a large project and at what point should a project be broken down into two or more sub-projects? Are there additional (financial) constraints that larger projects must meet? In a large project, who represents the Product owner? Should there be a single Product Owner or is it okay to have multiple Product Owners.
  • Establish parameters around distributed projects with Agile. How experienced should the team be? How is communication between teams handled, and what about the Product Owner? Should he be located with the business or with the development team? Should the entire business be relocated to somewhere more cost effective?
  • Establish promotion policies. How should successful individuals be promoted? Should the promotion model be based on merit, influence or some combination of both?
  • Establishing Training model for Coaches/Agile teams. What are the training requirements of Agile teams? After doing some initial training, what else should Agile teams know?
  • Align funding with lines of business. Funding for Agile teams is usually secured by the Product Owner. What does this mean for software development groups that have previously had their own source of funds? How will the management structure react to changes in the funding model for these departments?

If you’ve reached this point you’re either very stubborn or very interested in how Agile practices have the potential to change the enterprise. Either way, congratulations! Let me repeat my initial caution that there is some element of speculation in the material presented here. Although the initial parts of the strategy are fairly well understood (I’ve start several organizational down this path), the end results are far from certain.

The path presented above is idealized, and successfully introducing Agile methodologies into an organization is a difficult task that requires substantial experience, strong persuasive skills and a great deal of “political collateral”. If you’re heading down this path, I wish you the best of luck.

An idealized plan of action is interesting, but if it’s possible to outline a plan, is it also possible to anticipate some of the difficulties? That, coincidently, is the topic of my next post in this series.

Note: If you’re having trouble reading this article due to the formatting, you might want to try reading it on WordPress at Http:// WordPress has a better layout (than Drupal) and you might find it easier to read.

Posted in Agile
One comment on “An Enterprise Strategy for Introducing Agile: Part 2 – A plan of Action
  1. jornh says:

    … either I’m stubborn or just very interested. You decide 🙂

    I think this is a good read that supplements the “Implementation Playbook” posted in the “for CSM’s only section” (requires login) on the scrumalliance site.

Leave a Reply

Your email address will not be published. Required fields are marked *