agile evolution report - project management · agile implementation and have undertaken preliminary...

Benchmarks and Guidelines to improve Your effectiveness

Agile Evolution Report

RELEASED: FEbRuARy 2013

SponSoRED by

http://www.projectmanagement.com

2AGILE EvoLutIon REPoRt: Benchmarks and Guidelines to improve Your effectiveness

EXECUTIVE SUMMARY

Agile is no longer a niche tool that is used by a small number of organizations on a small number of projects. The understanding of Agile by organizations is evolving and the way that it is viewed has evolved considerably in recent years – no longer viewed with suspicion, but welcomed as a valuable project execution tool in the right circumstances. At the same time, new Agile methods have come to the forefront and talk of hybrid methods is accelerating as ways to enhance and evolve Agile approaches are sought. Within individual organizations, Agile has been expanding and maturing – and processes and tools have been evolving in response to feedback loops with varied degrees of success.In this survey, we sought to understand how Agile adoption was spreading and how Agile methods themselves were being accepted, rejected and modified. We looked into the way that Agile and waterfall were coexisting, and we asked participants where they saw shortcomings in both their implementations and the Agile methods themselves. This is the result of that survey, along with some analysis and recommendations to aid project managers as they implement or enhance Agile within their own organizations.

Our survey participants were drawn from subscribers to the ProjectManagement.com newsletter as well as from visitors to ProjectManagement.com. ProjectManagement.com has nearly 600,000 members representing project professionals from all corners of the globe. These individuals understand and are interested in issues around project management and are at the heart of the growth and evolution of Agile. IT focused project professionals represent the largest category of people invited to take



the sample, but there is representation from every corporate function and, as we will see in the survey results, many different industries.

This paper details the responses received from the survey participants to each of the questions that was asked and offers an analysis of each individual question. The paper then moves on to identify and explore four themes that come out of the survey and offers recommendations based on this analysis along with the thoughts of a number of industry experts. These four themes are:

• Committing to Agile is a journey, not a destination

• As Agile grows, so do the commitments that you need to make to support and nurture it

• Agile is not an excuse to avoid metrics

• The future is changing

We believe that it is vitally important to provide practical, realistic advice to readers of this paper in order to allow them to leverage this work to improve the growth and development of Agile within their organizations. We have therefore developed a five step process that organizations should consider following once they have determined that they are going to pursue a formal Agile implementation and have undertaken preliminary work to choose an Agile approach. We strongly believe that alignment with these steps will

help to deliver the full potential of Agile in organizations as quickly and as sustainably as possible:

1. Identify the criteria that will be used within your organization to determine which projects will use Agile methods, which require traditional methodologies and where a hybrid approach should be considered. Rather than identifying arbitrary determining factors and then applying them, consider reviewing early Agile initiatives to establish common characteristics of successful (and unsuccessful) ones. Use your project archive of waterfall projects to establish similar characteristics and then apply those as part of the decision making process for the approach to be used. Review and adjust the criteria as you add data points and ensure that any exceptions and special situations are documented and assessed.

2. Ensure that the project environments support the approach being used. The reality is that the vast majority of organizations will have a need for comprehensive waterfall and Agile infrastructures and each will need its own culture and methodology without being diluted by other organizational factors. Blending of methodologies should only



occur where the organization has determined a hybrid approach is appropriate, all other initiatives should be allowed to occur within the purity of their processes and structure.

3. Establish metrics and measures for waterfall, Agile and hybrid approaches that provide meaningful data points while minimizing the administrative overhead required to secure that data. At the same time ensure that the metrics used can be related back to the business goals and objectives that initiatives are designed to address – regardless of the approach that is being used. There is no requirement for measures to be comparable across approaches, but absolute progress against expectations is vital regardless of the method of project execution.

4. Establish a continuous improvement and evolution program for all project execution types. If you already have such a program for traditional project management approaches then this can be expanded to Agile but recognize that the speed and extent of change is likely to be increased due to the relative immaturity of Agile approaches. Recognize that expansion of Agile (breadth

and / or depth) may well drive change in the Agile approach that best fits the organization and may well require an entirely different Agile method (as a replacement or addition) or the creation of your own variations on Agile and / or hybrid models. Ensure that every project conducts a process focused lessons learned to identify variances and opportunities.

5. Invest in tools to support your project execution environment only once you have established the framework that your organization will use for the coexistence of Agile and waterfall project execution approaches. The software tools that you select must be capable of supporting the project execution environment that you have developed, not the other way around. Additionally the tool needs to be able to evolve with your processes and expand as your environment matures. Ensure that your tool implementation is conducted from the project teams upwards – collaboration and execution support will drive the biggest benefits into your organization and reporting and data analysis can be tailored around the configuration that best supports successful project execution.



SURVEY RESUlTS: GENERAl DATA

1: how olD ARE YoU?A majority of respondents (almost 72%) were aged between 35 and 54, with the 45–54 age group representing the largest percentage (38.4%) and 35–54 a little behind at 33.5%. A relatively high 16% were 55+, and only 10% were below 35. A small minority preferred not to say. This suggests that the survey is a reasonable reflection of the cross section of people found within organizations, with perhaps a slight bias toward more experienced people.

2: ARE YoU MAlE oR fEMAlE?Of the respondents who indicated their gender, 56.4% were male, although the 45–54 age range showed an almost 50/50 split (50.6% male) and the other age ranges reflecting an approximate 60–64% male majority.

ARE you MALE oR FEMALE?

200

150

100

50

018–34 35–44 45–54 55+

18–34 55+35–44 45–549.8% 16%33.5% 38.4%



3. whERE IN ThE woRlD ARE YoU?Respondents came from 46 countries, although the United States dominated with 66.1% of respondents, followed by Canada (6.7%), Australia (5.5%), the United Kingdom (4.2%), India (3.8%) and New Zealand (1.3%). All other countries recorded less than 1% of respondents. The survey was truly global with Europe, Asia, Africa, Australasia, North, Central and South America represented.

4. whAT IS YoUR RolE?65.4% of respondents were either project managers (41%) or program managers (24.4%), with most of the balance being represented by IT managers (9.3%) or PMO positions (9.1%). Responses were also received from executives, change managers and developers, among others. The survey did not distinguish between project managers in different functions or departments, recognizing that the modern project and program manager is frequently leading cross functional teams within a matrix structure. While stereotypical Agile projects may not have as much breadth of function as traditional projects, as we will see from later questions Agile is not just an IT approach anymore.

USA Australia India Canada United Kingdom New Zealand

Project Managers

Program Managers

PMo Professional Executive/CXo Change Manager IT Developer

66.1% 5.5% 3.8%6.7% 4.2% 1.3%

41% 24.4%

9.1% 2.9% 2% 1.6%

IT Manager9.3%



5. whAT INDUSTRY ARE YoU IN?As might be expected with an Agile survey, the largest category of respondents was from IT – but this still only represented around 22% of respondents, a clear indication that Agile has now gained widespread acceptance across multiple industries. We would anticipate based on the projectmanagement.com membership that was the core focus of invitations to participate that IT departments within these other industries were well represented, but as we drill down into the details of projects later in the analysis it will become clear that not just IT initiatives are represented.

In total 27 unique industries were represented in the survey with strong representation from Finance, Banking and Accounting (10%), Healthcare (7.3%), State and Local Government (6.4%), Insurance (6.4%), Manufacturing (5.3%), Education (4.9%), Telecommunications (4.9%) and Federal Government (4.4%).

6. how bIG IS YoUR oRGANIZATIoN?Responses were received from all sizes of organization, allowing for analysis of Agile evolution by company size (which we will see later in this report). While small companies were still the largest categories, almost half of respondents worked for organizations with greater than 2,000 employees and 1 in 5 worked for an organization with greater than 15,000 people.

How big iS youR oRgAnizAtion?

>15,000

5,001–15,000

2,001–5,000

1–500

501–2,000

20.6%

14%

12.9% 22.6%

29.7%

ITInsurance

federal Government

health Care

EducationState local Government Telecommunications

finance/banking/Accounting

Manufacturing

22%

6.4% 4.4%

7.3%

4.9%6.4% 4.9%

10%

5.3%



7. how MUCh REVENUE DoES YoUR oRGANIZATIoN GENERATE?More than half of respondents (54.1%) reported that their company’s revenue was in excess of US$50 and a further 19.1% reported revenues of US$10–$50 million and 17.5% between US$1–10 million. Only 9.3% of respondents had revenue below $1 million.

>$50M$10M–$50M $1M–$10M <$1M

54.1%

19.1% 17.5% 9.3%



SURVEY RESUlTS: AGIlE DATA wHEn it coMES to tHE bAckgRounD oF RESponDEntS AnD tHEiR oRgAnizAtionS witH AgiLE, wE AgAin SAw A bRoAD cRoSS SEction oF AppRoAcHES, bAckgRounDS, cERtiFicAtionS, DEgREE oF AgiLE AccEptAncE AnD LEngtH oF ExpERiEncE.

8. how MANY AGIlE PRoJECTS hAVE YoU PERSoNAllY woRKED oN?82.7% of respondents reported that they had worked on at least one agile project, although only 35% of people had worked on five or more Agile projects. As we might expect, industries like IT and Finance/Banking/Accounting saw higher percentages of people with Agile experience than other heavily represented industries – only 8.1% of IT respondents and 15.6% of Banking respondents reported no Agile experience, compared with 30.3% of Healthcare respondents and 27.6% of State/Local Government respondents.

However, as Agile experience increased we saw a balancing out of experience with all four industries having between 20–25% of survey respondents with 5–9 projects of Agile experience. This suggests that as Agile is expanding into less traditional industries, it is being adopted at a more rapid rate than was the case with some of the early adoption industries.

How MAny AgiLE pRoJEctS HAVE you pERSonALLy woRkED on?

None

1–4

15+

10–14

5–9

17.3%

47.7%

17.1%

6.7%

11.3%



9. Do YoU CoNSIDER YoURSElf AN AGIlE PRACTITIoNER?The majority (67.4%) of respondents considered themselves to be Agile practitioners, although 40% of that group indicated that they did not have any formal certification. Of those who were certified, 64.2% of indicated that they had a Scrum Alliance certification – Certified Scrum Master being the dominant certification as expected, with 60% of certified practitioners holding it.

Nothing else was remotely close, with the PMI’s Agile Certified Professional a distant second with 7.9% of those who held a certification and only 2.6% indicating that they held the APMG’s Agile Project Management Certification. More traditional certifications still have a strong showing in the survey results with 30% of those who were certified indicating that they held a traditional PM certification, with the Project Management Professional (PMP) dominating. 5.3% of total respondents and 12.6% of those who were certified indicated that they held multiple certifications, with various combinations of Agile certifications and Agile combined with traditional certifications being represented.

