• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content


Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Agile foundation and agile myths



This presentation addresses the value destroying Predictive approaches that lead to Agile - and then some myths about Agile.

This presentation addresses the value destroying Predictive approaches that lead to Agile - and then some myths about Agile.



Total Views
Views on SlideShare
Embed Views



1 Embed 2

http://www.linkedin.com 2



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • To get to these business benefits, some realities must be acknowledged. At some level in the project these begin to become inaccurate.
  • Manufacturing has different departments Research, Engineering, Planning, ExecutionSoftware engineering includes all disciplines concurrentlyInterestingly, planning takes place before engineering in SD in stark contrast to manufacturing.
  • This is written in response to the prevailing Predictive approach. The focus on process and tools, comprehensive documentation, contract negotiation, and following a plan results in value destroying behavior.
  • Being able to predict how long the project will take is much easier than predicting how long each activity will take.Driving to workHow long does will it take to fix the bugs we haven’t found yet in the code that hasn’t been written yet from the specifications that haven’t been finalized yet.Parkinson’s law, Student Syndrome, Murphy’s LawGains are lost and losses accumulate.
  • Optimizing resource utilization increases WIP and creates delays (leads to rework, re-learning, and quality issues)
  • How long will it take to fix in the bugs you find in the tests you haven’t run on the code you haven’t written to meet the specifications that are still ambiguous? And be precise because you will be held accountable to it.
  • Are an overreaction to challenges presented by predictive approaches. When the predictive approach is removed, it must be replaced with the appropriate enabling Agile approach.
  • Agile principle: responding to change over following a planPlan & prioritize backlog – Means high value, high risk first as shown earlier.Reference agile triangle, work within cost and schedule scope will emerge.
  • Working software over comprehensive documentation
  • Working with PMI Agile CoP Helping to explain the body of experience forBalancing Agile and predictive methods

Agile foundation and agile myths Agile foundation and agile myths Presentation Transcript

  • Agile Foundation, Promises and Myths
    Executive Brief
    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
    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
    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
    Variation from estimates is natural
    Separate estimates from execution. Promote Road Runner behavior.
  • Optimize Resource Utilization
    Predictive Approach
    The highest ROI depends on maximum resource utilization
    Software development is not linear in nature – Optimizing resources doesn’t improve cycle time, it creates WIP and lost knowledge.
    Focus on finishing and flow of work
  • Predictive Approach
    Planning every detail up-front results in stable projects
    You don’t know where you are until you deliver things.
    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
    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.
    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
    Every team, product, and situation is different with different needs and strengths
    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
    Satisfy customer needs
    Improve delivery capability
    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
    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
    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
    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
    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
    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
    Product Owner Team
    Development Team
  • 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
    Satisfy customer needs
    Improve delivery capability
    When applied responsibly and purposefully, the appropriate Agile efforts will dramatically improve the ability to deliver software.
    Dennis Stevens
    President, Synaptus
    Enabling the Agile Enterprise