when agile fails

7/30/2019 When Agile Fails

1/39

Craig D. Wilson, MS, PMP, CSM

Matincor, Inc.

IT Management Consulting


2/39

Slide 2 of 39

IT Management Consultant

10+ years of service as an independent consultant precededby 10+ years of senior and executive managementexperience in several Fortune 500 companies

Graduate degree in Management Science, additional post-graduate studies at UCLAs Anderson School, ProjectManagement Professional (PMP), Certified Scrum Master(CSM)

Specializing in program / large project management, projectturn-around, and team and organizational development

Copyright Matincor, Inc. 2013


3/39

Slide 3 of 39Copyright Matincor, Inc. 2013

Presentationassumption:

Audience isfamiliar with

Agile conceptsand perhaps a

specific Agilemethodologysuch as Scrum

or Kanban


4/39

Slide 4 of 39

Practice & precepts based on lessons learned from60+ years of software development experience

Most key concepts in use for decades (e.g.; time boxes,iterative development, self-managed teams, co-location, rapid delivery)

Now packaged in several popular frameworks andmethodologies (e.g.; Scrum, Extreme Programming,Kanban, FDD, Crystal, UP lite, Disciplined AgileDelivery)

No single Agile methodology addresses everything!

Past experience can help with successfulimplementation of Agile



5/39

Slide 5 of 39

While strongly supporting Agile

Lets not turn a blind eye to the fact that manylight weight Agile methodologies cover only ahandful of the practices necessary for effective

software development projects

Nor ignore the fact that some companies do apoor job of introducing and executing Agileconcepts and precepts



6/39



7/39

Slide 7 of 39

Project management and software development,

Agile or otherwise, are huge topics impossible tocover in one brief presentation

This presentation is intended only to provide a fewexamples to get the audience to think about their

experience and use it to supplement the oftenlight weight Agile methodologies

My observations are based upon personalexperience and may differ from other Agile

proponents. You must use your own experience todetermine what will work best for your situation.

(Dont follow the GPS instructions over a cliff!)



8/39

Slide 8 of 39

Key benefits of Agile include opportunities to

quickly achieve high value features anddiscover problems early

A focus on delivering working solutions asrapidly as possible with minimal re-work

However, we can have problems with a project

using an Agile methodology just as we canhave problems with any project approach

But, if you did it correctly, you wouldnt have problems!



9/39


Project results we want Project results we get

exercise

slothdiscipline

lazy

hard work silver bullet


10/39

Slide 10 of 39

The Beginning

The Middle

The End



11/39

Slide 11 of 39

Inception

Construction

Transition



12/39

Slide 12 of 39

Most Agile methodologies and literature focus

on the middle of the project There are preliminary and follow-on activities

that are required to effectively execute an Agile

project or program

Other areas of the organization are impactedby adoption of Agile



13/39


Scrum image used by permissionMountain Goat Software

Copyright 2005


14/39

Slide 14 of 39

Inception Construction Transition

Management

Team

Stakeholders


Scrum image used by permissionMountain Goat Software

Copyright 2005


15/39



16/39

Slide 16 of 39

Enterprise strategic goals, PPM, ROI targets,

cost-benefit analysis, feasibility studies allstill exist

Approach (e.g.; all Agile, combination Agile & traditional,distributed teams, shared teams)

How will teams be monitored, motivated &rewarded?

How will projects be terminated?

Product Owner has achieved sufficient value Early results indicate potential product/project

failure



17/39

Slide 17 of 39

Build cross-functional team with shared responsibilityfor project success Must provide training if team new to methodology Identify Product Owner and ensure they understand their

role & responsibility

Define done very specifically

Identify & define leader/coach role depending uponteam needs Scrum Master / Agile PM role will evolve as team matures and

experience is gained

Scope the project Prepare project scope and initial requirements backlog Include non-functional requirements (design is emergent but

architectural boundaries are up front) Initial effort estimates



18/39


ScrumZivs Law

Uncertainty is inherent andinevitable in software

development processes and

products

Hadar Ziv and Debra Richardson, "TheUncertainty Principle in SoftwareEngineering," 1997

Sufficient up-front analysis forunderstanding & risk

reduction but not so much asto create rework.

Beware false certainty!


19/39

Slide 19 of 39

Ensure that all stakeholders are identified and

understand their needs / responsibilities Necessary in order to define done

May help to categorize stakeholders including

those external to the organization Set expectations - primary stakeholders will be

more intimately and frequently involved thanin traditional projects