There were dramatic differences in the levels of certification between different industries, and while industries with only a small number of respondents were not considered due to the potential to skew the results, of the top industries by number of respondents the level of certification varied considerably. 46.5% of respondents from IT, 44.4% of those in Finance/Banking/Accounting and 45.5% of those from Healthcare indicated that they were certified. However, only 20.7% of those in State/Local Government and 31% of those in Insurance were certified. This is likely caused by practitioners waiting until Agile becomes established in these industries before they commit to certification, combined with the organizations themselves waiting before actively recruiting certified individuals.

42.1%

11.8%32.5% 20.8%

Certified Agile practitioner

No, but plan to become within 12 months

Non-certified Agile practitioner No



10. how MANY AGIlE PRoJECT MANAGERS woRK IN YoUR CoMPANY?71.4% of organizations reported that they had 10 or fewer Agile project managers within their organization with an equal number (8.4%) reporting that they had 11–25 or 26–100. 2.9% reported that they had between 101 and 500 Agile PMs, and as we would expect only 0.9% reported over 500; 8% of respondents did not know how many Agile project managers were in their organization, although that was generally within larger organizations.

Not surprisingly, the number of Agile PMs increased with the size of the organization – although well over a third (36.6%) of the largest organizations still reported 10 or fewer, and in mid-size companies the numbers were even more stark (almost 80% of organizations in the 2,001–5,000 employee range still reported fewer than 10 Agile PMs). While this may be indicative of the nature of projects undertaken within those organizations, it is also a sign that Agile has not yet expanded beyond its core. There are signs that even in industries like IT, Agile hasn’t yet expanded beyond the core functions – not a single IT organization below 5,000 employees reported having more than 100 Agile PMs, and only 1.3% of IT organizations with up to 15,000 employees reported more than 100 Agile PMs.

11. whAT PERCENTAGE of YoUR oRGANIZATIoN’S PRoJECT MANAGERS ARE AGIlE?As we started to drill deeper into the prevalence of Agile within organizations, we asked about the percentage of PMs who were Agile. The numbers demonstrate that Agile is clearly moving into the mainstream in a wide variety of organizations with 50.1% of respondents indicating that 20% or more of their PMs were Agile, and a full 20.8% indicating that 80% or more of their PMs were Agile.

Interestingly, there were a relatively small number of organizations (14%) who indicated that they had between 40 and 80% of their PMs who were Agile. This suggests that once organizations reach a critical mass of Agile initiatives using Agile, there is a rapid expansion of Agile project execution.

of respondent organizations have 10 or fewer Agile project managers71.4%



This trend was similar across all sizes of organization (although as we would expect the percentage tended to drop with very large companies) and industry. IT was the outlier with a heavier concentration of Agile PMs – 62.6% of respondents indicated that more than 20% of PMs were Agile. This is undoubtedly a reflection of the higher percentage of software development initiatives that will occur within IT organizations.

How MAny AgiLE pRoJEctS HAVE you pERSonALLy woRkED on?

0–19%

80–100%

60–79%

40–59%

20–39%

49.9%

20.8%

5.3%

8.7%

15.3%

12. how MANY AGIlE CERTIfIED PRoJECT MANAGERS ARE ThERE IN YoUR oRGANIZATIoN?76.3% of respondents reported that their organization had 10 or fewer Agile certified project managers, a relatively low number when you consider that 71.4% of respondents said that they had 10 or fewer Agile project managers in total. A greater percentage (13.7%) of respondents indicated that they didn’t know how many PMs were Agile certified than indicated that they didn’t know how many Agile PMs there were (8%), which may explain some of the reason why the gap isn’t larger between certified and total. But this appears to be a strong indication that Agile certification is becoming more important as Agile becomes more accepted within organizations, an indication of an ongoing commitment.

Top Tip!

Agile certification is becoming more popular but you can still stand out from the crown by becoming certified. now is the time to consider certification to be an in-demand resource.

0–10 11–25 26–100 101–500 >500

76.3%

4.9% 4% 0.9% 0.2%



13. whAT PERCENTAGE of PRoJECT MANAGERS ARE AGIlE CERTIfIED?With a relatively low average number of Agile certified project managers, it’s not surprising that the overall percentage of project managers who were Agile certified was low. As we saw in Question 11, almost half of respondents said that less than 20% of their PMs were Agile – so it’s not overly surprising that 69.2% of people said that less than 20% of their organization’s PMs were Agile certified.

The trend that we saw in Question 11 of a heavy commitment to Agile once a certain critical mass was received continued with 16.4% of respondents indicating that more than 80% of their PMs were Agile certified. However, whereas the trend to invest heavily in Agile project management identified in Question 11 appears to occur once 40% or more of the project managers were Agile, the certification commitment appears to occur earlier. Only 14.4% of respondents indicated that between 20 and 80% of the organization’s project managers were certified; while this could be a statistical anomaly, it appears to suggest that organizations are starting to mandate Agile certification once they become committed to it. This is particularly evident when comparing the 60–79% range, where only 1.1% of respondents indicated that their organization sat, with the 80–100% range with the previously stated 16.4%.

wHAt pERcEntAgE oF pRoJEct MAnAgERS ARE AgiLE cERtiFiED?

40–59%

5.3%

20–39%

8%

0–19%

69.2%

80–100%

16.4%

60–79%

1.1%0%

80%

60%

40%

20%



14. whAT AGIlE CERTIfICATIoNS ARE hElD bY PRoJECT MANAGERS?When we asked respondents which Agile certifications were held by project managers within their organizations, the most surprising response may have been that 46.1% indicated that there were none. This reflected both organizations where Agile projects were common (24% of the people in the “no certification” group considered 80–100% of their PMs to be Agile), and organizations where traditional methods still dominated (57.2% of the group said that less than 20% of PMs were considered to be Agile). This latter category is to be expected – if there is not yet a commitment to Agile, then there is less likely to be a requirement for Agile certifications. But the relatively high number of Agile-committed organizations who do not have Agile certified PMs is perhaps a little troubling.

Of those respondents who said that their organizations did have Agile certified project managers, we once again saw the Scrum Alliance certifications dominate. 39.7% of survey respondents and 73.7% of those whose project managers held certifications mentioned at least one Scrum Alliance certification. Certified Scrum Master dominated with 71.6% of respondents; this also represented 95.5% of those who held Scrum Alliance certifications. Other Scrum Alliance certifications also had healthy representation, with Certified Product Owner being quoted by 13.6% of organizations where PMs were certified, Certified Scrum Professional by 9.5% and Certified Scrum Developer by 5.3%.

Other certification bodies were also well represented, with the PMI’s Agile Certified Professional being mentioned by 25.1% of respondents whose PMs were certified and 8.2% listing the APMG’s Agile Project Management Certification. 21.8% of this group indicated that other certifications were held, including a number of internal certifications – a trend that suggests that organizations are not only adopting Agile but are also starting to tailor the approaches to their own specific needs.

35% of respondents with certifications listed multiple certifications within their organization, suggesting that there is recognition that a “one size fits all” certification is not necessarily appropriate. In some cases, these were all Scrum Alliance certifications where there are clearly variations in the certification for different roles – but there were also variations of Scrum Alliance and other certification bodies.

of organizations had certified project managers53.9%



oF tHoSE oRgAnizAtionS wHERE cERtiFicAtionS wERE HELD:

0%

9.5%

Certi�ed Scrum

Professional (Scrum

Alliance)

13.6%

Certi�ed Product Owner

(Scrum Alliance)

71.6%

Certi�ed Scrum Master

(Scrum Alliance)

25.1%

Agile Certi�ed Professional

(PMI)

5.3%

Certi�ed Scrum

Developer (Scrum

Alliance)

21.8%

Other

8.2%

Agile Project Management Certi�cation

(APMG)

80%

60%

40%

20%

We also dived deeper into the certification within organizations to understand how extensively a particular certification had been accepted. We asked respondents to tell us the percentage of project managers within their organization who held a specific certification. The responses were extremely varied from organization to organization, but a weighted average of the responses reveals the results:

CERTIfICATIoN wEIGhTED AVERAGE % of PMS holDING ThE CERTIfICATIoN

CERTIfIED SCUM MASTER (SCRUM AllIANCE)

31.2%

CERTIfIED PRoDUCT owNER (SCRUM AllIANCE)

12.5%

CERTIfIED SCRUM PRofESSIoNAl (SCRUM AllIANCE)

6.4%

CERTIfIED SCRUM DEVEloPER (SCRUM AllIANCE)

12.3%

AGIlE CERTIfIED PRofESSIoNAl (PMI)

13.7%

AGIlE PRoJECT MANAGEMENT CERTIfICATIoN (APMG)

17.3%

oThER CERTIfICATIoN 34.4%

The table is effectively showing us the degree to which certifications have penetrated the organizations where they are in use. For example, where respondents indicated that Certified Scrum Master was held by project managers within their organization, an average of 31.2% of PMs



held the certification. This demonstrates that this certification not only dominates in terms of breadth of acceptance, but also in terms of the depth of that acceptance.

The level of penetration of the “other certification” category may seem rather high, but we know that this includes organizations’ own internal certifications; we would expect to see a higher penetration rate in those situations, and that raises the overall average. Additionally, a number of respondents made comments that suggested that their organization accepted the Project Management Professional (PMP) in this category even though it is not an Agile-specific certification. The high penetration rate of the PMP within project management will also increase the overall average. This may also help to explain why the PMI’s own Agile Certified Professional designation has not spread as deeply within organizations as the APMG’s Agile Project Management Certification, even though it is in use in a wider range of organizations – the PMP is seen as acceptable for the current project managers, with a shift to the Agile-focused PMI credential occurring over time.

15. whERE Do ThE AGIlE PRoJECT MANAGERS AND PRACTITIoNERS REPoRT To?We asked respondents to indicate where Agile staff reported within the organization. Of those that indicated that they had Agile project managers, 63.4% indicated that these staff reported into IT – 38.3% across all areas of the IT organization and 25.1% specifically within an IT PMO. The remaining 36.6% were split between a reporting structure that was distributed across all business units (24.5%) and within a corporate PMO (12.1%).

These numbers are to be expected given the close alignment of IT and Agile, and we actually consider the 36.6% of respondents who indicated that Agile PMs did not report to IT to be fairly high – more than one third of respondents indicated that Agile was broadly based enough within their organization to warrant management and control from beyond IT. With the recent increase in the popularity of Enterprise PMOs (EPMOs), we considered that this may represent much of the non IT group, but less than 1 in 8 of respondents whose organizations had Agile PMs indicated that they were within a corporate PMO. This is perhaps indicative of the perceived difficulty of combining Agile and traditional project execution approaches within the same organizational structure.

