Research and Refine Research Topic

Agile_an_Executive_Guide_----_Pages_76_to_100.pdf

Home >Business & Finance homework help >Operations Management homework help >Research and Refine Research Topic

3: Five Steps to Agile Success

need to choose projects that are important enough so that their success will be meaningful to the organization. Achieving great results on trivial projects will only serve to fuel resistance from others in the organization who may believe that Agile methods are not applicable to their IT projects.

Is your objective to mandate the immediate use of Agile methods for all software development work across the organization? If so, you will need to review the information about organizations who have successfully achieved this in the Choosing the right method of introduction section.

Is your objective to use Agile methods to begin to shift the organizational culture towards a more open and collaborative environment? If so, you may want to start with the path of least cultural resistance by choosing an area of the organization which (or a particular manager who) is most likely to be amenable to working closely with stakeholders, trusting and empowering teams, and measuring success through the production and demonstration of tangible results.

Once you have selected the project(s) that align with your core objectives, the next step is determining which Agile methods and practices are best suited to the needs of the selected project(s).

Choosing the right methods and practices

Agile methods are not a ‘one size fits all’ proposition. For these approaches to deliver genuine business value to your organization, it is important to find the right Agile method (or

Cooke, Jamie Lynn. Agile: an Executive Guide, IT Governance Ltd, 2016. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=4519661. Created from harrisburg-ebooks on 2020-11-11 04:39:55.

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

combination of methods and practices) to address your specific challenges, your KPIs and your culture. It is equally important to work with the selected project teams in making this decision.

The Agile methods selection workflow tool in Figure 2 takes you through some of the key questions that you need to ask in order to select the most appropriate Agile methods and practices for each of your selected projects.32

It is important to note that the Agile methods selection workflow tool is only a guideline for you to use as a starting point in selecting the methods and practices that are more likely to be suited to the unique requirements of your project and your organization. Your ongoing use of these approaches is the definitive indicator of how well they meet your needs.

32 The Agile methods selection workflow tool only addresses the ten Agile methods described in the Common Agile methods section of Chapter 1. It does not include Disciplined Agile Delivery, Crystal or other methods which may be equally valuable to your organization.

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

F ig

ur e

2: T

he A

gi le

m et

ho ds

s el

ec ti

on w

or kf

lo w

to ol

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

To use the Agile methods selection workflow tool, start with the question in the upper left-hand corner:

New Software Development or Maintenance Work?

If the project that you have selected is a new software development, then go to the Stakeholders Available? question below.

If the project is predominantly a maintenance activity, then the next question to consider is whether or not the maintenance work will include the development of Enhancements or Bug Fixes?

If the project is a maintenance activity primarily for bug fixes, you may be best off starting with Kanban or Scrumban to manage this work.

If the project is a maintenance activity that includes a significant number of enhancements, you may decide, instead, to treat these enhancements as new software development; in which case, you will want to go to the Stakeholders Available? question in the following section.

Stakeholders Available?

Almost every aspect of Agile methods requires involvement from the stakeholders (e.g. business areas, customers) who will be using the delivered software. If these stakeholders are unavailable (and your organization is not in a position to make them available, or to organize for other resources who can adequately represent their interests), then your options for using Agile methods are

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

extremely limited. Therefore, if the answer to the Stakeholders Available? question is No, the project team may be able to utilize some selected Agile practices, such as daily stand-up meetings, time-boxed work, pair programming or test-driven development, to enhance the quality and throughput of their development work; but the substantial benefits of using Agile methods to deliver usable software solutions that directly align to customer needs will not be achieved.

Single team or multiple enterprise-wide teams?

If you intend to implement your selected Agile method within a single development team, then go to the How big is the team? question below.

If you intend to implement Agile methods across multiple enterprise-wide teams, you may want to consider using one of the scaled Agile methods, such as SAFe®, Scrum of Scrums, the Large Scale Scrum (LeSS) framework or Nexus. Ideally, you will have successfully implemented Agile methods on a smaller scale before endeavoring to implement a large scale Agile initiative. This allows you to leverage the lessons learned, the skills acquired and the cultural adaptations made at a smaller scale, which will increase the likelihood of successfully integrating Agile work across multiple teams - and decrease the potential for unaddressed issues to grow exponentially.

