Agile Software DevelopmentWhat CXO’s Need to Know

Problem: Software Projects Fail

Standish CHAOS Report, 2010

37%

21%

42%

Successful Failed Challenged

Reasons for failure:

• Incomplete requirements• Lack of user involvement• Lack of resources• Unrealistic expectations• Lack of executive support• Changing requirements and

specifications

• (Note: “Appropriate technology unavailable” is not one of these)

Developing Software is Difficult

Software development is more like R&D than factory assembly lines

People do not know what they need until they see/use it

Business-technology collaboration and alignment is essential

Analogies to construction and manufacturing are not useful

Trying to design everything in up front invites massive change

Yet organizations are siloed, relying on document handoffs and restrictive sign-offs

How Waste Creeps In

• Detailed planning/design at the beginning of a project results in constant revisions

• Over half the features developed never get used

• Large amount of work must be redone– Because of the ineffectiveness of document handoffs– Because users do not see the product for months/years

• Team waiting time (for equipment, answers)

• Task-switching and multi-tasking

• Unresolved “technical debt” makes subsequent releases challenging (plus, they take longer and longer)

It All Seems “Set Up” to Fail

The Solution• Short cycles (1-4 weeks):

– At the beginning of each cycle, figure out what are the most important things to do right now

– Demonstrate what was done at the end of each cycle (make it available for use if appropriate)

• Welcome feedback (and act on it)

• The team focuses on one thing at a time, until it is done

• Defer requirements definition until just before you build them

• Create cross-functional teams that include both business and technical people

• Promote adaptive planning and a people-centric approach

When to Use

Traditional (waterfall)

Agile (for anything

complicated or complex)

- Stacey Complexity Graph

Traditional Approach

“I believe in this concept, but the implementation described above is risky and invites failure.”

- Dr. Winston Royce (“Father of the Waterfall”), August 1970

Agile Example: SCRUM

Adaptive Planning - Pivot

• Imagine developing a social media monitoring system

Target: Police and Public Safety

Intelligence ServicesIteration 1:

Facebook group posts

Feedback: Interest, but no police subscriptions

Iteration 2: All Facebook posts

Feedback: Still no police subs, but

retailers take note

Iteration 3: UI adapted to retail market

Feedback: 10 retail subscriptions sell

Iteration 4: Twitter

Feedback: 100 retail subs

People-centric

• Trust motivated people– Build projects around motivated individuals. Give

them the environment and support they need, and trust them to get the job done.

• Face-to-face communication– The most efficient and effective method of

conveying information to and within a development team is face-to-face conversation.

• Self-organizing teams– The best architectures, requirements, and

designs emerge from self-organizing teams.

- Extract from Agile Manifesto, 2001

What it Takes

Dedicated teams

Readily available development and test environments

New metrics for progress, status

Business people assigned to IT projects

Drop the matrix, or at least multi-taskingVirtualization key; consider cloud computing (e.g. Amazon Web Services)

No more EVM, % complete; still have RYG

If you are spending $10m and can eliminate $1m in waste, why not?

Summary

• Contrary to popular belief, agile development is for complicated/complex projects

• People-centric approach that advocates self-organization and adaptive planning

• Acknowledge that this is a sea change• And that it will take time and

significant effort/commitment for the organization to transform

• Questions/Comments/Concerns?