At the same time, more than one-third of respondents indicated that their Agile PMs were distributed across business areas beyond IT. This suggests that those departments are dealing with the challenges of managing both



Agile and waterfall-based projects – an assumption borne out by a look at the percentage of Agile project managers in those organizations. 38.7% of the organizations that identified that Agile resources reported beyond IT also reported that less than 20% of their projects were Agile, making it clear that both types of project execution approaches are occurring in parallel.

wHERE Do tHE AgiLE pRoJEct MAnAgERS AnD pRActitionERS REpoRt to?

Across all areas of IT

In an IT PMO

In a corporate PMO

Across all business areas

38.3%

25.1%

24.5%

12.1%

16. how MANY of ThE oRGANIZATIoN’S PRoJECTS USE AGIlE APPRoAChES?The last questions that were asked around the makeup of projects within organizations was with regard to the number of projects (in absolute and percentage terms) that were considered Agile. 59.4% of respondents indicated that 10 or fewer projects within their organization were Agile, and 69% of that number indicated that this represented less than 20% of their project portfolio. This group (41% of total respondents) is likely to still be in the evaluation and early adoption phase of Agile, not yet committing to Agile across the entire organization or for all initiatives.

As the absolute number of Agile projects increased, so did the average percentage of the portfolio – with the median moving to the 20–39% range for those organizations who conduct between 11 and 25 Agile projects; the 40–59% range for those conducting 26–100; and just into the 60–79% range of those organizations conducting more than 100 Agile initiatives.

An interesting trend emerged when we compared the percentage of Agile projects with the percentage of Agile project managers. We might expect the numbers to be equivalent, or perhaps even slightly lower for the percentage of Agile PMs to reflect the perception of Agile being a “thinner” approach to project execution – but the opposite was true.

Top Tip!

close to half of organizations now have at least 1 in 5 of their projects executed with Agile methods. if you aren’t one of them, chances are that many of your competitors are – and they could be gaining a significant advantage.



The table below shows the percentage of PMs who were described as Agile (from Question 11 above) as well as the percentage of projects that are Agile. The weighted average is provided (calculated using the mid-point of the percentage ranges) to provide a point of direct comparison:

PERCENTAGE RANGE PERCENTAGE of PMS

PERCENTAGE of PRoJECTS

0–19% 49.9% 55.9%

20–39% 15.3% 12.9%

40–59% 8.7% 11.1%

60–79% 5.3% 5.5%

80–100% 20.8% 14.6%

wEIGhTED AVERAGE 14.5% 12.8%

This suggests that an average of 14.5% of PMs within an organization are Agile, but collectively only 12.8% of projects are Agile – the opposite of what we might expect to see. Caution should be taken in reading too much into these statistics because it is entirely possible that a PM could be managing a combination of Agile and waterfall projects, and we would also expect the effectiveness and efficiency of Agile execution to improve over time as organizations and project managers become more familiar with Agile approaches. Nevertheless, this is an interesting trend that bears monitoring in future surveys.

How MAny oF tHE oRgAnizAtion’S pRoJEctS uSE AgiLE AppRoAcHES?

0–10

Don’t know

500+

101–500

26–100

11–25

59.4%

14%

11.5%

10.4%

3.8%

0.9%



17. how loNG hAVE YoU bEEN MANAGING PRoJECTS USING AGIlE oN AN AD hoC bASIS?We asked respondents how long they had been managing projects using Agile methods on a less formal basis. While 23.7% of people said that they did not manage projects using Agile, 30.8% of survey respondents (representing 40.4% of those who said that they managed projects in an Agile manner) indicated that they had been using the approach for 1–3 years. This compares with 16.2% of respondents (and 21.2% of those using Agile) who had been using the approach for less than a year. Clearly this indicates the relative youth of Agile within mainstream project execution. However, it also shows that the interest of Agile is not diminishing at all and continues to be adopted at a rapid rate.

The number of people who had been using Agile for longer periods of time was much lower, but the numbers are becoming more significant – 38.4% of people who managed projects using Agile have been doing so for more than 3 years, and 20% for over 5 years. This is a clear sign that Agile is not only becoming more accepted, but once adopted it is retained within the organization.

How Long HAVE you bEEn MAnAging pRoJEctS uSing AgiLE on An AD Hoc bASiS?

Less than 1 year

1–3 years

Do not manage projects using Agile

Greater than 10 years

7–10 years

5–7 years

3–5 years

23.7%

4.2%

4%

16.2%

7.1%

30.8%

14%

18. how loNG hAVE YoU bEEN MANAGING PRoJECTS USING AGIlE oN AN offICIAl bASIS?To follow up on the previous question, we next asked how long respondents had been managing projects using an official Agile approach. Obviously the trend was to a shorter period than when we asked about ad hoc management;



this is due to the lag between the concept being introduced and it being introduced as an official organizational approach to execution.

How Long HAVE you bEEn MAnAging pRoJEctS uSing AgiLE on An oFFiciAL bASiS?

Less than 1 year

1–3 years

Do not manage projects using Agile

Greater than 10 years 7–10 years 5–7 years 3–5 years

20.4%

26.8%

34.2%

6%1.1%

1.3%

10.2%

If we calculate a weighted average based on the midpoint of the ranges, we see that the average for official usage is 1.5 years versus an average of 2.3 years for ad hoc usage. Both numbers include those who say that they do not use Agile. This suggests that the period of time between initial use and formal adoption is relatively low. The gap will increase if those who do not use Agile are excluded, but there is clearly not an extended period of time where Agile is debated and considered before being accepted. It seems logical to assume that the benefits of Agile-based project execution are readily identified and understood.

19. how wIDESPREAD ARE AGIlE PRoJECTS wIThIN YoUR oRGANIZATIoN?We next asked respondents to identify the areas of their organization where Agile projects were executed. 71.8% of respondents reported that their Agile initiatives were restricted to IT, although the spread of Agile within IT departments seems to be growing. 11.3% of survey participants said that Agile was in use across all of IT, and 34.8% said that Agile was being used across multiple IT departments or teams. That meant that only 25.7% of respondents said that their Agile initiatives were restricted to a single IT department/team, and 70.7% of that group were in the two smallest company size categories (less than 2,000 employees) where it can be expected that IT has a smaller overall size.

Only 14.2% of respondents said that their organizations did not undertake any Agile initiatives. While caution should be taken in reading too much into that number on a survey that is Agile focused, the indication is clearly that



Agile continues to grow. Perhaps surprisingly, 39.1% of the respondents who said that their organization did not conduct any Agile initiatives indicated that they worked for large (5,000+) employers. This may perhaps indicate a reluctance to introduce potentially significant disruption to well-developed project execution methodologies.

This question also revealed a rapid expansion in Agile use once it broke beyond IT. While only 14% of respondents said that Agile was in use beyond IT, 73% of that group said that they were using Agile across the entire organization – suggesting that after Agile is adopted, it rapidly expands into areas where it can be beneficial.

20. whAT TYPE of PRoJECTS DoES YoUR oRGANIZATIoN USE AGIlE foR?We asked respondents to tell us about the type of projects that they used Agile to manage. Software development projects dominated: 43.9% of survey respondents (50.3% of those who used Agile) stated that Agile was used for selected software development projects. In addition, 22.8% of respondents (26.1% of those using Agile) said that all of their software development projects were managed using Agile approaches.

Software development is clearly the Agile sweet spot, but this question also revealed that organizations are extending Agile techniques and processes to more than just development initiatives. Respondents were

one IT Department/Team

No Agile Projects

Several IT Departments/Teams All IT Departments/Teams

IT and other Departments

Company-wide

25.7%

14.2%

34.8%

11.3%

3.8%

10.2%



allowed to select multiple options for this question, and 10.6% of respondents (12.2% using Agile) stated that they used Agile for all product enhancement projects. However, only 2% indicated that Agile was used for all new product development projects. The numbers are low as we would expect – unless organizations are heavily focused on IT products then it is likely that not every product is a suitable candidate for Agile methods. However, this relatively significant percentage difference between new products and product enhancements is slightly surprising. This may reflect ownership – enhancements may fall within the realms of IT, whereas new products may not, however it may also reflect a desire to see expansion into less traditional Agile areas with lower risk and/or less business-critical initiatives first before trying to scale across strategic new product endeavors.

When we specifically asked about non-software development projects, the numbers clearly indicated that Agile has a place in those projects – 25.6% of respondents whose organizations used Agile said that it was used in that type of project, and 36.7% of that group said that it was used for all non-software development projects.

Clearly the idea that Agile is simply a quicker and simpler way to write code is outdated; organizations are recognizing that Agile approaches can deliver a number of different advantages and are looking to leverage those benefits wherever possible.

wHAt typE oF pRoJEctS DoES youR oRgAnizAtion uSE AgiLE FoR?

Selected software development projects

All software development projects

Selected new non-software development projects

All new non-software development projects

Selected new product development projects

All new product development projects

Product enhancement projects

Other

We do not use Agile

0% 50%40%30%20%10%

We delved deeper on this question and asked those who had chosen one or more of the selected options to tell us what the drivers were that led to the decision about whether to use Agile or not. Respondents were able to select multiple options, and the traditional triple constraint of budget,



scope and timeframe featured heavily in the decision with 48.8% of respondents indicating that at least one of the them factored in to the decision-making process.

There also seem to be realistic expectations of what Agile should focus on – only 14.3% used budget as a determining factor (presumably in the expectation that Agile would be cheaper), whereas 38.8% used scope as a determining factor. 31.1% of respondents indicated that timeframe was a deciding factor, indicating that there is an expectation that Agile may deliver more quickly (it may also indicate a recognition that new approaches may take longer to execute while they are being adopted and accepted).

There was also significant weight given to experience: 44.1% of respondents indicated that the team’s experience with Agile was a deciding factor, with 27% indicating that the department’s experience factored in. While it is encouraging to see that these items are considered, organizations will need to move beyond this determining factor if they are going to successfully expand their Agile use – it cannot be tempered by a lack of experience.

Sponsor and customer choice also factored into the decision-making process, with the sponsor’s choice influencing 25.8% of decisions and the customer’s choice influencing 22%. This is perhaps a lower value than we might expect for customers; it may indicate a lack of awareness of Agile approaches among some customers. Clearly the impact on the customer of an Agile-based project can be considerable, and we might expect the customer’s preference to carry more weight than seems to be the case.

18.9% of respondents indicated other criteria were used, and these varied from a company-mandated decision to the PM’s preference and from the type of project to the complexity and risk involved.