How big is the team?

It is generally believed that the ideal size for a single team using Agile methods, such as Scrum,

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

is four to eight team members (although this is not a hard-and-fast rule). If your intended team has four to eight members, then go to the Need substantial documentation produced? question below.

If you have fewer than four members on your team for the selected project, it may be better for your organization to consider using selected Agile practices (noting that at least two coders will be required for pair programming).

If you have more than eight team members, you may want to consider breaking down the teams into groups of four to eight, and then scaling the project work for the selected Agile method(s). Alternatively, you can opt to progress as a single, larger team and select the most appropriate Agile method by progressing to the Need substantial documentation produced? question below.

Need substantial documentation produced?

The final question to ask yourself is whether or not the organization (or you personally) prefer for the work undertaken by project teams to be substantially documented throughout the process. If so, it may be better for you to use Agile methods such as DSDM, FDD™ or RUP® which mandate the generation of work products, such as requirements specifications and domain models, as part of the process. Otherwise, it may be better for you to start with methods such as Scrum, Lean, AUP, Scrumban or XP™ (or combinations of these), as they are more flexible to accommodate each team’s preferred work practices and levels of documentation.

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

If you have selected more than one project as your starting point, it may be valuable for you to trial two or three different Agile methods at the same time to see which is the best fit for your organization.

Last, in selecting Agile methods for your organization to trial, you need to be prepared to allow staff to adjust and modify their use of these methods to achieve their optimal levels of productivity as their work progresses. For example, project teams may not, at first, be comfortable with committing to the two- to four- week delivery cycle of Scrum; in which case, the team may be better off using a six- to eight-week cycle as a starting point. Equally, team members may not have enough information at hand to do the value stream mapping that Lean requires, but they may be able to identify and address immediate areas of waste in the current software development processes. The key is to give teams the power to adapt the practices of Agile without jeopardizing the underlying principles. (See the Avoiding common traps section for further detail on the perils of the misapplication of Agile methods.)

Choosing the right method of introduction

In a perfect world, the introduction of Agile methods within your organization would be achieved through an organization-wide mandate where staff readily embraced and adopted these approaches. In reality, however, the opportunity to achieve organization-wide Agile adoption as a starting point may be rare, but it is not impossible.

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

BT Innovate & Design provides a classic example of an organization who successfully achieved organization-wide Agile adoption courtesy of a forward-thinking executive who, in 2004, established a mandate that the organization produce business value every 90 days. 33

It should be noted that the BT example is an exceptional situation. It is far more common for Agile methods and practices to be introduced to an organization by the team members themselves, often without the active awareness (or support) of senior management. (You may, in fact, be surprised to learn that there are IT project teams within your organization who are already using Agile.) This ‘Agile by Stealth’ approach is generally not the team’s preferred way of introducing Agile within the organization; they would much rather have your support and backing for this work. Instead, this approach is likely to be perceived by the team members as a necessary way to ensure that they can progress with these practices ‘under the radar’ without provoking management resistance or challenging the traditional approaches of the organization.

If, in your discussions with prospective Agile teams, you find that they have already been utilizing these methods, you are likely to be one step ahead of the game. In most cases, these teams will not have definitive ROI metrics for the work 33 Details on the approach that BT successfully used is provided in the Avoiding common traps section of this chapter, with further details available at Agile Coaching in British Telecom, Meadows L and Hanly S (2006): www.agileconnection.com/article/agile-coaching-british- telecom

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

http://www.agileconnection.com/article/agile-coaching-british-telecom

3: Five Steps to Agile Success

that they have done to date (see Establishing your baseline and Monitoring your investment for further detail on measuring ROI). They are, however, likely to have a number of work products, including Agile communication tools, delivered software, and stakeholder testimonials, which can indicate how well their selected Agile methods worked. They are also likely to have acquired a substantial amount of knowledge about what does – and does not – work within your organizational culture. All of this information can be applied to selecting the best ongoing approaches for your organization to use, including the expansion of the team’s Agile work with the benefit of your support.

