A Systems Engineering Perspective John M Allen 1 Presentation Overview What is Agile Agile Methods Systems Engineering and Agile Why is Agile in a DoD Project a challenge The Earned Value Management EVM challenge ID: 639701
Download Presentation The PPT/PDF document "Using Agile Methods in a DoD Environment" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Using Agile Methods in a DoD Environment
A Systems Engineering PerspectiveJohn M. Allen
1Slide2
Presentation Overview
What is Agile?Agile Methods
Systems Engineering and Agile
Why is Agile in a DoD Project a challenge?
The Earned Value Management (EVM) challengeAgile in PracticeThe future of AgileQuestions and Comments
2Slide3
What is Agile?
Methods and PracticesShort phases of work
Iterative or incremental development
Self-organizing teams
Regular evaluation of progressDeliberate planningAdaptation to changeTransparencyCommunication
3Slide4
Waterfall, Agile, and the DoD
Waterfall model to software development Codified in 1985 in DOD-STD-2167.Contractor shall implement the following six phases:
Preliminary Design
Detailed Design
CodingUnit TestingIntegrationTesting4Slide5
Agile Roots
Waterfall formalized in “Managing the Development of Large Software Systems” by Dr. Winston W. Royce in 1970
Dr. Royce saw the waterfall method as
a
“risky development process”.Dr. Royce suggested iterating the software development process.
Waterfall Method
Iterative Method
5Slide6
Agile Roots
Many Agile methods evolved from manufacturing and Lean initiatives
Toyota Production System (Precursor to Lean Manufacturing, socio-technical system)
Lean (eliminate waste)
Six Sigma (Define/Measure/Analyze/Improve/Control)
Poka-yoke (mistake proofing)
Agile was popularized by XP and Scrum for software development
Agile is a collection of methods and practices
6Slide7
Manifesto for Agile Software Development
Kent Beck
Mike
Beedle
Arie van BennekumAlistair CockburnWard CunninghamMartin FowlerJames GrenningJim Highsmith
Andrew HuntRon JeffriesJon KernBrian
Marick
Robert C. Martin
Steve Mellor
Ken
Schwaber
Jeff Sutherland
Dave Thomas
7
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 processes 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.
Published at agilemanifesto.org
© 2001, the above
authors
this
declaration may be freely copied in any form,
but
only in its entirety through this notice. Slide8
Agile Methods
ScrumBacklog based with time boxed development periods
Kanban
Lean technique uses pull based scheduling
DSDM (Dynamic Systems Development Method)Released in 1994 to support rapid application development (RAD)Fixes cost, quality, & time uses MoSCoWMust have, Should have, Could have, Would like
XP – Extreme programming29 rules. Pair programing, code test first, frequent small releases.
Takes best practices to an “extreme level”
Feature driven
development
Customer oriented feature development (lightweight agile)
Mix-and-match
Scrumban
,
Scrum+XP
,
8Slide9
Agile Methods – Common Features
Iterative DevelopmentCustomer Focused
Communication
Transparency
Adapt to ChangeImprove Efficiency9
Notice that common features are not specific to software onlySlide10
Scaling Agile
Frameworks to scale AgileSaFE – Scaled Agile Framework – Enterprise
Designed by Scaled Agile, Inc. in Boulder, CO
Aimed at Large enterprises (greater than 1000)
Scrum of Scrums – Programs/Multiple ProjectsMultiple Scrums that are embedded in an overall ScrumWorks well within Program Management Organization (PMO)Can be used on larger/complex programs with multiple projectsKanban scales well
10Slide11
Agile and Systems Engineering
“The value proposition of an agile SE process is risk management, appropriate when development speed and customer satisfaction are likely to be affected by requirements understandings that evolve during system development
”
–
INCOSE Systems Engineering Handbook, Fourth EditionSection 9.9 of the INCOSE Systems Engineering Handbook, Fourth Edition is titled “Agile Systems Engineering”Discusses Agile SE, Metric, and Architectural FrameworksItemizes agile architectural design principlesNAVAIR SETR Process Handbook, Version 1.0, Section 4 – Emerging ProcessesSection 4.2 – “Agile”
Section 4.3 – “Incremental Software Development”Section 4.4 – Model-Centric Systems Engineering (MCSE)
11Slide12
Agile Supports Systems Engineering Activities
Interface Development
Incremental requirements development - subsystem-at-a-time
Spiral development supports incremental integration and interface evolution
Progress tracking and risk predictionUse burndown and planning metrics as leading indicators for schedule and performance riskHelps team focus on the goal, not the pastConstantly evaluate interfaces and requirements applicability
Enable value-based engineering decisionsDoes this requirement still make sense?
Will the latest baseline still support mission objectives?
Has the mission changed?
Has technology changes?
12Slide13
Agile and DoD Acquisition
Most proposals are Firm Fixed Price (FFP)Contractor must estimate cost of entire scope
Contract modifications required for deviations
Scope/baseline deviations are difficult
Cost contracts are more difficult to obtainProposals are difficult to evaluate Cost Plus contracts are seen as riskyBurden of formal Earned Value Management SystemsNeed for up front pricing to plan budget
Government budgeting and procurement cycles require known costsHard to budget in advance for unknown cost and/or scope
Hard to evaluate multiple proposals
Hybrid FFP and Agile approach is needed
13Slide14
The EVM Dragon
What is Earned Value Management (EVM)?Methodology that combines scope, schedule, and resource measurements to assess project performance and progress.
Represents progress and value in terms of money expended/remaining
Strongly based on prediction of cost and schedule
EVM is required on cost or incentive contracts$20M - $50M: Must meet ANSI/EIA-748 (EVMS). No formal validation required.$50M or greater: Must meet ANSI/EIA-748 and be formally validated by DCMA.Issues with EVMTends to fail if cost or schedule cannot be predicted with high confidence
Multiple rebaselining
is often required to increase confidence but typically perceived as “bad”
14Slide15
EVM and Agile
“Agile and EVM are complementary when properly implemented together, and help enable a robust overall management process. In order to be effective, Agile must be evaluated for its applicability on a program-specific basis and tailored to best align with programmatic and contractual requirements
.” -
Agile and Earned Value Management: A Program Manager’s Desk Guide, John S. McGregor, Deputy Director, Earned Value Management Performance Assessments and Root Cause Analyses (OUSD AT&L) 03 March
2016Align the WBS to a feature oriented structure. Capability driven instead of structural:15Slide16
EVM and Agile
Planning and SchedulingDecompose work scope: Theme->Feature->Epic->Story
Time-phase work: Release roadmaps and backlog management
Underpin the IMS: Agile management and ERP/MRP tools to feed the IMS
Use rolling wave planning: Document the planning window in the EVM system descriptionEstablish a Freeze period: Baseline the IMS/plan at regular intervals prior to commencing work16Slide17
EVM and Agile
Measuring progressTie progress to scope completion: Completion tied to releasable feature, not execution interval.
Claim performance/value: Define “done” as all-or-nothing.
Dollarize agile effort: Decide at what point a dollar amount is attached to metrics/work.
Forecasting and Estimates at Complete (EAC): Agile focuses on Estimate to Complete (ETC). Use this to build a more accurate EAC as progress is made.17Slide18
EVM and Agile
Baseline MaintenanceMaintaining the backlog: Keep the customer actively involved in backlog management.
To maintain EVM System Compliance:
Use standard terminology and metrics. Define your process and metrics in the EVMS, and IPMR deliverables.
Use Agile metrics to derive and support EVM metrics. Agile metrics cannot supplant EVM metrics.Agile execution should underpin the level at which EVM is reported. Support of EVM metrics should be traceable to Agile metrics. 18Slide19
Agile in Practice
Challenge: Overcoming bias based on lack of Agile education and industry abuse
“Agile is just a way for contractors to milk the Government for money, descope as they go, and avoid up-front analysis.”
“Agile is just a way to avoid planning.”
“How can we manage a project without a baseline?”Suggestions: Educate stakeholders and customers. Establish a metrics and reporting approach up-front.Perform system analysis to identify subsystems and capabilities early
Allocate capabilities to system configuration itemsEstablish a system architecture and progressively increase detail as the design emerges
19Slide20
Agile in Practice
Challenge: The team will not embrace Agile methods.
The
discipline of SCRUM is not embraced by the
teamThe team fails to self-organizeIndividuals use Agile as an excuse to avoid documentationSuggestions: Educate the team prior to implementing Agile and seek inputUse a strong coach/mentor to implement Agile - not a managerEliminate the bad-apple from the team
Realize Agile is not for everyone and some individuals will not be able contribute effectively
20Slide21
Agile in Practice
Challenge: “Agile is not working…” / “Where is the whole schedule?” / “When will you be done?”
Management or customer is not willing to wait for a couple of iterations to see success
Suggestions
: Stand firm and defend your teamUse metrics to show progress or blockersEducate the requestorMetrics take time to establish themselvesThe team always overcommits on the first 2 or 3 iterations
Ensure metric collection is at an acceptable rateCommunicate barriers/blockers with suggested resolutions
21Slide22
Agile in Practice
Challenge: Overzealous process tailoring followed by failure
“We don’t need all those steps, we’ll tailor the process before we start”
Followed by “This {insert process here} doesn’t work!”
Suggestions: Unless the entire team is an expert in the process and has executed it successfully as a team – don’t tailor immediatelyFollow the chosen approach as prescribedAllow the team to organically tailor over timeRemember Tuckman’s stages of group development
Forming, Storming, Norming, PerformingProvide the team mentoring and leadership early and often
Allow success to occur – don’t micromanage the team
22Slide23
Agile in Practice – Individual Agile
Maintain an individual backlog of tasks
Use the backlog in discussions with supervisor/manager/teammates
Keep personal metrics
Record actual time to complete the taskPlan individual tasksWhat external support is needed?Risks and blockers to escalate to management/team?Communicate progress early and oftenFacilitate team member contribution
Educate others on status/progress/issuesOften communication will result in assistance/ideas/support
23Slide24
Agile techniques are gaining ground in project management circles
If you take a step back… most of us already use an iterative approach to everythingIteration, the core tenant of Agile, is present in many areas
Quality Management
Deming – Plan, Do, Check/Study, Act (repeat as necessary)
Military Strategy / combat operationsColonel John Boyd – Observe, orient, Decide, Act (repeat as necessary)Process Improvement (Six Sigma)DMAIC – Define, Measure, Analyze, Improve and Control (repeat as necessary)Cooking…Try the recipe, alter the recipe, cook it again…
Agile will eventually become a standard practice
The Future of Agile
24Slide25
Questions, Comments, Thoughts?
Agile methods are formalized techniques to apply disciplined iterative processes.Quotations from
INCOSE Systems Engineering Handbook, Fourth
Edition:
“Systems engineering is an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near optimal manner, the full range of requirements for the system” quoted from “Essentials of Project and Systems Engineering Management”, Eisner, H. 2008“The SE process has an iterative methodology that supports discovery, learning, and continuous improvement.”“Graphical representations of lifecycle stages tend to be linear, but this hides the true incremental, iterative, and recursive nature of the underlying processes.”25Slide26
References
26Slide27
References
27
Web Links
http
://agilemethodology.org/http://www.agilenutshell.com/http://cs.smu.ca/~porter/csc/465/notes/sdm_xp.html http://www.scrumguides.org/history.htmlhttp://agilemanifesto.orghttp://www.scaledagileframework.com/https://www.scrumalliance.org/community/articles/2007/may/advice-on-conducting-the-scrum-of-scrums-meetinghttps://www.mountaingoatsoftware.com/agile/scrum/teamhttps://en.wikipedia.org/wiki/Scrumbanhttp://www.deloittedigital.com/us/blog/scrumban-a-different-way-to-be-agilehttp://www.acq.osd.mil/evm/faqs.shtmlhttps://acc.dau.mil/CommunityBrowser.aspx?id=488728http://www.acq.osd.mil/evm/resources/AgileFeb2015/LM%20Agile%20EVM%20Lessons%20Learned%20021915.pdf https://en.wikipedia.org/wiki/John_Boyd_%28military_strategist%29Slide28
References
28
Literature
Real-World
Project Management, Richard Perrin, 2008 Wiley & SonsSystems Engineering Handbook: A Guide for System Life Cycle Processes and Activities (Fourth Edition), INCOSE, 2015 WileyA Guide to the Project Management Body of Knowledge (PMBOK® Guide) (Fifth Edition), PMI, 2013 (ANSI/PMI 99-001-2013)Iterative and Incremental Development: A brief history, Craig Larman and Victor R. Basili (2003)
Managing the Development of Large Software Systems, Dr. Winston W. Royce (1970)
NAVAIR
SETR Process
Handbook, Version 1.0,
NAVAIR
Agile and Earned Value Management: A Program Manager’s Desk Guide
, John S. McGregor, Deputy Director, Earned Value Management Performance Assessments and Root Cause Analyses (OUSD AT&L) 03 March
2016