Understanding Agile Project Management
•Download as PPTX, PDF•
5 likes•4,944 views
This is the short form of my Agile PMP talk
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (17)
Similar to Understanding Agile Project Management
Similar to Understanding Agile Project Management (20)
More from Mike Cottmeyer
More from Mike Cottmeyer (20)
Understanding Agile Project Management
- 1. Understanding Agile Project Management Presented by: Mike Cottmeyer
- 2. mike cottmeyerenterprise agile coachmike@cottmeyer.com 1.404.312.1471leadingagile.comfacebook.com/leadingagiletwitter.com/mcottmeyerlinkedin.com/in/cottmeyer
- 3. The essence of ProjectManagement? CostTimeScope
- 4. The essence of ProjectManagement? Risk
- 8. Project (years) Release (months) Release (months) Release (months) I1 I2 I3 I4 I5 I6 I7 I8 I9 Fixed duration No overlap
- 9. Team A Team B Team C Team D Team E Team F Team Size Project Duration
- 10. Feature Epic User Story User Story Feature User Story User Story Feature User Story User Story Feature Epic User Story Feature Epic Feature Epic
- 12. User Story Screen User Story Team User Story Report User Story User Story Database User Story User Story
- 13. User Story Screen User Story Team User Story Report User Story User Story Database User Story User Story
- 14. PMBOK
- 15. Initiate Plan Execute Monitor & Control Close Construction Elab. Inc. Trans. I1-N I0 IH
- 16. PMBOK A
- 17. Time Deliverables not activitiesReduce DependenciesPrioritize don’t sequenceAlways finish on-time
- 18. Cost Cost = team size X duration Invest don’t spend
- 19. Scope Plan scope in rolling waves Make trade-offs Allow room for negotiation Frequent customer interaction
- 20. Risk Business and Technical Risk management built in Continuous visibility
- 21. Quality Quality not an afterthought Test driven development Continuous integration Continuous testing
- 22. Comm. Outside the team… the same Co-location Osmotic communication Information radiators
- 23. Int. Charter or vision is okay Agile PM plan and approach Individual accountability Change control built in
- 24. Proc. Build contracts for change Build relationships on trust Create win-win agreements
- 25. HR Motivated individuals Give them tools Remove impediments Self-organization
- 26. Remember…Agileis a value system
- 27. Empowerment Self-Organization Trust Individuals Accountability
- 28. Team PM PM Team Team Team
- 29. Team PM PM Team Team Team Team APM Team Team Team APM
- 30. Know where you are… know what’s left to go
- 32. mike cottmeyerenterprise agile coachmike@cottmeyer.com 1.404.312.1471leadingagile.comfacebook.com/leadingagiletwitter.com/mcottmeyerlinkedin.com/in/cottmeyer
Editor's Notes
- 1. This talk is called the Agile PMP. Regardless of whether your agile transformation is top down or bottom up, the PMO quite often finds itself on the outside looking in. Project Managers are trying to figure out what the heck is going on, and how to be successful in this new reality. They are trying to figure out how to apply their skills and experiences to help manage these projects that don't seem to have any need for traditional managers.
- 2. Hello everybody, my name is Mike Cottmeyer. I am a agile transformation coach with Pillar Technology. Pillar is a 100 person consultancy based in the mid-west. We are expanding and I am opening an office out of Atlanta, Georgia. My company believes that at the end of the day, culture and structure are going to trump anything you do with people, process, and tools. Transforming businesses around agile principles is what we do.
- 3. One of the things that I've learned over the last 10 years is that project management is project management. It doesn't matter if we call it traditional or agile. At the end of the day, we are primarily trying to deliver stuff within some sort of predetermined or negotiated time, cost, and scope constraint. We figure out the work, we sequence the work, and we manage the work. Project management is about making all that stuff happen.
- 4. The biggest difference between traditional and agile project management are the assumptions that we make about uncertainty. Traditional project managers tend to assume that with more up front planning, that we can get all of the uncertainty out of our projects. The goal is to have a well defined scope and a solid project plan that will help us deliver that scope. Our job is to define the plan… and to manage to the plan.
- 5. Agile project managers don't make the same assumptions about uncertainty. We believe that uncertainty is okay. We believe that there are certain projects where you just don't understand enough about the work early-on to create a credible plan to follow. We believe that there are some problem domains where it's not even desirable to try to figure out everything up front. In those cases we need a credible alternative.
- 6. Agile projects still manage to the triple constraints. But while traditional projects tend to start with scope as their primary constraint and derive time and cost, agile projects tend to focus time and cost first. Rather than figure out what we want in gory detail and then figure out how long it will take and how much it will cost, we determine how much to invest and when we need to deliver and then figure out what we can build.
- 7. Agile projects start with some idea of when they want to get to market and create a series of time-boxes designed to help us measure our progress along the way. You might have a project scope that get's broken down into a series of intermediate releases. Each release might get broken down into a series of sprints or iterations. The idea is that each time-box is fixed and we measure (over time) how much the team can deliver in each one.
- 8. Agile projects also start with some notion of what they want to spend. On software development projects, spend is typically governed by the size of the team. The idea is that agile projects are assigned to teams that stay together for the duration of the project. The team establishes a delivery cadence and gets used to working with each other. Over time the spend is roughly equal to the team size x duration.
- 9. Now the trick becomes how to vary scope while still giving the business some idea of what they can expect up front. The idea is that we start with the breadth of scope, both from a requirements perspective, and from a technical perspective. Usually, in a relatively short period of time, we can get an idea of what the project is and what it is not. Pretty early, without a ton of up front planning, we can begin to constrain project outcomes.
- 10. It's this idea of convergence this is the key concept. It's not that with agile we can somehow magically just start writing software, with no planning, and get acceptable project outcomes. We go through a process of planning at higher levels of abstraction, and then as we build the emerging product, and we reduce risk, and we learn about what we are building... we make tradeoffs that lead us toward the best possible business outcomes.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 12. Our goal is to recognize, that on projects where we have a tremendous amount of uncertainty... we don't want to create plans that don't reflect our current understanding of reality. We don't want to assume the process overhead of change management, when change is going to be the norm. Agile gives us a way to manage our projects, in the face of uncertainty, while aggressively working to reduce risk and uncertainty.
- 13. Now that I've hopefully that the fundamentals of agility are not totally antithetical to our basic understanding of project management. What's up with all this PMP stuff... are you telling me that the PMBOK is consistent with agile project management? Well... yes and no? I would challenge you to find a PMI knowledge area or a PM process that you wouldn't do in some form on an agile project. Often it is a matter of how we look at things.
- 14. Even agile projects have to be initiated, planned, executed, monitored and controlled, and closed down. No where does it say we can only do these processes once. Every agile project out there deals with time, cost, scope, risk, quality, communication, human resources, procurement, and integration. The problem is that we often think about these things as an SDLC, the PMBOK is an adaptable project management framework.
- 15. I'm not saying that everything in the PMBOK applies on every single agile project. The PMBOK itself says that it is a set of processes that apply on most projects most of the time. What agile requires us to do is think differently. It requires us to be different as leaders. It requires us to view our role on the project differently. It is less about us and more about how we can enable and empower our teams members to be more effective.
- •Define deliverables not activities •Strive to reduce dependencies between deliverables•Prioritize don’t sequence. Work from the top of the list.•Estimate based on relative size•Releases and iterations always end on time.
- •Scope is defined at progressive levels of detail. •Plan scope, deal with project realities, and make tradeoffs.•Allow room for scope negotiation when planning project scope•Collaboration and frequent interaction
- •Communication planning can be thought of in the traditional sense when looking outside the project team •Collocation•Information radiators•Osmotic communication
- •Quality is not an afterthought •Test first design•Test driven development•Continuous integration•Continuous testing
- •Agile has room for a Charter or a Vision statement •Project management plans and approach statements•More empowering style of management based on individual accountability•Change control is built into the process. Tradeoffs managed in real time.
- •Agile does not deal much with procurement •Approach contracts with adaptability in mind•Build relationships based on trust•Create win-win agreements
- •Staffing based on available people and willingness to invest •Build your team around motivated people•Give them what they need to be successful and remove impediments•Allow teams to self-organize
- 17. We want to create self-organizing teams. We want to create teams that understand what problem they are solving and have the tools to make a difference. We want teams that know their capability and are able to make and meet commitments to the business. We want to help teams become predictable and build trust with the rest of the organization. We talk a lot about trust on agile teams... teams have to be trustworthy.
- 16. As agile project managers we are called to be servant leaders. We want to put our team members in a position to be successful. We want to help reduce dependencies and reduce the amount of task-switching the people do on a day to day basis. We want to help the team really get better over time by removing the impediments that are actually slowing them down. We want to help people think in between the lines on the Gantt chart.
- 18. As agile project managers, we tend to focus more on leadership. We focus more on managing the context around the team. We manage the environment rather than the team members themselves. The funny thing is that we often focus so much on managing people and tasks, we forget what is really cool about being a project manager in the first place. Getting out there and helping people be truly successful.
- 19. Our goal isn't to be the hub on our projects. Ours is to create a culture of innovation where people become creative problem solvers. We want our team members to talk to each other rather than to us. We want people to be accountable for outcomes not activities. Creating these kinds of teams requires a structure that just isn't present in most organizations. This is where the Agile Project Manager can have great impact!
- 20. Be empowered to go back to you organization and manage these kinds of projects. Be empowered to build these kinds of teams. Be willing to take chances and make tradeoffs. We willing to break the rules... the traditional rules and the agile rules. Every organization is different and every team is different. Know where you are, know where you want to be... and have a plan for helping your project get there.
- 2. Hello everybody, my name is Mike Cottmeyer. I am a agile transformation coach with Pillar Technology. Pillar is a 100 person consultancy based in the mid-west. We are expanding and I am opening an office out of Atlanta, Georgia. My company believes that at the end of the day, culture and structure are going to trump anything you do with people, process, and tools. Transforming businesses around agile principles is what we do.