Agile foundation and agile myths

Agile Foundation, Promises and Myths
Executive Brief
For
Turner Broadcasting PMO

Better Software Delivery
Get working software to market faster
Optimize resources
Improve predictability of delivery
Satisfy customer needs
Improve delivery capability

Software Development Circa 1994
Technology is a key driver for business strategies
But most business weren’t very successful at it

The Predictive Approach
To improve software delivery we need to:
Standardize processes
Optimize resource utilization
Perform Rigorous up-front design
Produce Comprehensive documentation
Get commitment to a definitive Scope, Cost and Schedule
Enforce strict adherence to the detailed plan

Predictive ApproachUnderlying Assumptions
Scope
Variation
All requirements are knowable initially
Requirements can be documented completely up front to guide development
Change requests provide sufficient flexibility to new and/or clarified needs
Tasks required to deliver requirements can be precisely known and estimated
Tasks must start and finish according to the predictive schedule

Predictive Approach: Underlying Assumptions
Process
Software engineering is linear in nature
Manufacturing-centric practices apply directly to software engineering

Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Predictive / agilecomparison

Get to Market Faster
Predictive Approach
The best way to finish projects faster is to dictate that all tasks be finished on time
Flaw
Variation from estimates is natural
Agile
Separate estimates from execution. Promote Road Runner behavior.

Optimize Resource Utilization
Predictive Approach
The highest ROI depends on maximum resource utilization
Flaw
Software development is not linear in nature – Optimizing resources doesn’t improve cycle time, it creates WIP and lost knowledge.
Agile
Focus on finishing and flow of work

Predictive Approach
Planning every detail up-front results in stable projects
Flaw
You don’t know where you are until you deliver things.
Agile
Frequent delivery of tested, deployable solutions provides the best learning and predictability (you can trim the tail)
Improve Predictability

Satisfy Customer Needs
Predictive Approach
Study the problem until you know everything
Flaw
We can not have perfect (even reliable) up front knowledge of all tasks, how to do them, how long they will take, or what challenges we will face.
Agile
Get started early delivering value and get customer feedback

Improved Capability
Predictive Approach
Rigorous adherence to work standards, hand-offs, and detailed “how” based process
Flaw
Every team, product, and situation is different with different needs and strengths
Agile
Engaged, fully capable, self organizing teams that are continually assessing their performance and applying situation specific strategies, processes and practices

Better ways of developing software
Agile Methods deliver on the promise:
Get to market faster
Optimize resources
Improve predictability
Because Agile is designed to deal with these realities:
Inevitable uncertainty in scope
Natural variation from estimated task effort
Non-linear nature of software engineering

Agile myths

No Planning
Origins
Comprehensive detailed planning is not realistic
Treating estimates as commitments destroys moral and value
Agile Approach
Identify major outcomes, milestones & dependencies
Plan & prioritize backlog iteratively
Establish context & simple policies

No Documentation
Origin
Detailed up front spec’s are wrong in retrospect
Perfect documentation provides little customer value but results in delays and rework
Agile Approach
Document high level, stable concepts
Just in time detail
Rich forms of communication
Focus on long lived doc’s that support adoption and achieving value

No Commitments
Origin
Tasks cannot be defined, much less estimated, up front
Committing to tasks does not ensure the project is on track
Agile Approach
Estimate the big project by order of magnitude
Commit at the sprint level
Demonstrate predictable delivery of working software
Commit to PO
Pull work - Commit to Team
Commit at OOM

No Process
Origin
Detailed process is different from task to task
And difficult & wasteful to pre-determine & enforce
Teams know the most about the task in the moment
Agile Process
Establish standards & policy
Establish competencies within teams
Teams self-organize armed with most current understanding
Automate repetitive processes

No PM, BA, QA
Origin
Scrum does not specify PM, BA, QA
Agile started with small teams where a Product Owner embodied these functions
Agile Approach
These competencies still exist either on the team or coordinated by the Product Owner
Larger org’s require a PO team
DEV
Product Owner Team
PM
Development Team
QA
DBA
BA
PO
UI

conclusion

How do you know you’re Agile?
The question is not are you Agile
Where are you on the Agile scale?
Balance predictive and Agile methods where appropriate to optimize your organizations ability to deliver value

Summary
Agile arose in response to problems with predictive planning
Balance predictive planning and Agile execution to achieve these goals of software delivery
Get working software to market faster
Optimize resources
Improve predictability of delivery
When applied responsibly and purposefully, the appropriate Agile efforts will dramatically improve the ability to deliver software.

QUESTIONS?
Dennis Stevens
President, Synaptus
Enabling the Agile Enterprise
www.synaptus.com
www.dennisstevens.com

Agile foundation and agile myths

by Dennis Stevens on Nov 10, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Agile foundation and agile myths — Presentation Transcript