0%

14.3%

Budget

38.8%

Scope

31.1%

Timeframe

44.1%

Team experience

27%

Department experience

25.8%

Sponsor’s choice

22%

Customer’s choice

18.9%

Other

50%

40%

30%

20%

10%



GoING DEEPER oN AGIlE PRoCESSESoncE wE HAD An unDERStAnDing oF tHE oRgAnizAtionS tHAt ouR RESponDEntS cAME FRoM AnD How AgiLE FittED into tHEiR pRoJEct StRuctuRE, wE wAntED to go into MoRE DEptH ARounD tHE AgiLE pRocESSES tHAt tHEy uSED AnD How tHEiR uSE oF AgiLE HAD cHAngED AnD EVoLVED. tHAt’S ExpLoRED in MoRE DEtAiL in tHiS SEction.

21. whAT AGIlE APPRoAChES DoES YoUR oRGANIZATIoN USE?We asked respondents to identify all of the Agile processes that were in use within their organization. Consistent with the responses provided around certification (and in line with general industry utilization), Scrum was the dominant approach with 79.7% of those who used a formal approach listing it. Perhaps more surprisingly, only 44.6% of respondents reported using a single approach, the rest reporting that a combination of different approaches was used:

% oF oRgAnizAtionS uSing EAcH AppRoAcH

% USING ThE APPRoACh oN

ITS owN

% USING ThE APPRoACh IN CoNJUNCTIoN wITh oThERS

ToTAl %

AGIlE UNIfIED PRoCESS 2.1% 7.2% 9.2%

CRYSTAl 0% 1.5% 1.5%

DSDM 0.8% 2.1% 2.8%

fEATURE DRIVEN DEVEloPMENT 2.3% 12.6% 14.9%

KANbAN 0.5% 29.7% 30.3%

lEAN 3.6% 24.4% 28%

SCRUM 31.5% 48.2% 79.7%

XP 0% 14.4% 14.4%

oThER 6.2% 4.6% 10.8%



These numbers show some interesting variations in the way that different approaches are used. Some of the extremes shown in the table might be expected – anyone familiar with Kanban will recognize that it is an approach that works well in conjunction with other approaches, and it isn’t surprising to see such a high number in that category. At the same time, it’s not necessarily an approach that organizations would consider implementing on its own – so the strong indication that it is being used to strengthen an Agile implementation based on other methods makes perfect sense. 33.1% of Kanban users used it in conjunction with Scrum, and 6.8% used it in conjunction with Lean (these represented the two largest pairings).

There was a surprise in one element of the Kanban numbers – 13.6% of Kanbaners used it in conjunction with both Scrum and Lean, twice the number that used it with Lean alone. Without turning this into an analysis of each of the different methods, this does make sense. In the same way that Kanban can add a more strategic focus to a Scrum implementation, Lean can add a focus on constantly improving efficiency – the three form a natural partnership. This trend continues in organizations that don’t leverage Kanban – 71.6% of organizations that leverage Lean also use Scrum, although only 15.6% use only Lean and Scrum; the rest combine them with a variety of other approaches.

The other approach that may seem anomalous in the numbers is XP. While 14.4% of organizations used XP, no respondent indicated that it was their only approach. The two largest categories were a pairing of XP and Scrum (26.8% of XP users) and the combination of XP, Scrum, Lean and Kanban (19.6% of XP users). Only 5.4% of XP users did not also use Scrum. The shift away from XP as a standalone Agile approach is likely reflective of the acceptance of Agile as a mainstream project execution methodology. As Agile has become more accepted, the engineering-focused XP is insufficient and the more management-focused Scrum and/or Lean approaches have been introduced to help strengthen Agile execution – a trend that is further evolving with the inclusion of Kanban.

Top Tip!

Most organizations implement more than one Agile approach. consider an Agile foundation that combines elements of different methods to find what works best for you.



22. whAT lED YoU To ChooSE ThIS APPRoACh?We next asked respondents to tell us what led them to choose the approach or approaches that were selected. The table below shows the percentage of people who indicated that each of the identified reasons impacted the decision for each of their selected methods.

bREAkout oF DEciSion-MAking cRitERiA by AppRoAcH 3R

D PA

RTY

RECo

MM

ENDA

TIoN

CUST

oMER

REq

UES

T/RE

qUIR

EMEN

T

EASE

of

USE

fIT

wIT

h Y

oUR

oRGA

NIZ

ATIo

N

INTE

RNAl

SEl

ECTI

oN

PRoC

ESS

PREV

IoU

S

EXPE

RIEN

CE

oTh

ER

AGIlE UNIfIED PRoCESS

16.7% 18.8% 31.3% 47.9% 12.5% 25% 8.3%

CRYSTAl 15.4% 23.1% 23.1% 7.7% 15.4% 15.4% 15.4%

DSDM 15% 15% 45% 30% 25% 30% 5%

fEATURE DRIVEN DEVEloPMENT

12.9% 25.7% 41.4% 55.7% 15.7% 32.9% 5.7%

KANbAN 16.5% 11% 46.5% 55.1% 21.3% 37.8% 8.7%

lEAN 10.6% 11.5% 32.7% 52.2% 17.7% 43.4% 8.9%

SCRUM 16.9% 8.5% 47.3% 47% 19.7% 37.9% 12.2%

XP 9.4% 10.9% 23.4% 34.4% 25% 40.6% 15.6%

oThER 17.3% 19.2% 26.9% 42.3% 19.2% 28.8% 21.1%

As a general trend, we can see that ease of use and organizational fit were powerful drivers in decisions. But as we start looking at the data in more depth, some variations appear. Some of the percentages may be skewed slightly by the relatively low number of respondents who indicated that their organization used that approach – as we saw in the previous question, a very low percentage of survey participants used DSDM or Crystal so we should be cautious in reading too much into those numbers.

Perhaps surprisingly, third-party recommendations are not seen as a major deciding factor. While it does feature in the decision-making process, it is not a significant factor for any approach. This suggests that organizations are taking the time to investigate all options and educate themselves on the best options for their particular scenario before making a decision. Put another way, Scrum is not dominating simply because it is the current hot trend. The lowest

Top Tip!

you have to live with your choice of Agile method, so make sure that you are comfortable with the selection criteria that you’re using. while organizational fit and ease of use are vital factors, you also need to think about the ability of the approach to grow and develop with your organization.



numbers in this category were for XP and Lean, and this may reflect the fact that they aren’t necessarily seen as “cool” and contemporary Agile approaches relative to some of the others – and are therefore less likely to be recommended. However, as we saw in the question above, Lean still has a healthy reach into Agile organizations. This again suggests that third-party recommendations are not heavily weighted in the decision-making process.

The approach leaders among our respondents, Scrum and Kanban, were also the leaders in the “ease of use” category. Lean scored poorly in this category: only 32.7% of users stated ease of use was a consideration; this suggests that users do not find Lean as easy to work with as Scrum (47.3%) or Kanban (46.5%). Whether the adoption rate would be higher if Lean were considered easier to use can only be speculated.

Lean did score highly in the other major decision-making category: fit for the organization. Clearly this is a major deciding factor, although it is interesting that fewer than half (47%) of Scrum users chose that approach because of its fit with their organization. This may suggest that in some cases Scrum is being chosen despite it not being a “best fit” solution for organizations. This is reinforced by a look at those respondents, who cited organizational fit as their only deciding factor. Only 9.4% of Scrum users cited organizational fit as the exclusive reason for making the selection, the lowest of all but the smallest adoption-rate approaches.

% oF uSERS wHo DEcLARED oRgAnizAtionAL Fit AS tHE SoLE DEciDing FActoR:

0%

12.5%

Agile Uni�ed Process

0%

Crystal

5%

DSDM

14.3%

Feature Driven

Development

14.2%

Kanban

16.8%

Lean

9.4%

Scrum

9.4%

XP

11.5%

Other

20%

15%

10%

5%

The clear implication here is that organizations view other approaches as a better fit for their needs than Scrum. As Agile continues to become more mainstream and organizations are able to become better informed in the decisions that they make, this may suggest that Scrum’s dominance is not as secure as it may initially appear.



23. whAT AGIlE APPRoAChES (If ANY) hAS YoUR oRGANIZATIoN PREVIoUSlY USED ThAT ARE No loNGER bEING USED?We asked survey participants about any previous experiences with Agile approaches. While the relative youth of Agile led us to expect that the majority of organizations were still experiencing their first wave of Agile implementations, we wanted to understand what changes had occurred. As expected, 88% of respondents said that their organization had not yet rejected any Agile approaches, but within the remaining 12% all of the major approaches were mentioned. The graphic shows the percentage of respondents who had stopped using an approach.

0%

5.6%

Agile Uni�ed Process

3.7%

Crystal

7.4%

DSDM

18.5%

Feature Driven

Development

5.6%

Kanban

18.5%

Lean

29.6%

Scrum

22.2%

XP

18.5%

Other

30%

20%

10%

It’s no surprise to see that Scrum was the highest – from sheer weight of numbers, we would expect to see that appear more frequently. However, when we start to look at the number of people who have rejected a particular approach as a percentage of those that are currently using it, we get a very different picture:

PEoPlE who SToPPED USING AS A % of ThoSE CURRENTlY USING

AGIlE UNIfIED PRoCESS 8.3%

CRYSTAl 33.3%

DSDM 36.4%

fEATURE DRIVEN DEVEloPMENT 17.2%

KANbAN 2.5%

lEAN 9.2%

SCRUM 5%

XP 21.4%

oThER 19%



Again, we need to be cautious with the numbers for Crystal and DSDM as such a small percentage of respondents indicated that they used the approaches. But the relatively high percentage of users who had tried and moved away from those approaches may also indicate why their popularity is currently low.

Kanban has the lowest percentage of users who have tried and rejected it. While that is clearly a very good sign, we also have to recognize that while not a new concept in and of itself, Kanban is a relatively new approach to Agile as it is currently viewed and is still one of the en vogue approaches. On the other hand, XP has been around for a relatively long time, increasing the chances that it will have been moved away from. Combined with the relatively low (14.4%) rate of use among our survey participants, that helps explain the relatively high percentage of former users. The standout is once again Scrum, an established process that still shows a remarkably high retention rate among users – only one former user for every 20 current users.

24. whAT lED YoU To SToP USING AN APPRoACh?In the same way that we asked why a particular Agile method was chosen, we also asked respondents to tell us why a particular method was moved away from. Those responses are tabulated below:

lACK

of

SUCC

ESS

AGAI

NST

bU

DGET

lACK

of

SUCC

ESS

AGAI

NST

DE

lIVE

RAbl

ES

lACK

of

SUCC