Determine how to coordinate feature anditeration planning with other teams



20/39



21/39

Slide 21 of 39

Must support progress tracking based on feature

delivery May require dropping or modifying traditional

benchmarks and stage gates

Earned Value becomes more effective

Agile techniques call for more frequentrefinements of estimates than traditional processes

Death marches have always been disruptive but

even more so for Agile teams Crashing & fast tracking destroy ability to project long-

term forecasts and put product quality at risk


X


22/39

Slide 22 of 39

My hot buttons:

Need continuous backlog grooming Beware technical debt (done violations)

Continuous builds and effective regression testing

are key to quality

Maintain a sustainable pace

Cant build to a story need to define & design

Release planning & coordination are on-going


How muchtime for this

slide?


23/39

Slide 23 of 39

Rapid and easy access to stakeholders is critical to

iteration progress & success Including up-stream and down-stream process owners

Coordination with inter-dependent Agile teams is

frequent (e.g.; Scrum of Scrums) Beware of delayed communications

e.g.; monthly or quarterly coordination meetings

Disciplines may coordinate

e.g.; designers with designers, QA with QA

Product Owners have an especially key role



24/39



25/39

Slide 25 of 39

Capture project metrics and results for final

Cost Benefit retrospective Perform a project governance retrospective

Are we getting the information we need?

How can we improve in an Agile environment?

What cross-enterprise process improvements

are recommended? Beware overly prescriptive procedures



26/39


Agility at Scale:

Economic Governance, MeasuredImprovement, and Disciplined Delivery

By Alan Brown, Scott Ambler, Walker RoyceTo be published: May 2013

https://www.ibm.com/developerworks/mydeveloperworks/blogs/c914709e-8097-4537-92ef-8982fc416138/entry/agility_at_scale_economic_governance_measured_improvement_and_disciplined_delivery?lang=ent


27/39

Slide 27 of 39

May require integrated QA test, UAT, beta

testers, training, phased deployment, etc. Coordinated turn-over to down-stream

stakeholders (e.g.; operations, support)

As built documentation includingarchitecture and design, technical debt, andknown defects

Project completion retrospective and teamrecognition



28/39

Slide 28 of 39

The Land that Scrum ForgotBy Robert Uncle Bob Martin

December 14, 2010

http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot



29/39

Slide 29 of 39

Acceptance of product

Feedback to team and Product Owner

What product improvements are needed?

What inception, construction, and transitionprocesses improvements are needed?



30/39



31/39



32/39

Slide 32 of 39

Requirements hierarchy

Communication structure Interaction coordination

Integrated testing

Release planning


Program

Product

Theme

Epic

Story Story

Epic

Theme

Product

Theme

Epic

Theme

Epic

Story Story


33/39

Slide 33 of 39

Quick time boxed iterations allow a team to

adjust their feature priorities anditeration/release goals

Changes to schedule or deliverables still need

coordination with other teams andstakeholders



34/39

Slide 34 of 39

Most Agile methodologies focus only on team

dynamics Software engineering is given short shrift

Your product is likely developed using Object

Oriented programming and Service OrientedArchitecture

A basic understanding of Object OrientedAnalysis and Design will greatly improvecommunications between team members Especially between non-technical and technical staff



35/39

Slide 35 of 39

Team development Communities of Practice

Private open source code Anyone can contribute

Monitored by responsible party



36/39

Slide 36 of 39

Strictly speaking, it isnt a failure of Agile

- Not a failure of the Agile Manifesto

- Not a failure of lessons learned from 60+ years ofsoftware development

But more often



37/39

Slide 37 of 39

Cause Correction

Limitations of individualmethodologies.

For example, limited span of projectlifecycle (looking only at

development and not inception,development, transition) or lack ofcomprehensive requirementsengineering techniques.

Evaluate your organizations needsand perform a gap analysis betweenthose needs and the scope of thechosen methodology. Using your

experience, knowledge, and othersources, supplement the methodologykeeping Agile principles in mind.

Failure to apply discipline to theapplication of the methodology andprocesses.

For example, failure to groom the

project backlog or allowing technicaldebt to build up.

Enforce team discipline in theapplication of Agile concepts and theselected methodology.



38/39

Slide 38 of 39

Management of software development is

constantly evolving and improving Never stop learning (& un-learning!), never

stop pushing the envelope



39/39

Slide 39 of 39

E-mail to:

[email protected]

Visit website at:

www.matincor.com

Connect on LinkedIn:www.linkedin.com/in/matincor


when agile fails

Documents