Robert Mc Geachy Common Pitfalls Agile
•Download as PPT, PDF•
3 likes•2,687 views
Common pitfalls moving to Agile
![Learning Objectives ,[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Robert Mc Geachy Common Pitfalls Agile
Similar to Robert Mc Geachy Common Pitfalls Agile (20)
Robert Mc Geachy Common Pitfalls Agile
- 1. Common Pitfalls When Moving to Agile Presented by : Robert McGeachy, PMP Thursday April 17, 2008
- 13. Agile Delivery Model Short Iterations (1-4 weeks) 24 hours (1) Validate/Reprioritize scope At the start of each iteration, the team works with the client to validate planned iteration scope and if needed reprioritise or swap scope (2) Build iteration plan The team works with the client to gain a deeper understanding of the iteration requirements and be able to break the work down allocated to their track. Each track uses this to create an iteration plan (3) Daily team Meeting The team meets daily to report status and address roadblocks Iteration Scope (4) Deliver potentially deployable functionality The team performs Analysis & Design, Requirements detailing, Development and testing of the selected scope items to deliver something of value to the client at the end of each iteration Potentially Depoyable Functionality Iteration Plan Checkpoint with client
Editor's Notes
- The previous slide and this slide go right to the heart that big upfront requirements and design work (without client validation and course correction as you go) results in waste. In order words, requirements get implemented that are rarely or never used.
- This hits on Executable Architecture Release (EAR) The purpose of the EAR is to do the minimum amount of work to understand the problem and commit to a solution To achieve this each team must assess what combination of requirements, analysis, development and design activities are necessary to mitigate both requirement and technical risks associated with the project Release Planning Release every 3-5 iterations (never more than 3 months) Work with client to identify target functionality for first release: what is their “minimal marketable feature set?” The smallest subset of the solution’s capabilities that would have value for the client Know that the mid-level plan will change, don’t try to get too precise Iteration Planning An iteration length is typically 2 weeks, but never longer than 4 weeks Focus on “Done is Done” while talking about iteration planning Deliverables must be production-ready at end of every iteration No separate “clean up” phase Forces decision making and closure on the things of immediate concern Need to leave time to do closeout within the iteration
- Speaker notes: When we sit with the client we are not necessarily saying that each kickoff we need to reprioritise scope. We are showing them what was originally planned for the iteration, and then providing them with the option to swap scope if they feel it is necessary. It is providing this choice that is very powerful. We have seen from our pilot projects that many times, after seeing what was delivered, clients have made scope choices that they may not have if they had not seen working code. This happened in Avatar.
- Speaker notes: While these are the Agile Principles in the ideal world, not all of these will work for the environment that Sapient works in. We have taken what we can, and made adjustments where the principles do not fit out business model. For example, our clients are more often than not available to work side by side with us, as indicated in the point „Business people and developers must work together daily“. This is not always a luxury that we have. Our clients do not always want to or have the time to be working side by side with us, and can only spend very limited time with us. Addtionally, we live in a GDD world, so most of the time we do not have the luxury of all team members being in the 1 location (as aluded to in the last bullet). Face to face conversations are most of the time not possible when the majority of the team (if any) are not at the client location.