ESS

AGAI

NST

SCh

EDU

lE

DIff

ICU

lT T

o U

SE

lACK

of

fIT

wIT

h

YoU

R oR

GAN

IZAT

IoN

No

loN

GER

APPR

oPRI

ATE

AS A

GIlE

EX

PERI

ENCE

EVo

lVED

CUST

oMER

fEE

DbAC

K

PRoJ

ECT

TEAM

fE

EDbA

CK

STAK

Ehol

DER

fEED

bACK

oTh

ER

AGIlE UNIfIED 6.3% 18.8% 6.3% 6.3% 12.5% 0.0% 6.3% 31.3% 25.0% 12.5%

CRYSTAl 27.3% 18.2% 27.3% 9.1% 9.1% 0.0% 9.1% 0.0% 18.2% 18.2%

DSDM 23.1% 15.4% 15.4% 15.4% 15.4% 23.1% 15.4% 7.7% 15.4% 7.7%

fEATURE DRIVEN DEVEloPMENT

0.0% 13.6% 22.7% 13.6% 4.5% 13.6% 13.6% 18.2% 13.6% 27.3%

KANbAN 7.1% 14.3% 28.6% 14.3% 14.3% 7.1% 7.1% 14.3% 21.4% 21.4%

lEAN 15.8% 26.3% 10.5% 21.1% 21.1% 5.3% 0.0% 21.1% 21.1% 15.8%

SCRUM 16.7% 27.8% 22.2% 5.6% 30.6% 5.6% 16.7% 27.8% 22.2% 13.9%

XP 13.6% 13.6% 22.7% 13.6% 13.6% 18.2% 9.1% 18.2% 9.1% 18.2%

oThER 0.0% 23.8% 23.8% 14.3% 14.3% 19.0% 4.8% 14.3% 9.5% 33.3%

Top Tip!

Very few organizations completely change their Agile approach once they have committed – make sure that you are comfortable with your choice up front.



We have to remember that the overall universe of responses for each of these methods is relatively small – only 12% of respondents said that they had made any change. However, the trends here are worth considering and we can immediately see a few themes. Firstly, when we consider the traditional triple constraint of budget, scope (deliverables) and schedule (the first three columns of the table), we can see that there was a consistent trend of deliverables and schedule being problematic. While there were outliers, this suggests that financial performance has been broadly positive, although this needs to be tempered somewhat against the backdrop of organizations traditionally using waterfall-based approaches (which we would expect to be more costly). It may also reveal that organizations are focused more on expectations of improvements to schedule and deliverables, although whether the failure to meet those expectations is the result of failed performance or unrealistic expectations is something that we can only speculate on.

Difficulty of use was an area that saw some variability, but only Lean was notably higher than the others (although the data samples are not large enough to draw conclusions). The combination of “lack of fit” and “no longer appropriate” was also interesting – the general trend was for the percentage who identified a bad fit to be higher than those who suggested that the approach was no longer appropriate. This appears to suggest that the expected fit and the actual fit were at variance rather than the needs of the organization changing. Scrum in particular showed a significant variance with 30.6% of respondents claiming lack of fit – almost one-third of the people who rejected Scrum approaches cited this as a reason. Given the significant amount that has been written on Scrum in recent years, this suggests unrealistic expectations at the time of implementation rather than a lack of awareness.

One approach that showed a markedly different result was Feature Driven Development. Here, only 4.5% of respondents rejected Scrum because it wasn’t a good fit – with 13.6% suggesting that it was no longer appropriate, perhaps because newer approaches have been developed in recent years.

When it came to the different stakeholder groups, it is clear that all three carry some weight when it comes to deciding whether or not to continue with a particular approach (although project teams and sponsors seem to carry more weight than customers overall).

25. hAS YoUR oRGANIZATIoN MoDIfIED ThE APPRoAChES ThAT IT USES?As we continued to drill down into the details of respondents’ Agile approaches, we asked whether organizations had chosen to modify standard Agile approaches. Of those that used Agile methods, 72.7% said that they had modified some element of the approach – and the majority (58.1%) had actually modified or created process elements rather than simply adapting



templates and/or terminology. 11.7% said that their organizations had gone as far as to develop their own internal methodology.

We use a standard approach, terminology and templates

We use a combination of standard approaches, terminology and templates

We use a standard approach, but have adjusted terminology and templates to better �t our organization

We have developed an internal Agile methodology

We have modi�ed a combination of approaches to better meet our needs

We have modi�ed a standard approach to better meet our needs

18%

11.7%

28.1%

9.4%

14.6%

18.2%

When we look at these responses compared with the previous questions around the use of previous Agile methods, some of the answers are surprising. We might expect organizations to start with a standard approach and evolve over time to something that is more customized. With 88% of respondents advising that they had not stopped using an Agile approach, it is clear that this is happening as organizations become more familiar with the approach and tailor elements to better meet their needs. A higher-than-average percentage of respondents who indicated that they use a combination of standard approaches (19.9%, relative to the 12% of the overall survey) said that they had rejected a previous approach. This may indicate a reluctance or inability to modify or tailor Agile methods to their needs, resulting in higher turnover in approaches and the use of multiple approaches.

On the other hand, those organizations that have modified approaches show an increased likelihood to still be working with the Agile approach/approaches that they selected when first starting Agile. Compared to the 88% of the overall set of respondents who had not moved away from an alternative approach, the number for “we have modified a standard approach” was 88.6%; and for

“we have modified a combination of approaches” was 89.8%. Not dramatic improvements, but an indication that – sometimes – adjustments to standard approaches can deliver the required results.

Perhaps the most surprising result is that only 11.1% of respondents whose organizations had developed their own internal Agile approach had previously used an alternative method. Where we might expect organizations to migrate to their own methodology as their familiarity and experience grows, it would appear as though some organizations are committing to their own approach from the very start of their Agile journey.

Top Tip!

the vast majority of organizations find themselves modifying standard approaches to better meet their needs. Make sure that consideration is given to how best to tailor approaches to your unique circumstances and invest in the resources to make those changes as needed.



26. If YoU hAVE MoDIfIED AN EXISTING AGIlE APPRoACh oR DEVEloPED A NEw oNE, whAT DRoVE ThAT woRK?When we followed up on the previous question to ask what had caused organizations to modify or create their own approaches, there was a clear separation in how the decisions were made. 55% of respondents cited only a single driver for the work, with project completion reviews being the most popular response (25.8% of this subset). The “other” category was the next most popular (22.7%), with various reasons cited: from a lack of commitment to standard approaches to recommendations from consultants and from misunderstanding to organizational resistance. Of the 45% of respondents who indicated that there were multiple reasons for making the decision, the average number of reasons given was 2.9 – suggesting that these were complex decisions based on many factors.

Overall, the most frequently cited reasons for change were the results of project completion reviews/lessons learned (44.2%) and requests/feedback from project teams (43.9%). This clearly shows that the project teams are carrying a considerable amount of weight in determining how best to implement Agile approaches – and that has to be a positive sign that reflects a commitment to work with practitioners to develop the right approach.

iF you HAVE MoDiFiED An ExiSting AgiLE AppRoAcH oR DEVELopED A nEw onE, wHAt DRoVE tHAt woRk?

0%

10.3%

Audit reviews

22.2%

Process review by PMO or

similar group

44.2%

Project completion reviews/lessons learned

18.6%

Requests/feedback

from customers

30.8%

Requests/feedback

from project stakeholders

43.9%

Requests/feedback

from project teams

15%

Other

50%

40%

30%

20%

10%



27. whAT wERE ThE MAJoR AREAS ThAT YoU MoDIfIED?Most respondents indicated that the changes that they had made were fairly substantial (only 27.8% of respondents indicated that they had made changes in only one area). As expected, the process area was the largest in terms of change with 65% of respondents indicating that they had made changes. Given this relatively high number, it was a little surprising to see that training was only changed by 18.5% of respondents – indicating that there was a belief that the process and other changes could be absorbed without any modified training. Whether this indicates that the changes were relatively minor, that the investment in custom training wasn’t considered beneficial or some other reason is a matter for speculation.

All of the other areas were relatively even in representation and showed a relatively high degree of change overall – of the 72.2% of respondents who indicated multiple areas of change, the average was 2.9 areas (out of a total of only seven options).

wHAt wERE tHE MAJoR AREAS tHAt you MoDiFiED?

0%

80%

60%

40%

20%

65%

Processes

32.2%

Roles

43.8%

Templates

31.4%

Terminology

40.2%

Timing/frequency of cycles

18.5%

Training

6.6%

Other

28. whAT wERE ThE MAJoR EXPECTATIoNS of ThAT woRK?We next asked participants to tell us what drove those modifications that they made. Most respondents (80.2%) had multiple drivers and there was a clear separation of the most popular reasons from the others. Stakeholders (customers, sponsors and project team) along with schedule and scope were significantly more important drivers for respondents than the other criteria (this is consistent with earlier responses of the drivers for choosing one particular approach over another).



The large gap between these five criteria and the other responses may suggest that there is a level of inertia that has to be overcome before organizations will consider going to the time and expense of making modifications to a process – for many survey participants, it would appear that there has to be an expectation of improvements to multiple areas, particularly the five key ones.

Improved budget compliance

Improved customer satisfaction

Improved functionality (scope) compliance

Improved governance/policy compliance

Improved project team comfort/morale

Improved repeatability

Improved schedule compliance

Improved stakeholder acceptance

Other

0% 60%50%40%30%20%10%

29. wERE ThE EXPECTATIoNS MET/wERE ThE MoDIfICATIoNS SUCCESSfUl?We next asked people to tell us whether the changes that they had made to their Agile approaches were successful. 29.9% of survey participants who had made modifications said that it was still too early to tell, but of those who had been able to make a determination, 50% said that the changes that they had made had been fully successful and 26.5% said that the changes had been partially successful. The reasons given for the modifications not (yet) being fully successful were extremely varied: The general consensus was that the changes had made things better, but that there were still some minor adjustments that needed to be made. The following comments were typical:

• “Continuous improvement means we are never satisfied and always trying new approaches.”

• “The organization was thrilled with outcomes. The project team felt we could do better.”

• “We continue to evolve.”

The story wasn’t all positive: There were some respondents who indicated that challenges remain for a variety of different reasons, from resistance to change and staff acceptance to customer satisfaction.



The good news is that only 8.1% of those who had formed opinions on the success of the modifications felt as though they had failed, a clear indication that work to modify standard approaches to better suit the unique needs of an organization have a high likelihood of success. The remaining respondents who indicated that the modifications were far enough advanced to form an opinion on their success said that they weren’t sure whether the changes had been successful. This may point to a lack of visibility by the individual respondent, but it may also indicate a failure to establish criteria against which the modifications would be measured.

