Agile Program Management Process
4 likes725 views
The WSRI Agile Program Management Process applies agile principles to software development, focusing on delivering defined outcomes through iterative releases and backlogs. It emphasizes the need for regular delivery, team collaboration, and customer involvement while ensuring adherence to project timelines and budgets. This document outlines the processes, roles, and conditions for successfully implementing agile practices in the DARPA context.
Agile Program Management Process
- 1. WSRI Agile Program Management Process Applying Agile principles, prac8ces, and processes to the CODE program. Building the Release Plan for each program event and the deliverables for that review.
- 2. Agile at WSRI • Standard Agile processes focus on soFware development, with emerging requirements in a product development context. • The WSRI domain conducts research trade studies and produces outcomes from Modeling and Simula8ons to determine best solu1on architectures and algorithms for the CODE domain: – Along with a small amount of coding • Our needs are not the same as web site developers for the local pizza shop. 2
- 3. The BAA Says … • DARPA strongly encourages the use of the Agile methodology to expedite soFware development and keep up with this test schedule. • Performers should use best commercial prac8ces for rapid soFware development, such as Agile methodology, and leverage the simula8on environment developed in Phase 1 for frequent and progressive valida8on of the soFware. 3
- 4. Our Glossary 4 DODI 5000.02 Agile WBS – displays and defines the product, or products, to be developed and/or produced. Backlog – a list of deliverables which the team maintains. Deliverable – a tangible outcome delivered to the Government from the program Task – lowest level work ac8vi8es on the program, where budget and resources assigned to produce deliverables. Program Event – An assessment point that occurs at the culmina8on of significant Program Event in the Integrated Master Plan. Release – on CODE: CoDR, SRR, DS-‐Interim, PDR maturity assessments. Rolling Wave (RW)– Conver8ng planning packages into detailed work packages so that near-‐term effort is always detailed. IteraBon – a 1me box in which development of deliverables tasks place Rolling Wave Planning – with current defini8zed RW, planning for upcoming RW’s no further than the planning horizon. IteraBon Planning – the teams plan for work by selec8ng items from the Backlog and commiYng them to an itera8on. Program Event Planning in IMP/IMS Release Planning – planning assignment of deliverables to specific itera8ons and staff.
- 5. Agile Management Process Flow 5 WBS IteraBon 1 IteraBon 2 IteraBon 3 … IteraBon n Close Out § Deliverables § Tasks § Tasks § Deliverables § Deliverables § Deliverables § Tasks § Tasks CA CoDR … PDR WBS basis of deliverables Backlog, per MIL-‐SRTD-‐881C, decomposed into Release Backlog, then into Itera8on Backlog for delivery by Stories and Tasks.
- 6. CODE Program Life Cycle Each Program Event is a Release, with Itera1ons (Sprints) producing deliverables for that Release to increase maturity of outcomes 6 Release 2 Release 1 Release 3 Release 4 Final Capabili8es
- 7. Agile Program Rhythm 7 Completed Deliverable Requirement, Develop, Deliver Requirement, Develop, Deliver Requirement, Develop, Deliver Requirement, Develop, Deliver Completed Deliverable Completed Deliverable Completed Deliverable Increasing Maturity Program Maturity Assessment Event Program Maturity Assessment Event Program Maturity Assessment Event Program Maturity Assessment Event IteraBon Management Increasing Maturity Increasing Maturity Increasing Maturity § WBS defines deliverables in the Backlog. § Allocate Backlog items to Releases and start Release Management Release Management Itera8on Management Release Itera8on
- 8. Performance Assessment On a Weekly Basis 8 Deliverable Task Task Task Task Planned 240 Hrs % Complete 100% 100% 0% 0% Remaining 80 Hours Actual 200 Hrs DelTek GCS Week 1 Week 2 Week 3 Week 4 20 Day Itera8on Every Thursday Status § Physical Percent Complete § Hours remaining to 100%
- 9. Agile for WSRI and the CODE Program • Enable program planning and controls with agile process to support emerging paths of research within the Statement of Work for the program. • Maintain the integrity of the cost and schedule baseline for a DARPA procurement contract. • Assure delivery of winning solu8ons on-‐8me and on budget. 9
- 10. Agile Principles for WSRI • Individuals and interac/ons over processes and tools. – Teams of individuals will perform work in the SOW for each deliverable. – This work will be assessed at each itera8on, release, and Program Event • Working so6ware over comprehensive documenta/on. – Since documents are the product of the effort, both soFware and documenta8on will be needed • Customer collabora/on over contract nego/a/on. – The rela8onship with the customer is done through TIMs as defined in the SOW • Responding to change over following a plan. – Incremental development of the OS, DS, and Open Architecture deliverables WSRI adap1on of the Four Agile Manifesto Statements 10
- 11. HANDS ON EXAMPLE Let’s puts some Hands On for the 1st Release and the 3 Itera8ons of the 1st release. Define the Deliverables for CoDR from the WBS Define the contents of the Itera8ons Breakdown the Tasks inside the Deliverables Es8mate to hours of work for the Tasks 11
- 12. Release Planning • For 1st Release, using the WBS – Define what Deliverables are assigned to the Release from the WBS – The defini8on of Done for each Deliverable is stated in the SOW • For example CoDR has an agenda to review the work to date – Determine the Resources needed for each Deliverable from the Resource Pool 12
- 13. Itera8on Planning • For the Itera/ons in the 1st Release, using the WBS – Assign Deliverables to each Itera/on – Determine staff needed for each Deliverable – Determine the Tasks performed to produce the Deliverable – Es8mate the hours to produce the Deliverable within that Itera/on for each Task 13
- 14. Weekly Planning • Every Thursday status the work progress to date – What is the Physical Percent Complete for each Task – 0% or 100% – Capture actual costs from Time Sheets completed daily, from GCS – Report the es8mated Remaining Work for each Task • Program Controls will produce an analysis 14
- 15. NOW FOR HANDS ON 15
- 16. WBS Items Are the Backlog of all Planned Work 16 Deliverable 1 Deliverable 2 Deliverable 3 Deliverable 4 Deliverable 5 IteraBon 1 Backlog Items From WBS
- 17. Tasks Items Developed from each Deliverable for the WBS 17 Task 1 Task 2 Task 3 Task 4 Task 5 Deliverable 1 Delivery Manager
- 18. CONDITIONS FOR SUCCESS WITH AGILE PROCESSES Research shows there are several condi8ons for success in deploying Agile on DOD (DARPA) programs. We’ll need to assure these condi8ons are in place for CODE.
- 19. Agile Success Factors 19 Success Factor Evidence Success Factor Being Applied Delivery Strategy § Regular delivery business rhythm § Plan the delivery of important capabili8es first Agile techniques § Well defined standards of produc8on Team Capability § Competence and exper8se § Managers knowledgeable of agile § Adap8ve management style Project Management § Agile requirements analysis and project management § Process tracking § Face-‐to-‐face communica8on § Regular working schedule Team Environment § Coloca8on of team members § Coherent, self-‐organized teams § Small teams working on weekly cycle of deliverables § No mul8ple independent teams, close coordina8on of work Customer Involvement § Good customer rela8onships § Progress visible to customer on fine grained boundaries
- 20. Defining What Done Looks Like in an Agile Process • Done for Itera8on is different than Done for the Release • Acceptance criteria for the itera1on defined in the itera8on planning session – Agreed to by the team – Defined in the WBS Dic8onary from the SOW • Acceptance criteria for the release defined in the release planning session – Agreed to by the team – Defined in the SOW for each Program Event • Itera8on retrospec8ve assesses progress to plan – Debt is accumulated when planned work is not completed as planned. 20
- 21. Condi8ons for Success • Program Lifecycle • Team Environment • End User Access • Training And Coaching • Oversight • Incen8ves • Team Composi8on 21
- 22. Program Lifecycle • The Agile mindset starts early in the program lifecycle • Determining how to meet program milestones is the first step: – OS CoDR – Release 1 (3 Mo) – DS SRR/CoDR – Release 2 (6 Mo) – DS-‐Interim – Release 3 (9 Mo) – DS PDR – Release 4 (14 Mo) • Create expecta8ons and criteria to reflect the level and type of documenta8on acceptable at these milestones – Tradi8onal levels of documenta8on are not produced by Agile – CODE defines contents 22
- 23. Team Environment • Self organiza8on is an Agile paradigm • Centralized func8ons s8ll needed – Systems engineering – Configura8on control – Integra8on and Test – Interface management • These centralized func8ons are consider constraints in the DOD Agile paradigm – Boundaries for defining limits on choice and interac8ons – These are system boundaries that define edges of the agile teams. 23
- 24. End User Access • End use access is pragma8c in many DOD environments. • Single voice of the user is needed – Recurring TIMs and monthly mee8ng can provide this voice • DOD acquisi8on community is usually a proxy for the customer – This is not likely the case for CODE – But rapid and recurring feedback on deliverables is needed to stay agile in absence of specific requirements management 24
- 25. Training and Coaching • Subtle8es and nuances will cause confusion and divert energy from the agile process • A training Program Management Office delivers agile training and coaching • Ini8al and ongoing training is a cri8cal success factor 25
- 26. Oversight • Agile has less defined over sight func8ons • Management is a team func8ons rather than an overseer • Day to day func8ons need to be defined in a business rhythm for all team members • Process documenta8on is minimal on agile teams and replaced with – Big Visible Charts – showing process flows on weekly, monthly, and quarterly boundaries – Guidance Cards – to remember the words – Check lists – for each status process 26
- 27. Incen8ves • Early delivery of useful material is a primary incen8ve in the Agile paradigm • In the end, the deliverables must provide compliant content, but focusing on cost and schedule is secondary to value produced 27
- 28. Team Composi8on • And Agile advocate is the anchor for success • While end-‐user representa8ves are not likely for CODE, a proxy for those will be needed • Keeping the team together long enough to achieve high performance is needed – Mul8-‐tasking needs to be minimized – Key technical leads under a collec8ve organiza8on 28
- 29. EFFECTIVE PRACTICES OF AGILE Effec8ve Agile prac8ces are nearly iden8cal to effec8ve engineering and tradi8onal project management prac8ces. The only difference is in the business rhythm cycles. Short, compact, completely formed outcomes produced on a regular basis.
- 30. Effec8ve Prac8ces of Agile • Planning • Organiza8onal Commitment • Prepara8on • Execu8on • Evalua8on 30
- 31. Planning • Think agile, not just follow agile prac8ces • Allow gradual migra8on to agile • Observe and communicate with other program members • Follow organiza8on change discipline • Be prepared for difficul8es • Start with Agile guidance and an Agile adop8on strategy 31
- 32. Organiza8onal Commitment • Ensure all components involved in Agile projects are commimed to the organiza8on’s Agile approach. • Iden8fy an Agile champion within senior management. • Ensure all teams include coaches or staff with Agile experience. • Empower small, cross-‐func8onal teams. 32
- 33. Prepara8on • Train en8re organiza8on in Agile approach and mindset, and train Agile prac88oners in Agile methods. • Ensure subject mamer experts and business team members have required knowledge. • Enhance migra8on to Agile concepts using Agile terms and examples. • Create physical environment conducive to collabora8on. • Iden8fy measurable outcomes, not outputs, of what you want to achieve using Agile. • Ensure that the defini8on of how a story will be determined to be done is comprehensive and objec8ve. 33
- 34. Execu8on • Use same dura8on for each itera8on. • Capture itera8on defects in a backlog tool. • Test compliance with planned maturity of deliverables early and oFen throughout the life cycle. 34
- 35. Evalua8on • Obtain stakeholder / customer feedback frequently and closely monitor correc8ve ac8ons. • Con8nuously improve Agile adop8on at both the project level and organiza8on level. • Iden8fy and address impediments at the organiza8on and project levels. • Gain trust by demonstra8ng value at the end of each itera8on. • Track progress using tools and metrics. • Track progress daily and visibly. 35
- 36. Agile Management Process Flow 36 WBS IteraBon 1 IteraBon 2 IteraBon 3 … IteraBon n Close Out § 208hrs / Itera8on § 12 Deliverables / Itera8on § Deliverables § Deliverables § Deliverables § Tasks § Tasks CA CoDR … PDR WBS basis of deliverables Backlog, per MIL-‐SRTD-‐881C, decomposed into Release Backlog, then into Itera8on Backlog for delivery by Stories and Tasks. § Resources ~ 25 engineers, with 100 hours / month capacity for work § ~31,000 hours budget over 18 months at 1,700 hours / year absorp8on § 2,500 hours capacity per itera8on (20 work days)
- 37. Rules of Engagement • Planning takes place on Itera8on and Release boundaries – No work crosses a 20 work day increment – No work crosses a 90 calendar day assessment of progress to plan • Status progress to plan done every Thursday – DCAA daily 8me sheet – Physical percent complete of tasks in Deliverable 37
- 38. Rules of Engagement (Concluded) • All work to produce a deliverable is measured as 0% / 100% complete • This means the planning of that work has to follow the 0/100 rules 38
- 39. 7 STEPS TO OUR RESOURCE LOADED BASELINE The key to success for CODE and beyond is Tools Follow Process We’ll develop the process than adapt the tools to fit that process. As a start the processes shown here are the top-‐level framework for conduc8ng the programma8c ac8vi8es of the program. 39
- 40. Steps to Loading the Baseline Into the Program Management Tools 1. Establish Releases 2. Establish Itera8ons within each release 3. Establish Stories from the WBS and allocate them to each release 4. Assign resources to each Story 5. Es8mate work effort – in hours – to each story 6. Assess if capacity for work ≥ demand for work 7. Repeat Steps 4, 5, and 6 un8l demand equals capacity 40
- 41. Establish Releases • The current release plan is – CoDR – DS-‐SRR/CoDR – DS-‐Interim DR – DS-‐PDR – Phase 1 Final Report • Each release will have itera8ons to produce the outcomes of those “Events” 41 Releases are “mini-‐projects” and treated as “deliverables” of fully formed outcomes
- 42. Establish Itera8ons Inside Releases • Itera8ons are planned for 20 work days each and fit inside the Release Cycle – CoDR = 3 Itera8ons – DS-‐SRR/CoDR = 3 itera8ons – DS-‐Interim DR = 3 Itera8ons – DS-‐PDR = 3 Itera8ons 42 Daily standups confirm not only work for the day, week, and Itera1on, but impediments to progress that must be removed “today”
- 43. Establish Stories Inside Itera8ons • Stories deliver terminal node WBS elements • Walking the WBS, the program team layouts out the Stories against the WBS elements • Each story – Produces a single outcome of a WBS element – Takes up to 20 working days to complete – Is 100% complete, no revisi8ng the Story 43 Requirements Churn is just as much a problem in Agile as it is in Tradi1onal projects
- 44. Assign Resources to Stories • With Stories laid into Itera8on assign staff to perform the work – Named resources assigned to each story – Can have mul8ple staff assigned to a Story for its comple8on • Assure staff availability in the resource calendar – Commitment to perform is a Cri8cal Success Factor 44 Resource commitments for the period-‐of-‐ performance assure sustainable “throughput”
- 45. Es8mate Work Effort for Those Resources • Use proposal BOE’s as a start of effort es8ma8on • Revisit those to confirm understanding, es8mates, and outcomes • Load the work effort es8mates into the project management tool 45 All es1mates need to be adjusted for naturally occurring variance and event-‐based risk
- 46. Assess Capacity for Work Against Demand for Work • Compare demand for work against capacity for work • Assure sufficient capacity for the demand before proceeding • If demand higher than capacity, re-‐plan work to level demand • The Grooming of the Backlog is cri8cal to controlling the progress to plan 46 Closed loop control of demand versus capacity has a weekly sampling interval
- 47. BACKUP 47
- 48. Vocabulary Work Breakdown Structure • MIL-‐STD-‐881-‐C tells us … – All por8ons of the program are covered. – This all-‐in requirement assures all deliverables are iden8fied in the WBS. – The WBS facilitates collabora8on between the team members by tying performance, cost, schedule, and risk informa8on. – The WBS facilitates the required technical rigor and integrated test and evalua8on throughout the acquisi8on process. – The WBS is the first loca8on to define the risks to achieving the above items in this list 48
- 49. Vocabulary (Con8nued) Deliverables • Agile focuses on outcomes rather than ac8vi8es • Our outcomes are listed in the BAA (and SOW from the contract) – Trade studies – Open Architecture – Transi8on Plan – MOP defini8ons – Various reports • The agile planning process, won’t detail how to produce these, just that they are produced. • The agile planning process is not a schedule 49
- 50. Vocabulary (Con8nued) Release Planning • Release planning is not scheduling • The backlog of Deliverables from the WBS are assigned to Itera8ons within a Release • The Team … – Comprehends the work of the Release – Shares the understanding of what it takes to produce the release – Agrees on the ac8ons needed to formalize the plan – Baselines this confidence with all the stakeholders – Results in collec8ve ownership of the plan, any need to replanning, and communica8on within the team 50