Chapter 18: Introducing Agile Within Your Organization – Agile Productivity Unleashed, 2nd Edition

CHAPTER 18: INTRODUCING AGILE WITHIN YOUR ORGANIZATION

Although the prospect of introducing Agile approaches within your organization may seem a bit daunting at first, it can be done. Agile approaches have been used successfully by numerous organizations worldwide over the past three decades, including Yahoo!, Microsoft, Google, , Bankwest, SunCorp and Wells Fargo. These approaches have been equally successful in commercial, government and not-for-profit organizations of all sizes,60 particularly throughout the United States and Europe. Making Agile approaches work in your organization is an achievable task – it may just require some creative introduction in order to get the attention of key decision makers and the interest from staff.

Dip your toes or dive right in?

There is no one formula for introducing Agile approaches within an organization. Historically, some organizations have preferred to start by trialing Agile approaches on a small set of projects, in order to see how effective they are – and then expanding their use of Agile as staff became more comfortable with approaches, such as responsive planning. Other organizations, including the forward-thinking senior executive of BT,61 have jump-started the adoption process by instituting a top-down mandate for using Agile approaches across the organization, with the directive for all staff to deliver high business-value outcomes every 90 days.

Unless you work for an exceptionally forward-thinking organization, however, you are likely to find that acceptance of Agile approaches requires a few ‘runs on the board’ before executives will be willing to try these approaches on a larger scale. So, if you want to be in a position to apply these approaches within your organization, you need to be prepared to apply them on a few small projects, publicize the outcomes, and use their success to motivate other areas of the organization to do the same. The following section, Choosing the right kick-off point, provides some guidelines for you to use in determining the best projects to use as your starting point.

If the prospect of convincing your organization to trial Agile approaches on even a few small projects still seems out of reach, it may be easier for the organization to start off by trialing selected Agile techniques, instead of endeavoring to adopt an entire Agile approach in the first instance.

For example, your organization could begin to more directly involve internal and external stakeholders in the delivery process. This does not require formal iteration planning and outcomes review sessions; just encouraging internal and external audiences to provide more regular feedback while work is being undertaken. Applying this one technique alone could significantly improve the quality of the outputs that are being delivered, as well as provide the stakeholders with realistic expectations on what they will be receiving.

Once you have successfully enlisted the involvement of internal and external stakeholders in the delivery process (and people have begun to see the value in this technique), you can consider introducing another Agile technique, such as breaking down large deliverables in a project into smaller, achievable milestones that can be adjusted as the work is delivered to meet the ongoing requirements of the organization. This is similar in concept to iterative delivery approaches that people in the organization may already be familiar with, but the key difference is the project team’s ability (and authorization) to adapt the work that they are doing as the requirements mature, instead of blindly adhering to the originally documented upfront objectives simply because they were signed off.

Adding one Agile technique at a time can progressively move the organization into the ACTION plan without having to make a large initial commitment. In fact, for some organizations, these techniques become so embedded in the corporate culture that there is no need to give the work that they are doing a formal name. That is, of course, unless you want to officially take credit for the successful work that people are doing!

Choosing the right kick-off point

Although you can introduce Agile approaches by trickling in Agile techniques one by one, the ideal situation for more rapid adoption is for your organization to select one or two initiatives that are important enough for their success to be meaningful, but not so important that executives will not be willing to consider taking innovative approaches to fulfill the requirements. These initiatives can be anything from formal time-boxed projects (e.g. product launches, corporate events) to value-added outputs required by the organization (such as corporate reports or service improvements). In order to make their success as meaningful as possible, however, the following two criteria should be met:

  • The initiative must involve work that has a level of unknown outcomes which are dependent on the feedback provided by the internal and external stakeholders who will benefit from this work. For example, using Agile approaches to deliver a new customer satisfaction survey that determines the optimal degree of contact that the organization’s support teams should provide – versus using Agile approaches to make small, contained changes to an existing customer satisfaction survey, such as measuring the effects of changing the survey layout or the order of the questions.
  • The initiative must have a commitment from key internal and external customers (i.e. business owners) that they are willing to be involved in the delivery process for at least eight hours every four weeks. This is a pre-requisite for Agile approaches to be successful at any scale, but it is especially critical if the initiative is going to be used as a platform for demonstrating tangible outputs and business-value generation. see Chapter 8: Real-time Customer Feedback for an indication of how much time is likely to be required from each participating business owner, depending on their degree of involvement.

The intention is that the outcome of using Agile approaches to deliver these initiatives will be able to be used as the launching pad for convincing other areas of the organization to consider using these approaches in their work, which also feeds into the strategies recommended in Chapter 20: Expanding the Use of Agile in Your Organization.