30. If YoU hAVE NoT MoDIfIED A STANDARD APPRoACh, Do YoU ThINK ThAT YoUR oRGANIZATIoN wIll REqUIRE A MoDIfIED/IN-hoUSE APPRoACh IN ThE fUTURE?The final process-related question that we asked focused on future plans for modifications. While 53.4% felt that no modifications would be required, among those that did feel that changes would be necessary the belief was that they would need to come sooner rather than later. 23.7% of respondents (51% of those who felt that changes would be required) believed that the changes would need to be made within the next 12 months. This seems to support what we saw in the previous few questions – that organizations are broadly happy with the Agile approach that they have chosen but feel that there are some improvements that they can make. The relatively short timeframe for those changes also suggests that they have good visibility into the required improvements.

The concept of “growing out” of the current process at some point in the future doesn’t really seem to be a concern. Only 4.7% of respondents and 10% of those who felt changes would be necessary thought that those changes would occur in more than three years.

No Not sure Partially Yes, fully 8.1% 15.4%26.5%%50%



iF you HAVE not MoDiFiED A StAnDARD AppRoAcH, Do you tHink tHAt youR oRgAnizAtion wiLL REQuiRE A MoDiFiED/in-HouSE AppRoAcH in tHE FutuRE?

No

Yes – within 1 year

Yes – in 1–3 years



23.7%

53.4%

3.8%

0.9%

18.2%

31. DoES YoUR oRGANIZATIoN MAKE USE of AGIlE MENToRS who hElP GUIDE ThE woRK of NEw PRACTITIoNERS?We briefly looked at the role that Agile mentors played and found that only 42.1% of organizations had Agile mentor roles. Although there was some alignment of the mentor with the size of the organization – only 29.1% of organizations with fewer than 500 employees had the role compared with 57% of organizations with more than 15,000 employees – this is still a relatively low number. The percentage of projects also didn’t provide an indicator of the likelihood of an Agile mentor in place. While the 0–19% range was the lowest (with only 32.5% of organizations in this bracket having the role), the next smallest was organizations where 80–100% of projects were Agile – only 45.5% had Agile mentors. One could argue that when all of the projects are Agile, there is less need as there will be more Agile experts. But this is also a situation where it is vital that new project resources gain Agile skills.

Agile mentors appear to be a function that is underutilized in many organizations; consideration of adding them to the Agile skills mix may help with both ramp-up and acceptance.

Yes No42.1% 57.9%

Top Tip!

Agile mentors are an underutilized resource. Help yourself to stand out from your competition by using mentors to improve the effectiveness and efficiency of your Agile implementation.



32. whAT PERCENTAGE of YoUR AGIlE PRoJECTS ARE SUPPoRTED bY SofTwARE SPECIfICAllY DESIGNED foR ThE AGIlE APPRoAChES YoUR ARE EMPloYING?Our next area of focus was the fit of Agile with the organization’s overall portfolio execution. We started by asking what percentage of Agile projects were supported by Agile specific software. Of those whose organizations used Agile for at least some of their projects 21.8% had fully implemented Agile project execution support software with 80+% of their projects using it. However, at the other extreme, 59.1% had less than 0–19% of their projects supported by Agile software. While this indicates that once organizations adopt software it rapidly become the standard for Agile execution, this also suggests that the use of software is by no means automatic.

wHAt pERcEntAgE oF youR AgiLE pRoJEctS ARE SuppoRtED by SoFtwARE SpEciFicALLy DESignED FoR tHE AgiLE AppRoAcHES youR ARE EMpLoying?

0–19%

80–100%

60–79

40–59%

20–39%

59.1%6.7%

21.8%

7.3%

5.2%

When we look at the breakdown of the numbers in a bit more detail, we find that the largest companies are less likely to use software than the smallest. 65.4% of organizations with more than 15,000 employees used software on less than 20% of their Agile projects, compared with 57% of those with fewer than 500 employees. Only 18.5% of the largest organizations used software on more than 80% of their projects, compared with 22.8% of the smallest.

Perhaps more surprisingly, 31.8% of organizations who said that Agile projects represented more than 80% of their project portfolio said that they used Agile support software on less than 20% of those initiatives – and only 39.4% of these organizations had a fully rolled-out software infrastructure covering more than 80% of their initiatives.



33. If YoU USE SofTwARE SPECIAllY DESIGNED foR AGIlE APPRoAChES, IS ThAT SofTwARE CoMPATIblE wITh ThE PRoJECT MANAGEMENT SofTwARE USED bY YoUR PMo oRGANIZATIoN?We asked those respondents who used software designed to support Agile initiatives whether that was compatible with other project management software used within the organization. 51.3% of respondents who used software said that there was some degree of compatibility, although only 19.9% said that the software was fully compatible (the remaining 31.4% saying that the compatibility was rather limited).

Perhaps surprisingly, the majority of respondents who said that there was no compatibility felt that this didn’t present a barrier. The 48.7% of respondents who said that their software wasn’t compatible was made up of 12.3% who said that the lack of compatibility was an obstacle to the PMO and 36.4% (almost 3 times as many) who said that it wasn’t an obstacle.

iF you uSE SoFtwARE SpEciALLy DESignED FoR AgiLE AppRoAcHES, iS tHAt SoFtwARE coMpAtibLE witH tHE pRoJEct MAnAgEMEnt SoFtwARE uSED by youR pMo oRgAnizAtion?

Yes

Yes, in a limited way

No, and it is a PMO obstacle

No, but it is not currently a PMO obstacle

19.9%

31.4%

12.3%

36.4%



34. how wEll Do ThE METhoDS YoU ARE USING woRK wITh ThE MEASURES AND DRIVERS REqUIRED bY YoUR PMo?We asked people about the fit between their Agile approaches and the metrics that the PMO used to monitor and measure success. The responses suggest that for many organizations, this is still an area that needs to be worked on. This isn’t particularly surprising considering that many traditional waterfall-based metrics will not map directly to Agile initiatives. However, two-thirds (66.6%) of those who used Agile still said that they were satisfied (or better) with the fit between their chosen Agile methods and the metrics and measures used by their PMO. However, the majority of this group – 44.7% of the total survey and 67.2% of the satisfied or better group – fell into the satisfied group with room for improvement identified.

How wELL Do tHE MEtHoDS you ARE uSing woRk witH tHE MEASuRES AnD DRiVERS REQuiRED by youR pMo?

Extremely well

Very well (very satis�ed, small room for improvement)

Well enough (satis�ed, but room for improvement)

Not well at all

Not very well (they get us by, but there is lots of room for improvement)

14.3%

44.7%

8.9%7.5%

24.5%

Looking at the results based on the percentage of Agile projects that are undertaken within the organization reveals some interesting results. We might expect those organizations with a high percentage of Agile projects to have a better fit with the PMO’s metrics – Agile would be less of an outlier approach for those organizations and it might be easier to measure success using Agile-focused measures. Looking at organizations that had the largest percentage of Agile projects (80+%), we see that a greater number were satisfied with their measures – but a relatively high 22.7% of respondents said that they fell into the “not very well” or “not well at all” categories. More positively, while the organizations with the lowest percentage of Agile projects (below 20%) had the lowest satisfaction rate, 59.8% still described them as satisfactory or better.

Top Tip!

waterfall and Agile methods need to co-exist, and organizational commitment to Agile is going to depend in part on the ability to align the measurement of performance across the different approaches.



35. wAS YoUR IMPlEMENTATIoN of AGIlE DRIVEN fRoM ThE ToP DowN, boTToM UP oR A MIX?We asked organizations how their Agile implementation had occurred, and an almost equal number said that there was a top-down implementation (24.4%) as said that there was a bottom-up one (23.4%). The fact that almost one in four implementations has been executive driven is perhaps the most telling evidence that Agile approaches have successfully demonstrated their ability to deliver significant tangible benefits. Encouragingly, more than half (52.2%) of implementations have been a mix of bottom up and top down, suggesting a collaboration at all levels of the organization in order to maximize the chances for success.

wAS youR iMpLEMEntAtion oF AgiLE DRiVEn FRoM tHE top Down, bottoM up oR A Mix?

Top down

Bottom up

A mix

24.4%

23.4%

52.2%

36. whICh of ThE METhoDS/ToolS YoU USED wAS MoST USEfUl IN foSTERING CollAboRATIoN?This question allowed survey respondents to provide free-format responses to identify the Agile methods and tools that they felt were most helpful in allowing people to collaborate and work together. The range of responses was broad, but there were a number of themes that developed. In terms of software tools, the top three were SharePoint, JIRA and Rally. However, a wide variety of tools were mentioned, including tools that we wouldn’t necessarily consider as collaboration tools. They ranged from Excel, Outlook and PowerPoint to Team Foundation Server, Project and Primavera. Of the



“our organization had already focus on collaboration and teamwork so it’s not really a change.”

more traditional collaboration type tools, there was still a lot of variety from Skype and GoToMeeting to Clarity.

While tools played an important part in respondents’ views of what was fostering collaboration, the majority of responses focused on different elements of Agile approaches or of the team environment. Daily standups were mentioned by more than 10% of survey respondents as one of the keys to collaboration, and co-location was also a common theme. Training was also mentioned, and while that isn’t necessarily a tool that we typically think of as facilitating collaboration, this comment sums up the general sense: “Training managers and stakeholders to understand Agile taught them to hold the teams responsible for burn down, continuous delivery and sprint schedules.”

One of the other items that came out from this survey was that collaboration wasn’t always being given priority. While this wasn’t expressed by a large number of respondents, the comments are quite telling: “To the best of my knowledge no methods/tools have been embraced for fostering collaboration; however, we have several tools that could be utilized, such as Clarity PPM. User Adoption and knowledge are key factors” and “The move to Agile is being driven by CIO and VP of PMO without much collaboration from project managers.”

One other theme that came out is that sometimes the simplest methods are the best: whiteboards and sticky notes were often mentioned.

“we struggle with collaboration due to cultural and logistical concerns.”



37. Do YoU USE ANY SoRT of SofTwARE-SUPPoRTED RoADMAP To GUIDE AND/oR TRACK RElEASES?We asked survey respondents whether they used software to help them manage a release roadmap for their Agile products. While a large number of respondents said that they did utilize software to help them with managing the roadmap, this was still the minority – 46.9%, with 53.1% not using software to support their release roadmap. As we would expect, the percentage increases with the use of Agile project support software, but 38.1% of respondents who said that 80+% of their projects were supported by Agile specific software tools still didn’t use software to help manage the roadmap.