If your organization is not planning to issue organization-wide mandates to adopt Agile, and you have not been fortunate enough to unearth Agile success stories within your organization, the next best thing is the selection of one or more trial projects, using the guidelines in Choosing the right project(s) section. Tracking and documenting the outcomes of these trial projects can be used as the basis for persuading other areas of the organization to consider Agile methods for their projects. (See the Expanding Agile section for further details.)

You may also choose to position yourself as an Agile champion within the organization, using industry case studies (such as Microsoft™ and Yahoo!™) and industry research (such as VersionOne™) to support your decision to trial these approaches. Your awareness of Agile methods, coupled with your influence, can help to position Agile teams to avoid the most common traps that organizations encounter in their

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

implementation of Agile methods, as described in the following.

Step Two: Avoiding common traps

The simplicity and low overheads that make using Agile methods so appealing, also make them highly susceptible to misapplication. The following identifies some of the most common traps that organizations have fallen into when implementing Agile.

Undermining Agile principles

There is a difference between adapting Agile to suit the preferred work practices of your organization (e.g. adjusting iteration timeframes, using videoconferencing instead of face-to-face meetings), and adapting Agile in a way that contravenes the underlying principles that drive its effectiveness.

One example is an organization that moves to an 'Agile' iteration-based project management model, but still requires all of the work to be signed-off in an up-front specification. Agile methods are only valuable when the organization is in a position to adapt ongoing work as it progresses. Otherwise, iterative work just becomes shorter delivery cycles that are limited by the same core constraints; and Agile methods get an unjustified bad reputation when this pre-constrained process inevitably fails.

Similarly dangerous is an organization that applies a handful of Agile practices (e.g. daily stand-up meetings, test-driven development) without the benefit of the core elements of each Agile method,

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

such as stakeholder confirmation of requirements, or the ongoing adjustment of work to accommodate emerging information. In the Agile methods selection workflow tool, it was identified that, for projects without stakeholder availability, the use of selected Agile practices may be the only option available to the team. By using selected Agile practices, however, the outcome is likely to be a somewhat more efficient traditional software development process, not an Agile project.

Insufficient communication and/or training

In order for Agile to be effective, participants (stakeholders and project team members) need to be educated on the principles and practices of the selected method. Otherwise, they (and the organization) are likely to fall victim to the areas of misapplication identified in the previous section.

In Choosing the right method of introduction, the Agile work undertaken at BT Innovate & Design was referenced as a classic example of the successful organization-wide adoption of Agile based on a top-down executive mandate. What was not mentioned, however, was how this success was achieved.

When the CIO of the organization established the mandate for the use of Agile throughout the organization, he coupled that mandate with a series of training and communication initiatives to educate staff on Agile principles and practices. These initiatives included training and learning events (e.g. roadshows), assigning Agile coaches, and creating The BT Agile Cookbook as an online

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

reference guide for staff. BT’s continued use of these practices in the organization several years later is a testament to the power of both initial and ongoing communication – as well as the importance of genuine management commitment – in the successful implementation of Agile.

When introducing Agile in your organization, it is important to consider how Agile principles and practices will be communicated to staff. One cost- effective way to achieve this is by including an Agile resources page on your corporate intranet that provides links to relevant sites, and allows staff to exchange their questions, concerns and ideas about the use of these methods before work begins.

Alternatively, your organization may benefit from more formal guidance on adopting and applying Agile methods. There are a number of formal training courses available to teach people how to more effectively apply Agile methods. In some cases (e.g. Scrum) there are even certification courses that staff can attend.

All of these communication approaches help to assure you that your selected Agile methods are being utilized to the greatest advantage of the organization.

Using Agile as a doctrine instead of a tool

This last common area of misapplication was alluded to in Choosing the right kick-off point: following Agile as a strict doctrine without adapting it to the needs of your organization. To receive the greatest benefit from using Agile methods, it is important to allow your staff to

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

adjust and modify their use of these methods in a way that fits in with their preferred work practices. That is, so long as the underlying principles of Agile are not compromised.

As you are introducing (and trialling) Agile methods within your organization, it is valuable to consider the advice provided by the author of Kanban and Scrum: making the most of both34 who noted that:

Scrum [Agile] is just a tool. You choose when and how to use it. Don’t be a slave to it!

However you and your staff choose to introduce Agile within your organization, you can (and should) adapt it to suit your specific needs. By its very nature, Agile methods are meant to be, well, agile.

