How is Agile really used?

How is Agile really used?2017-10-12T22:05:26+00:00

“Its benefits come from many factors that are too numerous to mention here. The primary drivers are increased productivity and quality. Productivity comes from its streamlined nature and quality from its uncompromising discipline. However, its real power comes from its adaptability to change, collaborative nature, and focus on bottom line business results for the marketplace.” (David F. Rico, The Business Value of Using Agile Project Management for New Products and Services)

For any Agile consultant, it’s crucial to have a realistic knowledge of what happens when you implement Agile. Unfortunately there is very little hard data on this – a lot of crusading one way or another, but hard data?

But there are a few sources, which I have tried to gather here.

Who uses Agile?

First things first: how widely is Agile actually used ? According to Actuation Consulting’s (mainly US-based) ‘Study of Product Team Performance‘, the breakdown of methodologies is liked this:

Who uses what?

This naturally raises its own questions:

  • How well is Agile being used? According to Murphy et al., the most common problem with Agile, as perceived by both Agile and non-Agile teams, is the incorrect practice of Agile.
  • What part does Agile play in the various Agifall variants – more than 45% of all respondents?

Source: Murphy, B., Bird, C. Zimmerman, T., Williams, L., Nagappan, N., and Begel, A. Have Agile Techniques Been the Silver Bullet for Software Development at Microsoft?, International Symposium on Empirical Software Engineering (ESEM) 2013, Baltimore, MD, pp, 75-84.

Defining success

In 2010, Scott Ambler surveyed the Agile community to ask them among other things, how they defined success. This is how they replied:

  • Time/Schedule
    • 62% prefer to deliver on time according to the schedule
    • 34% prefer to deliver when the system is ready to be shipped
  • Cost
    • 28% prefer to deliver within budget
    • 60% prefer to provide good return on investment (ROI)
  • Functionality
    • 15% prefer to build the system to specification
    • 82% prefer to meet the actual needs of stakeholders
  • Quality
    • 29% prefer to deliver on time and on budget
    • 66% prefer to deliver high-quality, easy-to-maintain systems

Source: Scott Ambler, 2010 Agile Project Success Rates Survey Results.

Following an earlier survey, Scott concluded that “People really don’t define success in terms of ‘on time, on budget, to specification’ regardless of what the theory folks may claim. For example:

  1. 83% of respondents believe that meeting actual needs of stakeholders is more important than building the system to specification.
  2. 82% believe that delivering high quality is more important than delivering on time and on budget
  3. 70% believe that providing the best ROI is more important than delivering under budget
  4. 58% believe that delivering when the system is ready to be shipped is more important than delivering on schedule”

Source: Scott Ambler, 2008  Agile Project Success Rates Survey.

Iterations

Iteration planning

How long do people spend planning iterations? According to Scott Ambler’s Agile Planning Mini-Survey (January 2012):

Agile iteration planning time

Iteration 0

The following come from Scott Ambler’s 2013 Agile Project Initiation Survey Results.

In reply to the question “How long did it take your project team to get started?”, the average was 4.6 weeks. More precisely:

Agile - How long for Iteration 0

Copyright 2013 Scott W. Ambler www.ambysoft.com/surveys/

Length of iterations

In 2015, two-thirds of iterations were 2 weeks long:

AgileIterationLength2015Q1

Source: Scott Ambler, 2015 Q1 Agile State of the Art Survey Results.

In 2008, distribution was much looser:

Agile iteration length - 2008

Source: Ambler, S.W. ‘Has Agile peaked?‘, in Dr Dobbs, May 7, 2008.

Practices & disciplines

Agile vs non-Agile team practices

In 2013, Murphy et al. published a survey of teams using different delivery models in use at Microsoft in the US and the UK, the result of interviews and five annual surveys taken between 2006-2012. It included this summary:

Agile vs Non-Agile Team Practices

The researchers conclude:

We found no clear trends in practice adoption. Nonagile practitioners are less enamored of the benefits and more strongly in agreement with the problem areas. The ability for agile practices to be used by large-scale teams generally concerned all respondents, which may limit its future adoption.

Source: Murphy, B., Bird, C. Zimmerman, T., Williams, L., Nagappan, N., and Begel, A. Have Agile Techniques Been the Silver Bullet for Software Development at Microsoft?, International Symposium on Empirical Software Engineering (ESEM) 2013, Baltimore, MD, pp, 75-84.

Management practices & disciplines

Daily stand-up meetings

In his Agile Planning Mini-Survey in January 2012, Scott Ambler found that, perhaps not too unexpectedly, most organisations hold their Daily Stand-Up Meetings daily. Not quite everyone though:

Agile Stand-Up Meetings

Technical practices & disciplines

Technical debt

There are various definitions of technical debt. In 2010, Gartner defined it as ‘the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state’ (quoted here). This is perhaps not realistic, and it certainly isn’t very relevant to Agile. However, in their CRASH Report (CAST Report on Application Software Health) – 2011/12, the research organisation CAST Software defined it more usefully as:

Technical Debt represents the effort required to fix problems that remain in the code when an application is released.

For more on the basic concept of technical debt, see here.

How much is technical debt costing?

CAST found that:

Based on this definition and the analysis of 1400 applications containing 550 million lines of code submitted by 160 organizations, CRL estimate that the Technical Debt of an average-sized application of 300,000 lines of code (LOC) is $1,083,000. This represents an average Technical Debt per LOC of $3.61.

CAST 2012 Technical Debt By Technology

How is technical debt managed?

Scott Ambler raised this key question in 2015, in his 2015 Q1 Agile State of the Art Survey Results. This is what he found.

How do teams avoid technical debt?

 

How do teams avoid technical debt?

Source: Scott Ambler, 2015 Q1 Agile State of the Art Survey Results.

How do teams remove technical debt?

How do teams remove technical debt

Source: Scott Ambler, 2015 Q1 Agile State of the Art Survey Results.

How aware are the various IT groups of technical debt?

How aware are groups of technical debt?
Source: Scott Ambler, 2015 Q1 Agile State of the Art Survey Results.

How do organizations fund technical debt?

How do teams fund technical debt?
Source: Scott Ambler, 2015 Q1 Agile State of the Art Survey Results.

Release

In his 2015 Q1 Agile State of the Art Survey Results, Scott Ambler asked how frequently Agile teams carried out internal and production releases.

Internal releases

Ambler2015InternalReleaseCadence

 

Production releases

Ambler2015ProductionReleaseCadence

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Toggle Sliding Bar Area
Want to do more than just build systems?