Craig D. Wilson, MS, PMP, CSM Matincor, Inc. IT Management Consulting

WHEN AGILE FAILSCAUSES & CORRECTIONS

Craig D. Wilson, MS, PMP, CSMMatincor, Inc.

IT Management Consulting

Copyright Matincor, Inc. 2013 Slide 2 of 39

About Craig D. Wilson IT Management Consultant

10+ years of service as an independent consultant preceded by 10+ years of senior and executive management experience in several Fortune 500 companies

Graduate degree in Management Science, additional post-graduate studies at UCLA’s Anderson School, Project Management Professional (PMP), Certified Scrum Master (CSM)

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


Presentation assumption:

Audience is familiar with

Agile concepts and

perhaps a specific Agile methodology

such as Scrum or Kanban


My View of Agile

Practice & precepts based on “lessons learned” from 60+ 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 and methodologies (e.g.; Scrum, Extreme Programming, Kanban, FDD, Crystal, UP lite, Disciplined Agile Delivery)

No single Agile methodology addresses everything!

Past experience can help with successful implementation of Agile


My View of Agile

While strongly supporting Agile… Let’s not turn a blind eye to the fact that

many light weight Agile methodologies cover only a handful of the practices necessary for effective software development projects

Nor ignore the fact that some companies do a poor job of introducing and executing Agile concepts and precepts


You ignore the precepts and guidelines of Agile at your peril!

That being said, I’ve added a few

inflammatory remarks….

Because I think some Agile discussions and implementations miss the mark!


Caveats

Project management and software development, Agile or otherwise, are huge topics – impossible to cover in one brief presentation

This presentation is intended only to provide a few examples to get the audience to think about their experience and use it to supplement the often “light weight” Agile methodologies

My observations are based upon personal experience and may differ from other Agile proponents. You must use your own experience to determine what will work best for your situation.

(Don’t follow the GPS instructions over a cliff!)


Benefits & Challenges

Key benefits of Agile include opportunities to quickly achieve “high value” features and discover problems early

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

However, we can have problems with a project using an Agile methodology just as we can have problems with any project approach

“But, if you did it correctly, you wouldn’t have problems!”


The single biggest challenge…

Project results we want

Project results we get

exercise

slothdiscipline

lazy

hard work silver bullet


Three Critical Project Points

The Beginning The Middle

The End


Three Critical Project Points

Inception Construction

Transition


Why Is This Important?

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 impacted by adoption of Agile


Scrum

Scrum image used by permissionMountain Goat Software

Copyright 2005


Presentation Structure

Inception Construction Transition

Management

Team

Stakeholders

Scrum image used by permissionMountain Goat Software

Copyright 2005


INCEPTION


InceptionManagement

Enterprise strategic goals, PPM, ROI targets, cost-benefit analysis, feasibility studies – all still 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


InceptionTeam

Build cross-functional team with shared responsibility for 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 upon team

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


Beware Water-Scrum-Fall

Scrum

Ziv’s LawUncertainty is inherent and

inevitable in software development processes

and products“

Hadar Ziv and Debra Richardson, "The Uncertainty Principle in Software Engineering," 1997

• Sufficient up-front analysis for understanding & risk reduction but not so much as to create rework.

• Beware false certainty!


InceptionStakeholders

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 than in traditional projects

Determine how to coordinate feature and iteration planning with other teams


CONSTRUCTION


ConstructionManagement

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 frequent refinements 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


ConstructionTeam

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 Can’t build to a “story” – need to define &

design Release planning & coordination are on-going

How much time for this

slide?


ConstructionStakeholders

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


TRANSITION


TransitionManagement

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


Recommended Reading

Agility at Scale:Economic Governance, Measured

Improvement, 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





TransitionTeam

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 including architecture and design, technical debt, and known defects

Project completion retrospective and team recognition


Recommended Reading:

The Land that Scrum ForgotBy Robert “Uncle Bob” Martin

December 14, 2010

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




TransitionStakeholder

Acceptance of product Feedback to team and Product Owner

What product improvements are needed? What inception, construction, and transition

processes improvements are needed?


Recommended Reading:


Additional Considerations


Agility at Scale

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


Change Management

Quick time boxed iterations allow a team to adjust their feature priorities and iteration/release goals

Changes to schedule or deliverables still need coordination with other teams and stakeholders


Object Orientation

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 Oriented Architecture

A basic understanding of Object Oriented Analysis and Design will greatly improve communications between team members Especially between non-technical and technical

staff


Other Considerations

Team development – Communities of Practice

Private “open source” code Anyone can contribute Monitored by responsible party


So; when does Agile fail?

Strictly speaking, it isn’t a failure of Agile

- Not a failure of the Agile Manifesto

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

But more often……


Cause CorrectionLimitations of individual methodologies.

For example, limited span of project lifecycle (looking only at “development” and not “inception, development, transition”) or lack of comprehensive requirements engineering techniques.

Evaluate your organization’s needs and perform a gap analysis between those needs and the scope of the chosen methodology. Using your experience, knowledge, and other sources, supplement the methodology keeping Agile principles in mind.

Failure to apply discipline to the application of the methodology and processes.

For example, failure to groom the project backlog or allowing technical debt to build up.

Enforce team discipline in the application of Agile concepts and the selected methodology.


And finally…..

Management of software development is constantly evolving and improving

Never stop learning (& un-learning!), never stop pushing the envelope


Contact InformationCraig D. Wilson

E-mail to: [email protected]

Visit website at: www.matincor.com

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

mailto:[email protected]

http://www.matincor.com/

http://www.linkedin.com/in/matincor

Documents

Craig D. Wilson, MS, PMP, CSM Matincor, Inc. IT Management Consulting