Step Three: Establishing your baseline

Throughout the previous chapters, the term ROI metrics has been used as a mechanism for quantifying the business value that Agile methods can deliver to your organization. The following gives you a step-by-step approach for identifying the quantitative and qualitative value of your current work as a baseline for measuring the impact of implementing Agile methods for your future projects.

34 Kanban and Scrum: making the most of both, Kniberg, Henrik (2010): www.infoq.com/minibooks/kanban- scrum-minibook

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

http://www.infoq.com/minibooks/kanban-scrum-minibook

3: Five Steps to Agile Success

Calculating the net business value of current project work

In order to measure the comparative ROI value from the implementation of Agile, your organization needs to be able to assess and record the net business value of equivalent work activities prior to its introduction. For example, a software project, which was delivered using your current software development processes, and which is similar in scope and complexity to the software that is being proposed for your intended Agile project (i.e. your ‘comparison project’). The business value of your comparison project can then represent the baseline for future ROI comparison.

Identifying the potential quantitative net business value return on your Agile investment is, from my experience, contingent upon four primary factors:

• the business value that your software solutions generate

• your current costs to develop and implement software solutions

• your current costs to support, maintain and extend the software solutions that you deliver

• your current costs in managing staff turnover.

In order to baseline the quantitative net business value of your comparison project, you will need to gather the following metrics:

• a quantifiable business value for that project’s delivered software features, based on revenue generated and/or reductions in operational overheads (software value)

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

• the overhead costs for software development and implementation on that project, e.g. staff, accommodation, equipment (delivery overhead)

• the non-recoverable35 overhead costs for software support, maintenance and extension of that project (non-recoverable support overhead)

• the average cost for replacing an IT staff member who has left the organization (IT staff turnover cost)

• the percentage of IT staff turnover that can be reasonably aligned to the resources allocated to that project (IT staff turnover percentage).

Then apply these metrics, using the following software project net business value formula:

Figure 3: Software project net business value formula

35 As many IT projects pre-allocate funding for warranty period work and/or charge back annual support costs, non-recoverable costs refer to the portion of software maintenance work that cannot be recovered from allocated funds. There is, however, an argument to say that pre-allocated funding for software support should be focused on upgraded features and enhancements; in which case, the cost of bug fixes within these funds should also be considered non-recoverable.

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

The resulting figure represents the quantitative net business value for your comparison project.

To provide you with the most complete assessment of business value, these quantitative metrics should be coupled with qualitative metrics on:

• how satisfied your stakeholders (external customers, internal business areas) are with delivered software

• how satisfied your IT staff members are with their current work environment

• how often teams are working overtime or ‘fire- fighting’ to address software problems.

Compensating for insufficient metrics

The purest ROI comparison scenario would involve the establishment of two identical projects, each using the same objectives, the same budget allocation and the same number of employees, in the same timeframe: where one would be undertaken using your organization’s current software development processes; the other, using your selected Agile method. In order to minimize the impact of external factors, this scenario would also involve the isolation of staff from all other commitments during this time. In my 25 years of working in the industry, however, I have never encountered a situation that supported this scenario.

More realistically, organizations tend to find themselves with a combination of the following baseline information sources for their current projects:

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

• high-level budget reports (e.g. department or project expenditure breakdowns)

• incremental project status reports (with minimal quantitative metrics)

• sales figures and customer surveys (for commercial organizations with released software)

• issue registers and, where software is in production use, support logs

• anecdotal evidence of the success or failure of software development projects.

Therefore, in order to baseline the quantitative net business value for your comparison project (i.e. business value; costs for development, implementation, non-recoverable support and maintenance; and staff turnover), you need to determine whether the metrics that your organization currently record are sufficient.

If you can confidently assess (or reasonably estimate) your comparison project costs, then you should be well positioned to calculate your Agile ROI on an equivalent project undertaken using Agile methods.

If you are not confident that your comparison project costs can be sufficiently assessed, then you need to decide if:

• you are comfortable proceeding with partial baseline information

• you would like to track the business value of your proposed Agile implementation without a baseline comparison

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

• you would prefer to gather baseline metrics on a current (or planned) software project before proceeding with the Agile implementation.

