Agile Resourcing
2 likes2,312 views
Resource Planning is one of the biggest headaches for medium to large organizations. Creating a detailed resource plan that is meaningful is very difficult, and keeping it up to date is almost impossible. Plans that look good are often an attractive fiction, full of unrealistic assumptions, over-allocations, and the spreading of too-few people in too many ways. Agile Resource Planning provides a very different approach to the classic model. It produces realistic plans that are simple to maintain, and effective for planning work over time. In this webinar, Dr. Kevin Thompson will present new concepts in Agile Resource Planning, which provide a practical and easy-to-use approach to Resource Planning that can be used for Agile and classic environments.
Ad
More Related Content
What's hot (20)
Viewers also liked (14)
Ad
Similar to Agile Resourcing (20)
Ad
More from Cprime (20)
Recently uploaded (20)
![Pixologic ZBrush Crack Plus Activation Key [Latest 2025] New Version](https://cdn.slidesharecdn.com/ss_thumbnails/fashionevolution2-250322112409-f76abaa7-250428124909-b51264ff-250504160528-fc2bb1c5-thumbnail.jpg?width=560&fit=bounds)
Agile Resourcing
- 1. PEOPLE | PROCESSES | TECHNOLOGY
- 2. 2www.cprime.com Resource Planning and Management in an Agile World Kevin Thompson, Ph.D., PMP, ACP, CSP
- 3. 3www.cprime.com Presenter Kevin Thompson, Ph.D. Agile Practice Lead Trains, coaches teams and companies in Agile development Education and certifications Certified Scrum Master and Scrum Professional PMI Project Management Professional PMI Agile Certified Practitioner Scaled Agile Framework Program Consultant Certified Yellow Belt Collaboration Architect Doctorate in Physics, Princeton University
- 4. 4www.cprime.com What is “Resourcing?” • Resourcing: Allocation of people to work on projects or products over time • Resourcing is tightly linked to the scheduling of work • Resourcing and Scheduling decisions must be made concurrently
- 5. 5www.cprime.com From Scope to Schedule Goal: Given a desired sequence of Business Initiatives to be implemented, create a plan for work over next 6—12 months. Address • Duration of Initiatives • Availability of Resources • Schedule of Initiative work Techniques 1. Classic: Allocate resources to projects 2. Agile: Allocate scope to Teams Both approaches require decomposition of Initiative scope into smaller pieces
- 6. 6www.cprime.com Scope Decomposition Classic Decompose scope into a Work Breakdown Structure of interior nodes and Work Packages (leaf nodes) Agile Decompose scope into a tree of Epics (Interior nodes) and Stories (Leaf nodes) Stories are small enough so that one Agile Team can implement and test one in a few days Epic Child Epic Story 2 Story 3 Story 1
- 7. 7www.cprime.com Classic Resource Planning and SchedulingProject Managers knows scope of project Project Manager gets estimates of effort per person or skill set 1300 hours of any DBA for database development 1700 hours of Graham, our Tech Lead 1100 hours of a Business Analyst … Program Manager creates draft schedules for a set of projects, with candidate resource allocations Program Manager conducts “What If” analysis to develop practical schedule Following slides illustrate the usual approach, using the Innotas Project Portfolio Management product Microsoft Project, others, work in a similar fashion
- 8. 8www.cprime.com Proposed Resource Allocation Allocate time (hours) or head-count (fraction of person) to the project This and related screens from Innotas
- 9. 9www.cprime.com Develop Schedule The first attempt typically over-allocates people
- 10. 10www.cprime.com Modify Plan to Produce a Workable ScheduleRevise start dates, allocations to this and other projects to correct over- allocations of people
- 11. 11www.cprime.com Iterate to a Solution Goal is to get an implementable schedule of Projects Resource usage is in bounds Organizational needs are met Continue revising… Start dates of projects Resources allocated to various projects Which projects to attempt, defer, or terminate … until schedule is achievable
- 12. 12www.cprime.com Issues, Challenges with Classic Resource Planning Fine granularity (to person level) makes everything hard Initial plan for each project is time-consuming Plan for set of projects is more time-consuming What-if scenario planning across projects is extremely time- consuming, can lead to endless tweaking May need resources already allocated to other projects Negotiating trade-offs is time-consuming Negotiation may not be successful (for your project!) Not always clear who can make the call about resource allocation Sharing a person across multiple projects is problematic Simple availability numbers are misleading Context-switching is demoralizing and reduces effectiveness If Bob can spend 80 hours working this month, spreading him across four projects does not mean each gets 20 useful hours from Bob
- 13. 13www.cprime.com Basic Problem: Too Much Detail! The more things you try to manage concurrently, the more problems you have. So avoid excessive detail! • Managers know it’s best to have no more than five direct reports • Napoleon said, “No man can command more than five distinct bodies in the same theater of war.” Solution: Allocate scope to a small number of Teams, not to a large number of individuals.
- 14. 14www.cprime.com Understanding Teams Classic Project Management speaks of a “Project Team” Project Team is the set of people who execute a project Teams are formed for Project / Initiative, disbanded on completion Team membership grows, changes, dwindles over time Time variation of membership complicates estimates, measures of productivity per unit of time Agile Project Management speaks of “Teams” A specific set of up to nine people who produce tested and working deliverables in a specific domain Teams are persistent, with slowly-evolving membership Teams outlast Projects / Initiatives Work of specific Project / Initiative is divided across a set of Teams Stable membership simplifies estimates, measures of productivity Much easier to plan for 12 Teams than 100 individuals!
- 15. 15www.cprime.com Agile Resource Planning Agile Resource Planning is based on Teams, not individuals Teams make for a smaller number of bigger “resources” Teams are less specialized than individuals Each Team has a stable domain (focus) Each Team produces deliverables in its domain that are used by others (external or internal customers, including other Teams) Problem of splitting resources across projects (mostly) goes away There are no projects, only Initiatives A Team doesn’t care which Initiative is generating work, only that the work be in its domain Agile Resource Planning is about allocating work to Teams
- 16. 16www.cprime.com Initiative Decomposition A Technical Planning Team decomposes Initiatives into high-level Epics Initiatives are not decomposed to the Story level Agent V2 Upgrade V2 Implementation Device 1 Integration Device 2-31 Integration Administration console revision Monitor console revision Device 1 support Device 2-31 support Hardware Abstraction Layer base HAL: Chip-set 1 HAL: Chip-set 2 HAL: Chip-set 3 Communication Interface Console Team Agent Team Device Team
- 17. 17www.cprime.com Initiative Estimation Technical Planning Team estimates effort in standard units (Person-Days, Story Points, etc.) Epic Device Team Agent Team Console Team Agent v2 implementation 270 Integration of Agent with Device 1 13.5 Integration of Agent with Devices 2-31 279 Revision of Administration console 120 Revision of Monitor console 120 Support for Device 1 6 Support for Devices 2-31 124 Base Hardware Abstraction Layer (HAL) capability 90 HAL for chip-set 1 30 HAL for chip-set 2 30 HAL for chip-set 3 30 Interface for Agent communication 60 Total Effort 240 562.5 370
- 18. 18www.cprime.com Mapping of Effort to Duration Initiatives first have effort estimates, but… We need durations to make scheduling decisions Duration is driven by Effort of Initiative “Velocity” (rate) at which a Team can accomplish work Person-Days per month, Story Points per Sprint, etc. Duration is (roughly) Effort divided by Velocity Duration is highly uncertain Useful for planning, but not reliable Expect factor-of-four errors routinely Effort and Velocity are both uncertain Duration (the ratio) is even more uncertain
- 19. 19www.cprime.com What is Velocity, and Why do we Use it? Velocity = Amount of work a Team can do in a standard unit of time Velocity is often estimated for intervals of different size In Scrum Smallest unit is a Sprint or Iteration (2—4 weeks) Larger unit is a Release (set of Sprints to produce new product) In Kanban No standard unit. Can choose week, month, etc. Throughput (completed items / day) often used instead of Velocity In classic Project Management Term “Velocity” not generally used Concept of rate of work still relevant Concept of Velocity greatly simplifies estimates of Duration Much simpler than classic Project Management techniques that rely on detailed planning
- 20. 20www.cprime.com Duration for the Agent- Upgrade Initiative Program Manager supplies average Sprint-Velocity information for all Teams, then forecasts duration of their work on Initiative Example: Teams work in two-week Sprints Each Team has a known Velocity for an average Sprint Duration (i.e., # Sprints) = Effort / Velocity Agent V2 Upgrade Device Team Agent Team Console Team Total effort per Team 240 562.5 370 Team Velocity (Person-Days per two- week Sprint) 30 45 40 Number of Sprints required 8 12.5 9.25
- 21. 21www.cprime.com Scheduling Work for Initiatives We have several Initiatives to plan Each requires work from the same set of Teams We need to lay out a schedule that is achievable for all of the Initiatives Schedule development is iterative, as we revise draft plans to produce an achievable schedule Initiative Duration (Sprints) Device Team Agent Team Console Team Agent v2 Upgrade (AU) 8 12.5 9.25 Support for Gelco Cardiac Monitors (GC) 0 5 5 Support for Belden Cardiac Monitors (BC) 0 3 3 Vascubot Controller (VC) 9 0 0
- 22. 22www.cprime.com First Attempt to Schedule Initiatives AU 8 VC 9 AU 12.5 AU 9.25 GC 5BC 3 This appears to get the Agent Upgrade done first. However, the Agent Team needs the Device Team to finish the device interface, and so cannot start in parallel with the Device work. Agent Console Device GC 5BC 3 Each bar is labeled with Initiative initials and duration The patterns of the bars correspond to different Initiatives
- 23. 23www.cprime.com Second Attempt to Schedule Initiatives AU 8 VC 9 AU 12.5 AU 9.25GC 5 BC 3 Moving the start of the Agent-upgrade work out gives the Device Team enough time to establish interface standards and stubs so that the Agent Team can work productively. The Belden and Gelco Cardiac-Monitor support work can be done in parallel between the Agent and Console Teams, because the interface is well understood. However, the Console Team cannot start work on the Agent upgrade until after the Agent Team has developed some interface standards, which means that this schedule will not work for the Console Team. Agent Console Device GC 5 BC 3
- 24. 24www.cprime.com Third Attempt to Schedule Initiatives AU 8 VC 9 AU 12.5 AU 9.25GC 5 BC 3 Moving the start of the Console Team's Agent-upgrade work out gives the Agent Team enough time to lay the groundwork required by the Console Team. This plan should work. Agent Console Device GC 5 BC 3
- 25. 25www.cprime.com Conclusions An Agile approach to resourcing, based on allocating work to stable Teams, is much easier than classic individual-oriented resourcing • Effort of resourcing and scheduling is smaller • Properly-formed Teams do load-balancing and fine-grained work allocation internally • Stability and autonomy of Teams improves productivity and morale • Changes in direction, priorities are easier to manage