Work that is too predictable (i.e. too ‘safe’) will not have the same level of impact in selling Agile approaches to the organization, even if it is successful. Work that is undertaken without the direct involvement of the business owners will inevitably vary from their true requirements (which is why the ACTION plan requires business owners to be actively involved in the process). Work that does not bring a significant enough benefit to the organization will not have the same impact in influencing executives, even when the results of the initiative are highly successful.

Even if you are in a position to influence the adoption of Agile approaches across an entire area of the organization, you may still want to begin with a few selected initiatives, so that employees can get used to the structure and dynamic of Agile approaches – and be motivated by their effectiveness – before these approaches are more broadly applied.

Agile-by-stealth

One of the five fundamental questions asked in Chapter 17: Selecting Agile Approaches That Best Meet Your Needs was the extent to which you are in a position to influence the decision to use Agile approaches in your organization. If you are in a formal leadership position, you are likely to have the discretion to make the decision within the area that you manage; however, if you are not in a formal leadership position, you may need to use an approach known as ‘Agile-by-stealth’ to get the process going.

Agile-by-stealth is a subtle way of introducing Agile approaches to an organization from the ground up. Agile approaches in the IT industry have traditionally been promoted through ‘bottom-up’ channels, that is software developers who introduced these approaches to their team leaders, who then presented them to management. Generally this involves using Agile techniques through informal channels, such as:

  • Deciding as a team that you are going to use Agile techniques within the work that you do, including:
    • doing your work in self-imposed time-boxed iterations to ensure that you are producing outcomes for the organization every two to four weeks
    • monitoring and measuring the progress of your work through velocity tracking tools such as burndown charts
    • applying lean techniques in the work that you do to ensure that you are continually focusing on the core value stream
    • establishing high-communication channels within the team, such as face-to-face meetings (instead of numerous back-and-forth e-mails) and daily stand-up meetings to check in with each other where possible
    • pairing with your co-workers on the work that you are doing, so that you can each review and critique the other’s work while it is progressing.
  • Making arrangements with one or more representatives from the business area to work with you on a deliverable as an ‘unofficial’ business owner. This person can assist you in prioritizing the work that is needed, advise you on the work as it is progressing, and do a hands-on review of the work that you have done before it is presented to other people in their business area.

Even if the successful outcomes of your work are not sufficient to convince management to consider Agile approaches more formally, you will have at least delivered higher quality outcomes than if you had been using traditional approaches to do this work.

Of course, there is always the danger that adopting selected Agile techniques without the underlying principles being agreed with management could make them more difficult to use. For example, your manager may not understand why two people need to work on something that was originally assigned to one person (i.e. pairing). Or, they might not see the need for the team to get together each morning to review the work that they have completed, the work that they are planning to do, and the issues that they have encountered (i.e. the daily stand-up meeting). In an ideal world, you can point them toward the resources listed in More Information on Agile to explain the value and worldwide use of Agile approaches. Or perhaps, consider moving to an organization that encourages employees to continuously improve the work that they do.

A shared understanding of Agile

The only way for Agile to be successful in your organization is for the people who participate in the process to be aware of both the intent and the mechanisms of using Agile approaches. This will significantly reduce the potential for the misapplication of Agile approaches that could eliminate the possibility of wider organizational support altogether.

Before you begin using Agile in your organization, you should consider how the basics of these approaches are going to be disseminated to the people who will be involved in the process.

For some organizations, the best way to educate participants is to empower them to learn about these processes themselves, through online resources and books, such as those listed in More Information on Agile. Your corporate intranet can include an Agile resources page that provides links to relevant sites, and allows the people in the organization to exchange their questions, concerns and ideas about the use of these approaches before work begins

For other organizations, sharing of information may be best achieved by creating an easy-to-use guide that explains the basics of Agile approaches (such as the ‘Agile Cookbook’ that was created by BT), and then supplementing these guides with internal training sessions to walk through and demonstrate these approaches.

Alternatively, you may want to educate a small group of staff members in using Agile approaches for one initiative, and then document the outcomes of their work as a case study to bring to larger groups in the organization.

Whichever way you decide to share this information, it is critical that participants understand both the approaches and their respective roles (e.g. business owner, delivery team member, Agile facilitator). It is equally important that they appreciate the returns that they are likely to receive from their participation – including higher business-value outcomes, empowered delivery teams and less ‘fire-fighting’ to meet their deadlines – so that they are motivated to get started.

_________________

60 See list of these organizations in the Agile in a Nutshell chapter.

61 Agile Coaching in British Telecom, Meadows L & Hanly S (2006): www.agilejournal.com/articles/columns/column-articles/144-agile-coaching-in-british-telecom.