If you do decide to proceed with the information at hand, it may be valuable to establish a framework for tracking the quantitative net business value of Agile projects on an ongoing basis, so that you can measure the relative effectiveness of selected methods, as well as any changes in the levels of productivity and business value produced as staff become more familiar with these approaches.

Step Four: Monitoring your investment

Once you have established the baseline metrics for your current work (or have identified an alternative approach where your current metrics are insufficient), you are in a position to begin assessing the comparative value of your Agile work.

Tracking the progress of your Agile projects

Monitoring the business value and progress of your Agile projects can begin from the moment the project starts, and continue well before the whole-of-life quantitative net business value is evident.

Agile methods provide a number of mechanisms for tracking progress, including formal reports (e.g. executive dashboards), status update tools (e.g. WIP boards, product backlogs, sprint backlogs), and ongoing communication with stakeholders. Arguably, however, the most valuable measure of the Agile team’s progress is their delivery of tangible outputs. For iterative

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

Agile methods, such as Scrum and FDD™, the presentation of working software occurs at the end of each iteration. This means that, at fixed timeframes (generally once a month), you are able to see firsthand whether these approaches are delivering their anticipated business value.

Equally important, the teams themselves are able to use Agile tools to monitor their own progress during each iteration, and to adjust their ongoing work as needed to meet their agreed commitments.

It is interesting to note that the timing of four- week iterations aligns closely with the timing of monthly reports. This means that Agile teams may be able to use the presentation of working software at the end of each four-week iteration to report on their progress in conjunction with the standard reporting cycles for the organization overall (where required).

Comparing Agile to your current software development processes

If you have baselined the quantitative net business value for your comparison project (see Establishing your baseline), then comparing that project with the quantitative net business value of an equivalent Agile project is a straightforward ROI calculation – well, almost.

Retrospective comparison between two software solutions that are both in a production environment is reasonably achievable, as long as the variables (e.g. length of time in production) can be normalized.

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

The challenge (or opportunity) arises when comparing traditional software development projects that are in progress with equivalent Agile projects. The whole-of-life costs for software (including ongoing maintenance, support and extension costs) are not able to be measured until after the software has been released. For traditional software development projects, this is generally only available at the end of the process, i.e. when the complete software solution is implemented in a live production environment. For Agile projects, particularly ones using iterative approaches, software features can be released for production use on an ongoing basis. This means that you are in a position to track quantitative net business value of your equivalent Agile project well before that information is available for your comparison project. For this reason, it is recommended that your selected comparison project be a historical project (i.e. one that is already in production).

A cautionary note: As explained in the Your Agile ROI section of Chapter 2, the most relevant ROI calculation for your organization is not likely to be a side-by-side comparison of software development costs for projects using traditional processes versus Agile methods; it is a side-by- side comparison of the whole-of-life costs of developing, maintaining, supporting and extending each of these software solutions.

Thus far, the focus of the comparison between traditional and Agile software development projects has been focused on the relative quantitative benefits between these approaches. It

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

is just as (if not more) important to compare the qualitative benefits as well, including:

• the impact that each approach has had on employee motivation, camaraderie and job satisfaction, particularly for the project team members

• stakeholder response to the usability and relevance of the delivered software

• the impact that each approach has had on management.

Many of the benefits of Agile go well beyond what can be tracked on a balance sheet.

Comparing business value across Agile methods

If you have established a framework for tracking the quantitative net business value of Agile projects, then comparing your ROI across different Agile methods is also a relatively straightforward calculation. The important distinction is that you need to find a reasonable ‘apples-to-apples’ comparison between equivalent Agile methods. For example, Scrum and DSDM are both centered around iterative project delivery based on stakeholder feedback, so it is reasonable to compare outputs from these two methods side-by- side. Conversely, XP and Kanban are Agile methods with different functions (and outputs) to iterative project delivery. Therefore, it is more difficult to establish a meaningful ROI comparison between these Agile methods and iterative project delivery methodologies.

In comparing different Agile methods, it is especially important to compare the qualitative

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