Do you uSE Any SoRt oF SoFtwARE-SuppoRtED RoADMAp to guiDE AnD/oR tRAck RELEASES?

Yes No46.9% 53.1%

38. Do YoU hAVE foRMAl (INTERNAl oR EXTERNAl) CoMMUNITIES of PRACTICE ThAT YoU DEPEND UPoN foR GUIDANCE AS YoUR AGIlE EffoRTS MATURE?Of those organizations that undertook Agile projects, a small majority did leverage communities of practice (51.1%). Internal communities were the most popular (25.4%), followed by a combination of both internal and external (18.1%) and external only (7.6%). It is perhaps surprising that only a little more than one in four (25.7%) respondents said their organizations leveraged external communities of practice.

The split (with around half of community users being internal only, the other half made up of external users and both categories combined) was relatively



consistent regardless of organizational size – the larger the company, the more likely an organization seemed to be to leverage communities of practice (62.2% of organizations over 15,000). 30.5% leveraged external communities in some way, representing 49% of the group of community users. For the smallest companies (less than 500 employees), only 42.6% used communities of practice and 20% leveraged external communities, representing 46.9% of the group of community users.

Do you HAVE FoRMAL (intERnAL oR ExtERnAL) coMMunitiES oF pRActicE tHAt you DEpEnD upon FoR guiDAncE AS youR AgiLE EFFoRtS MAtuRE?

Both internal and external

Internal

External

No

25.4%

48.9%

7.6%

18.1%

39. whAT Do YoU ThINK ThAT YoUR oRGANIZATIoN NEEDS To Do To IMPRoVE ThE PERfoRMANCE of AGIlE PRoJECTS?This is clearly a very open-ended question, and we allowed respondents to provide free-format answers. Although some of the responses reflected very specific situations in the participant’s organization, there were also a number of common sentiments expressed. Management buy-in was mentioned by some respondents, but was not a major sentiment (only around 4% of survey participants cited the need).

Where management was the driver of Agile – the top-down implementation scenarios – there were concerns that the implementation was not being executed properly, with comments ranging from suggestions that the implementation had not been well thought through (“clear roadmap”) to indications that the approach being implemented was not really Agile (“either embrace it fully or not – currently the disconnects are trying to hybrid waterfall with Agile” and “I feel we still mix with waterfall methods on some of the development lifecycles instead of being pure Agile”). One respondent was a little more direct: “Blow it up and start over.”



For implementations that were driven from the bottom up, we saw more concerns around acceptance and understanding:

• “Better understanding of product owner role, agreement on approach”

• “Increase understanding of benefits”

• “Understanding and communication on what Agile is and how it will help us”

When the implementation was a mix of top down and bottom up, there were still issues – and these were sometimes more fundamental: “Change in culture to fully support agile thinking – be agile, not just do agile”. But there was also a theme of fewer real issues and more opportunities for improvement:

• “Continuously reflect and improve”

• “Faster retention and acceptance of lessons learned during retrospective”

• “More formal knowledge about methodology and learning from best practices”

Customers were singled out as an area where improvements could occur:

• “Increased awareness and expectation setting with the client, and clearer/aligned SOW statements that reflect an Agile set of deliverables/lifecycle”

• “Developing projects in close contact with the customers with frequent interactions with the actual users of the products is paramount to the success of Agile methodologies in my opinion”

There was also mention made by a number of survey participants about the benefits of including customers in Agile training to help them understand both the benefits of the approach and the role that the customer has to play.

Within Agile teams, the recurring themes were around the need for more training for both team members, product owners and stakeholders as well as the need for improved standardization and the use of supporting tools:

“Organization should focus on enterprise level project management tool which can support E2E Agile deployment and other project management activities. Otherwise there would be many local solutions which may not ensure standardization.”

40. whAT Do YoU ThINK IS ThE bIGGEST ShoRTCoMING of EXISTING AGIlE METhoDoloGIES?The final question that we asked generated the broadest range of responses – which is positive in that it suggests that there are not major shortcomings that need to be addressed. At the same time, that makes refinement more difficult by requiring solutions to be more tailored for each unique situation. There were



some themes that developed, but it would not be fair to consider these as broad trends as the responses were so diverse.

Respondents did identify problems with Agile in larger initiatives:

• “Scaling to large projects and systems development across many products in an overall system and portfolio”

• “Don’t work as well for very large, complicated software projects that require a significant amount of architectural design up-front”

Aligned with this are concerns over the ability of Agile to support systems infrastructure/architecture: “They do not specifically address building a solid technical architecture. This has to be a conscious effort so teams do not build a solution that is built on a shaky foundation.”

Issues were also addressed with integrating Agile and waterfall-based projects and/or approaches:

• “Difficult to integrate Agile projects into Waterfall programs”

• “Tracking against waterfall projects”

This also led to comments about the difficulty of adapting to Agile in organizations that are more used to traditional approaches: “confusing terminology, difficulty to change the culture from a waterfall method.”

Other respondents indicated that they were finding limitations with Agile as they tried to expand it beyond traditional software development projects:

• “Difficult to adapt to non-software projects”

• “Focused too much on product development rather than a broader set of technical projects”



SURVEY ANAlYSIS AND RECoMMENDATIoNS

It is expected that standard approaches will need to be modified to meet the unique needs of each organization – and that those approaches will continuously evolve based on feedback and lessons learned along with the sifting demands of the organization.

Why should Agile be any different?



SURVEY ANAlYSIS AND RECoMMENDATIoNS

The section above provides an overview of the responses received to each of the questions, but it also identifies some trends and themes. In this section, we want to explore the major themes in more detail and make some specific recommendations that we believe will assist organizations in successfully growing and evolving Agile. We also hope that this can serve as an evolutionary roadmap for organizations that have not yet committed to Agile within their suite of project execution approaches.The following themes will be explored in more depth:

• Committing to Agile is a journey, not a destination

• As Agile grows, so do the commitments that you need to make to support and nurture it

• Agile is not an excuse to avoid metrics

• The future is changing



Top Tip!

Agile represents an ongoing commitment to an additional project execution approach alongside waterfall. it should not be undertaken without recognition that it requires a cultural shift that will have a profound impact on project execution throughout the organization.

AGIlE IS NoT A PlACE, IT’S A wAY of TRAVEllING

When many organizations talk about Agile, it is as a decision to

“do” Agile or not. There is likely recognition that it is not necessarily a simple decision that is taken one day and has a solution in place the next day, but there is frequently a belief that Agile will be implemented and is then complete. In the same way that traditional project management approaches have evolved and changed over the years that they have been in use within organizations, Agile represents a lifelong commitment to managing an additional way of executing projects.

In our survey, only 3.7% of participants used a single Agile approach in a completely unmodified form. 96.3% used either multiple approaches, modified approaches or (in most cases) both. Given that in many organizations Agile is still a relatively new approach, it is clear that organizations need to begin their journey toward Agile with the expectation that they will need to enhance, modify and supplement their approach as their maturity grows.

Further, because Agile has demonstrated a consistent ability to deliver significant project execution enhancements in a relatively short period of time, the demands on the method are likely to grow and expand rapidly. In other words, when an organization sees what Agile can deliver it will want to maximize those benefits and eliminate any barriers to success as quickly as possible.

This requires organizations to make a commitment to go beyond “doing” Agile to actually become Agile – large “A” and small “a”. An organization that is considering committing to the implementation of an Agile approach to project execution is also committing to a willingness to swiftly adapt and evolve the way that it applies Agile methods. As adoption grows and the limitations and opportunities of the selected approach/approaches is better understood, so the need to customize and enhance those methods becomes more urgent. Otherwise, the benefits of Agile will start to erode – it becomes just another project approach. As one person put it:

“They are becoming mainstream approaches, quite similar to waterfall.”



Only a little more than half of respondents (52.2%) said that they had implemented Agile with a combination of top-down and bottom-up implementations, but we believe that this two-pronged approach is critical to success. Where organizations drove their implementations from the bottom up, we saw concerns about organizational buy-in being expressed; and when we saw top-down imposition of Agile, we saw challenges around a lack of clear understanding of the roadmap and a perception that at times the effort was to add Agile elements to waterfall.

Survey respondents gave a very clear warning against a top-down implementation – while only 12% of participants overall said that they had stopped using an Agile approach, that number increased to 20.4% of organizations that had imposed a top-down implementation. Bottom-up implementations had the lowest

“failure” rate at 9%, but this has to be tempered by the fact that many

of these are still small, pilot-type implementations for a small subset of the organization’s projects rather than organization-wide rollouts.

We also believe that organizations need to consider not just Agile itself but how it will integrate with existing organizational practices and tools. We know that Agile success depends in part on an ability to change organizational culture to accept the different way that Agile initiatives are executed, but that doesn’t mean that we have to accept an inability to measure the progress of Agile initiatives. We’ll look at details later in the “recommendations” section, but organizations should begin their Agile journey expecting to have to integrate with existing waterfall-based project execution methodologies and processes. They should also expect to invest in tools that not only support Agile, but that can help to distill common metrics from all types of project – and that may require changes to existing project support tools.



AGIlE GRowS qUICKlY – wITh ThE RIGhT NURTURING

In the last few years, we have seen Agile move from a niche way of conducting R&D projects to a mainstream project execution approach that is recognized as offering significant advantages over waterfall in the right circumstances. As adoption and acceptance has grown, so has the support industry that is designed to help organizations succeed with Agile. This includes everything from certifications to software tools, and of course a huge amount of training and guidance.

However, the fundamentals to success of Agile are no different than for any other process-based initiative within an organization – it needs to be executed, measured and enhanced in an ongoing cycle of improvement. Certification can help to provide evidence of expertise with Agile (and software can help to provide a framework for that growth and evolution to occur), but there is no substitute for an organization’s own internal process management and improvement.

The good news is that many organizations are recognizing that they need to make changes to their processes – and many of those changes have been

successful. When we asked survey respondents whether the modifications that they made to their projects had been successful, 76.5% said that their changes had been at least partially successful. But when we start to look at those numbers in more detail, it becomes clear that there are still opportunities for improvement. Only 42.1% of organizations used Agile mentors, but when we look at the success of modifications within organizations that do use mentors we find that the 76.5% success rate increases to 85.8% (and the percentage that said that their implementation was a complete success increased from 50% to 55.1%).

The same is true when we look at any of the areas of support that we looked at – companies that used software to support their roadmap and/or track releases saw an 84.1% success rate for modifications. When we looked at the use of Agile support software for managing initiatives, those who used software on less than 20% of their initiatives saw a 72.5% success rate, while those with 80% or more of their projects supported by such software saw an 88.2% success rate.

Top Tip!