benefits as well, particularly to identify project team and stakeholder reactions to each method. Were staff happier with the formal documentation structure of DSDM, or did they find that Scrum tools and practices were sufficient to communicate requirements? Were they comfortable using the pair programming practices of XP? What were the biggest challenges in each method? Are there any areas where they would like more formal training or expert advice (e.g. how to manage a product backlog)? Staff input is critical to undertaking the Agile evolution tracking activities described in the following section.

Tracking Agile evolution

As identified in Your Agile ROI, when you first introduce Agile methods in your organization, there are likely to be additional overheads associated with training and knowledge sharing; establishing supporting technologies (e.g. automated testing environments); and establishing centralized locations for project teams to work and collaborate. As Agile work progresses, staff members will become more comfortable with (and proficient in) these practices, and the methods that they use will most likely be adapted to work more effectively in your organizational climate. All of these factors contribute to the ability of Agile methods to provide the organization with even greater business value as they evolve.

The framework that you have devised for tracking the quantitative net business value of Agile projects becomes a toolset that you can use to track the relative net business value of initial Agile projects against projects run by established Agile

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

teams. This not only enables you to see progress in your Agile work, it provides you with a mechanism for undertaking predictive analysis if you decide to extend the use of Agile in your organization. (See Expanding Agile for further details.)

In addition, the qualitative metrics that you have been gathering for each Agile method (e.g. what challenges the teams faced and how they overcame them) can be transformed into guidelines, lessons learned and customized training materials for staff to use in other Agile projects.

Don’t be fooled by the numbers

Although this section focused primarily on identifying baseline ROI metrics for quantitative comparison, monitoring your Agile investment is much more than a numbers game. Comparative whole-of-life software development costs will give you an indication of the bottom-line business value of Agile, but they will not help you to find the root cause of software errors, usability issues and misalignment with business requirements; nor will they help you to understand the team’s dynamics or frustrations. These indicators tend to emerge in more insidious ways, as emergency software patches, lost customers, or valued members of your IT staff deciding to leave the organization. Successfully addressing these issues is the immeasurable benefit of Agile methods.

Step Five: Expanding Agile

After your organization has had the opportunity to trial Agile methods for a few months, it is valuable

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

for you to step back and ask yourself the following questions:

• Is work being done more efficiently? • Are the stakeholders getting the outcomes that

they need? • Are employees happier to be working in a

high-communication environment, rather than in a documentation-centric one?

• Is the quality of their work better than before?

The answers to these questions – in addition to the ROI comparisons described in the previous section – should provide you with sufficient information to consider broadening the use of Agile methods to other areas of the organization. (Or, conversely, to decide that Agile methods are not suited to your organization and should not be extended further; in which case, the low start-up costs of Agile have enabled you to make that decision without foregoing a huge up-front investment.)

If you decide to expand the use of Agile methods to other areas of the organization, the next step is to establish a strategy for broadening awareness of the value of Agile methods across the organization – and for encouraging other areas to trial these approaches.36

This strategy should include four key elements:

• Education: communicating with the organization on the quantitative and qualitative business value of Agile methods (using your

36 That is, unless you decide to issue an organization-wide Agile mandate, as BT did.

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .

3: Five Steps to Agile Success

100

ROI metrics, team feedback, etc.). This can be done through: o internal ‘roadshow’ events to show

people the tangible outcomes from your Agile work

o your corporate intranet (as described in Avoiding common traps)

o documenting the outcomes of your trial project as a case study for other groups in the organization.

• Motivation: using the information above, along with your influence, to encourage specific people in the organization to trial these methods in their areas (e.g. those who are more open to trying new approaches, or those who have had historical problems with their software development projects).

• Selection: helping interested areas of the organization in selecting the Agile method(s) that are best suited to their activities (using the Agile methods selection workflow tool). The metrics gathered in the previous section can also help these areas to undertake predictive analysis on initial and ongoing costs and ROI benefits for each method.

• Collaboration: providing assistance (and, where appropriate, experienced Agile team members) to help each area in the initial application of these methods. This includes educating the area on the principles and practices of their selected Agile method via: o an easy-to-use guide that explains the

basics of Agile methods (such as the ‘Agile Cookbook’ that was created by BT)

C op

yr ig

ht ©

2 01

6. IT

G ov

er na

nc e

Lt d.

A ll

rig ht

s re

se rv

ed .