the best chances of success come from investment in a support infrastructure. Agile can be successful without the adoption of support resources and tools, but the chances of success increase dramatically once a support organization is in place – and it demonstrates a clear commitment to Agile on a continuing basis.



Jesse Fewell, Founder of PMI’s Agile Community of Practice notes that while Agile has rapidly expanded in breadth, it has been much slower in gaining depth within organizations. He points out that for many organizations “Agile is seen as a silver bullet, not as a fundamental rethinking of how projects are conducted – and that results in short lived benefits”. He also points out that Agile “doesn’t solve issues with corporate strategy, it is an execution approach”, and that is the inherent message here – organizations have to ensure that their corporate strategy and project execution approach (Agile and traditional) are in alignment and they need to invest in the continued evolution and enhancement of those approaches.

It shouldn’t come as a huge surprise that organizations stand a better chance of being successful in growing and evolving their Agile implementations when they create an environment designed to support that evolution, and these numbers back that up. However, there are still relatively low adoption rates for these tools – 59.1% of organizations use Agile support software on less than 20% of their projects, 53.1% have no software to support and/or manage the roadmap and 57.9% of organizations make no use of mentors. As the final – and perhaps most telling – data point on this, the success of modifications for organizations that had no mentors, no roadmap software and no Agile project support software was just 55.1%.



AGIlE DoES NoT MEAN “MEASUREMENT fREE”

One of the challenges that organizations have found with Agile is the perceived difficulty in measuring success using traditional project execution metrics. In the early days, this was almost acceptable because the performance of projects executed with Agile methods was so much better than traditional waterfall-based project execution. Of course, over time this became the “new norm” – and the need to demonstrate continued improvement became just as important as ever, but with less understanding of how to do that in an environment that was still set up to measure waterfall-based performance.

Allan Mills, Engagement Manager at Digital Celerity, describes the problem by saying that Agile is a

“different language and we need to translate Agile to business language.” Mills stresses that it is this ability to focus on measurement in business terms that will ultimately define success as it allows for an apples-to-apples comparison.

It is therefore surprising that so many survey respondents (65.7%) said that they were satisfied or better with the

way that Agile methods work with PMO measures and drivers. While most of them said that there was still room for improvement, this implies that there is a level of acceptance around Agile methods that allows for lesser degrees of measurement. The alternative is that organizations have already established the ability to translate Agile to business language, and that doesn’t seem to be the case – the following comments on how the organization needs to improve Agile come just from the group that says that Agile methods fit “extremely well” with the measures and drivers required by the PMO:

• “Aligning the organization for Agile”

• “Faster retention and acceptance of lessons learned during retrospective”

• “Improve feedback cycles”

• “Give the project teams more leeway in modifying (but not throwing away) processes. As the team gain confidence/comfort with the new processes, trust them to know how best to adapt.”

Top Tip!

Agile only succeeds if it helps to improve an organization’s overall performance – its ability to achieve the goals and objectives that are set out in annual plans. Measuring Agile project performance against those goals and objectives not only makes success clear, it also provides a way to objectively compare Agile and waterfall performance.



The ability to align Agile execution with the underlying business benefits is essential to success. As Halim Dunsky of SolutionsIQ puts it:

“We need to couple results with expectations and break down delivery into smaller pieces to generate more frequent feedback.” In many ways, this ability to generate more frequent feedback can make it easier to demonstrate that Agile methods are delivering business value. The small delivery pieces that Dunsky describes align with the Agile philosophy of development and allow for measurement of actual results against expected results earlier and more

frequently than in a traditional project execution environment. As Dunsky says, “The organization becomes more agile.”

We firmly believe that Agile projects need to be measured against the same fundamental business measures as all other projects. Did the organization gain the expected benefits for the expected costs (financial, risk, quality, etc.)? This alone allows for legitimate comparison with traditional waterfall projects and provides the foundation for integrated reporting and tracking.



AGIlE of ThE fUTURE IS GoING To bE DIffERENT

There is no reason to think that the speed of evolution that Agile has gone through in the last decade is going to decrease in the years ahead. In fact, there will be increasing pressure for further evolution as organizations look to scale Agile to larger, enterprise-wide initiatives and to greater integration with the overall portfolio management strategy of the organization.

We see evidence from the survey that this is starting to happen – 23.7% of respondents who have not yet modified their approach to Agile execution expect to do so in the next 12 months, and 41.9% expect to do so within three years. 39.6% of survey respondents said that they didn’t use Agile-specific software yet, and the assumption has to be that the adoption rate of this software will increase as Agile becomes more embedded. Of those organizations that do use software, only 19.9% were fully satisfied with the way that it integrated with the PMO’s traditional project management software – again suggesting that changes are inevitable as Agile grows and evolves within those organizations. 12.3% of respondents say that this lack of integration is already causing problems, and this number will inevitably grow as Agile and waterfall projects exist in parallel.

Outside of the pure statistics, the comments from participants back up

these trends. Looking specifically at the implementation of Agile within respondents’ organizations:

• “More standardization of processes & integration with waterfall methods”

• “Tailor Agile to better fit with our existing governance structure”

• “Standardize on reporting status metrics”

• “Refine its methodologies. Get clear communication of what is needed for reporting on these projects. Define clear integration of reporting data for agile and waterfall projects as they overlap in the PMO portfolio.”

Issues weren’t just expressed with the way that Agile was implemented

– the same sentiments were expressed around the Agile methods themselves. When asked about the biggest shortcoming of existing Agile methodologies:

• “We have uncovered scaling limitations”

• “Scaling to large projects and systems development across many products in an overall system and portfolio”

• “Lack of options for distributed teams”

• “Fragmentation of agile communities and networks”

Top Tip!

Agile will continue to grow and evolve – and will become broadly accepted as a mainstream project execution approach alongside waterfall. However, practitioners need to invest in ensuring that their implementation is as well managed and executed as possible and they need to take ownership of that themselves, developing the same infrastructure as is provided to waterfall-based project execution. Agile may allow for a more streamlined approach to project execution, but it still requires a comprehensive organizational implementation model.



There are increasing demands on Agile (both implementations and pure methods) to evolve and develop to support larger programs and initiatives – and also to rationalize the many different approaches that are currently in place. There has been a lot of talk recently about Kanban working in conjunction with other approaches (in particular, Scrum) to create a form of hybrid Agile approach; but it seems that expecting Agile methods themselves to adapt and change to the demands of unique organizations is shortsighted.

In traditional project management, there are at least as many well-known methodologies as there are in Agile, and very few organizations of any size or complexity uses them in a pure form. Instead, it is expected that standard approaches will need to be modified to meet the unique needs of each organization – and that those approaches will continuously evolve based on feedback and lessons learned along with the sifting demands of the organization. Why should Agile be any different?



fINAl ThoUGhTS

We believe that in the years ahead, Agile will gain a place alongside waterfall as an equal – organizations won’t be choosing between different approaches, but rather will be using both depending on the specific demands of the project. Clearly there will always be initiatives that are better suited to one approach over another, and there will always be some initiatives where either approach is valid and organizations will make a decision based on their own unique circumstances.

Halim Dunsky says that a lot of the ability for Agile and waterfall to coexist comes down to the attitudes of practitioners. “Some people respond collaboratively and some don’t. Agile is different at a practice level, but it is also different at a mindset level requiring empowerment and emergent design. If the organizational culture values collaboration, then Agile works; if the culture values competition, you get different results.”

To us, this sums up a successful Agile implementation perfectly – if the organization tries to use the same culture for Agile as has been implemented for waterfall, then success is going to be difficult. If the differences are embraced and the focus is on results, then success can come more easily. To take Dunsky’s

thoughts a little further, a lot of the collaborative mindset requirements for Agile will also help to deliver improved waterfall performance.

We believe that organizations need to accept a need to customize Agile approaches to their own circumstances and need to invest in the skills and organizational infrastructure that will allow this to happen. This must include ways for Agile and waterfall projects to be consolidated for reporting and analysis purposes, but that alignment has to be logical and based on organizational needs rather than arbitrary templates and standards that do not reflect the current project execution environment.

Organizations need to invest in Agile mentors/coaches and need to ensure that a top-down and bottom-up approach as described above is a partnership of equals with the concerns and preferences of practitioners carrying as much weight as executives. We also consider it of paramount importance to work with clients to educate them on the advantages of Agile approaches and the implications on the relationship between vendor and customer. We strongly support the idea of including client resources in training and feedback sessions to help to enhance the approach.



We believe that software is a vital support tool for organizations, and are somewhat surprised that adoption rates aren’t higher – and that the lack of integrated tools isn’t seen as more of an issue. In recent years, project portfolio management (PPM) tools have become much more accessible and they are rapidly gaining a foothold in PMOs. Today, many of those tools are capable of supporting Agile and waterfall approaches. If organizations carefully define their requirements for a PPM tool to support and consolidate these two different approaches, they will find that suitable tools are available. These tools will need careful implementation and will need to evolve with the organization, but they can provide the groundwork for success.

Jesse Fewell points out the irony of using tools with Agile – “the great irony of Agile is that the start of the Agile manifesto says ‘we prefer individuals and interactions over processes and tools’, while Enterprise adoption focuses on processes and tools”. Fewell’s perspective is that organizations need to focus on expertise – in products, in soft skills and in the interplay between market demand and products, and we strongly agree. Tools can only enhance Agile implementations when they are deployed on top of culture, commitment and expertise.



AboUT PRoJECTMANAGEMENT.CoM

Since 2000, our mission has been simple: to make project managers more successful. projectManagement.com is the experience bridge that fills in the gaps—providing help to project managers in a number of ways. it is a community, your community, for project managers in information technology and other industries. we are your one-stop shop for pM answers, helping get you “unstuck”—and confidently meet every new challenge that comes your way with over 4,000 articles from industry experts, over 1k Deliverable templates to save you time and more than 550k peer connections and experts to offer specific advice.

AboUT CA TEChNoloGIES

project and portfolio Management (ppM) solutions from cA technologies empower you to innovate with agility, transform your portfolio with confidence, and optimize the right resources and investments to manage business demands. with the most complete and proven project and portfolio management solution in the industry today, your team can be more productive and your leaders will have the transparency and visibility into the entire portfolio to ease decision making.

copyright © 2001–2013 projectManagement.com

Acknowledgements

we’d like to thank all the people who completed the survey on projectManagement.com and were interviewed for this research.

About the Author

projectManagement.com research analyst Andy Jordan is a well-known author and speaker on project management and related topics as well as an experienced project, program and pMo leader. Andy runs Roffensian consulting inc. in ontario, canada with customers across north America and around the world.

SponSoRED by


agile evolution report - project management · agile implementation and have undertaken preliminary...

Documents