Best Practices When Moving To Agile Project Management


Published on

Delivered to the York Technology Association

Best Practices When Moving To Agile Project Management

  1. 1. Best Practices When Moving to Agile Project Management Presented By: Robert McGeachy, PMP Kintyre Consulting Incorporated February 26, 2010 York Technology Association February 26, 2010 - Markham, Ontario
  2. 2. Learning Objectives <ul><li>Understand the major issues teams face when adopting Agile processes </li></ul><ul><li>Walk through the process to train and inspire a team new to Agile </li></ul><ul><li>Learn how to transition roles from a Project Manager to an Agile Coach </li></ul><ul><ul><li>Moving your team to Agile is akin to moving to a new country with a new language and culture. No amount of training can prepare you for every challenge. </li></ul></ul>
  3. 3. <ul><li>Agile Principles </li></ul><ul><li>The 5 “Gotchas” </li></ul><ul><li>Setting up your Team </li></ul><ul><li>Organizational Success Factors </li></ul><ul><ul><li>Agenda </li></ul></ul>
  4. 4. Who is the presentation for? <ul><li>The people or organizations that are looking to improve on the efficiency of their development processes and the quality and alignment to business requirements </li></ul><ul><li>Generally, these methodologies are applied to the software or IT project. But Agile approaches can be adopted for other types of projects. </li></ul><ul><li>Some basic or general understanding of Agile Methodologies is assumed </li></ul><ul><li>We wont solve all the problems, but will point out the areas project managers and teams should focus on when making a change to Agile </li></ul>
  5. 5. <ul><li>Agile Principles </li></ul><ul><li>The 5 “Gotchas” </li></ul><ul><li>Setting up your Team </li></ul><ul><li>Organizational Success Factors </li></ul><ul><ul><li>Agenda </li></ul></ul>
  6. 6. Waterfall vs. Agile <ul><li>A project is broken into releases (a release should occur no less frequently than every 4 months) </li></ul><ul><li>Releases are broken into short (1-4 week) iterations </li></ul>Discovery Design Implementation Manage Waterfall Define Release 1 Release 2 Agile It 1 It 2 It 3 It 4 It 5 It 6 Release 3 It 7 It 8 It 9 Release 4 It 10 It 11 It 12 Iteration N Mon Local team: acts as interface to client, does some dev work team: develops and tests Fri Mon: Iteration kick-off with client Fri: End-of-iteration checkpoint with client Go Live Go Live
  7. 7. 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
  8. 8. Agile principles <ul><li>Highest priority is to satisfy the customer through early and continuous delivery of valuable software </li></ul><ul><li>Welcome changing requirements, even late in development and focus on the customer's competitive advantage </li></ul><ul><li>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale </li></ul><ul><li>Business people and developers must work together daily throughout the project </li></ul><ul><li>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done </li></ul><ul><li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation </li></ul>
  9. 9. Agile principles (continued) <ul><li>Working software is the primary measure of progress </li></ul><ul><li>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely </li></ul><ul><li>Continuous attention to technical excellence and good design enhances agility </li></ul><ul><li>Simplicity – the art of maximizing the amount of work not done – is essential </li></ul><ul><li>The best architectures, requirements, and designs emerge from self-organising teams </li></ul><ul><li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly </li></ul>
  10. 10. The Four Main Benefits of Agile (if done right!) <ul><li>Increases Flexibility </li></ul><ul><ul><li>It minimizes up front investment and maximizes return on investment (ROI) by creating an efficient IT development process </li></ul></ul><ul><li>Delivers the Right Solution </li></ul><ul><ul><li>It aligns users and stakeholders with the right people to deliver the solution that the business actually needs </li></ul></ul><ul><li>Accelerates Delivery </li></ul><ul><ul><li>Iterations get to the right solution faster </li></ul></ul><ul><li>Reduces Risk and Increases Quality </li></ul><ul><ul><li>Greater stakeholder visibility and control </li></ul></ul>
  11. 11. <ul><li>Agile Principles </li></ul><ul><li>The 5 “Gotchas” </li></ul><ul><li>Setting up your Team </li></ul><ul><li>Organizational Success Factors </li></ul><ul><ul><li>Agenda </li></ul></ul>
  12. 12. The 5 “Gotchas” for the Agile Team <ul><li>Lack of discipline </li></ul><ul><li>The iterative death spiral </li></ul><ul><li>Changes in working styles </li></ul><ul><li>The new role of testing </li></ul><ul><li>Changes in responsibilities and expectations </li></ul>
  13. 13. Lack of discipline <ul><li>Although it may seem counter intuitive, Agile is an extremely disciplined approach to working </li></ul><ul><li>Agile does not equal sloppiness. Most people will have a difficult time adjusting to this </li></ul><ul><li>Tracking stories to closure, accounting for the velocity of an iteration, tracking one’s estimate to complete -- these are all things where every team will slip up the first few iterations </li></ul><ul><li>Without discipline Agile will not work. Setting good examples and continually following up are essential </li></ul>
  14. 14. The iterative death spiral <ul><li>People misinterpret the term ‘iterative’ to mean that there is unlimited ability to revisit scope </li></ul><ul><li>In fact, Agile success hinges on incremental completion of scope throughout the project </li></ul><ul><li>Teams that do not effectively define their “exit criteria” for each work unit (known as “story”), will never get real closure on work in progress </li></ul><ul><li>This leads to endless cycles of revisions that are really scope changes but which are not labeled so because of the misperception, causing delays, overruns, and a demoralized team </li></ul>
  15. 15. Changes in working style <ul><li>Developers used to working in a solo mode will have a bit of a hump to get over when working in small teams to complete stories. </li></ul><ul><li>This can manifest itself in stalled work, as communication reverts to inefficient mechanisms such as email (instead of sitting together, or picking up the phone) </li></ul><ul><li>In a typical project the pressures of learning the business, addressing technology, business, and team personality issues, will very quickly overwhelm even the most prepared person </li></ul><ul><li>Add to this a major change in delivery methodology and it will lead one to revert to known approaches </li></ul><ul><li>A major mitigation here is training and more importantly, effective support from someone with actual experience in the field </li></ul>
  16. 16. The new role of testing <ul><li>Automated testing is fundamental to quality, short delivery cycles, and hence the agile model </li></ul><ul><li>Yet, there are many barriers: taking on a legacy application with no existing test suites; lack of tools for many aspects of an application; lack of team knowledge on how to do this </li></ul><ul><li>People will want to revert to more comfortable manual testing approaches </li></ul><ul><li>TDD (Test-Driven Development) will be a struggle to adopt. It is counter-intuitive unless tried </li></ul>
  17. 17. The change in responsibilities and expectations <ul><li>Given focus on transparency and on pushing responsibility to the team, the Project Lead will be less of a task manager, and more of a problem solver, and will have to “let go” of a lot of previously-held control </li></ul><ul><li>Developers will work hand in hand with testers and cannot declare a piece of code “done” until the tester gives the green light </li></ul><ul><li>Testers who are used to having a more clearly specified set of tasks will struggle, as the Agile tester role involves more thought, planning, and business knowledge </li></ul><ul><li>For Business Analysts, working just in time on requirements will feel very unnatural. Working hand in hand with developers to define requirements and then to help test them as a developer works will feel very foreign </li></ul><ul><li>This problem will be exacerbated by the multiple reporting structures that exist between team members </li></ul>
  18. 18. <ul><li>Agile Principles </li></ul><ul><li>The 5 “Gotchas” </li></ul><ul><li>Setting up your Team </li></ul><ul><li>Organizational Success Factors </li></ul><ul><ul><li>Agenda </li></ul></ul>
  19. 19. <ul><li>Project Manager </li></ul><ul><ul><li>Scrum Master, manages issues and removes roadblocks </li></ul></ul><ul><li>Architect </li></ul><ul><ul><li>Responsible for overall system architecture and development quality and processes </li></ul></ul><ul><li>Developer </li></ul><ul><ul><li>Participates in design, creates unit tests, builds and delivers code </li></ul></ul><ul><li>Tester </li></ul><ul><ul><li>Dedicated testers assigned to each track (ratio typically ranges from 2:1 to 4:1) </li></ul></ul><ul><li>Test Lead </li></ul><ul><ul><li>Responsible for organizing and planning testing efforts </li></ul></ul><ul><ul><li>Mentors testers </li></ul></ul><ul><li>Client Proxy </li></ul><ul><ul><li>Helps remote teams clarify requirements and run issues to ground </li></ul></ul><ul><li>Product Owner </li></ul><ul><ul><li>Client owner who participates in Kick-offs and Iteration closures, as well as provides feedback </li></ul></ul>
  20. 20. Physical Space and Co-Location <ul><li>The most effective layout for the physical team location is co-located desks </li></ul><ul><li>There should be shared access to plans, status, next steps, and other project planning and management tools. </li></ul><ul><li>In teams that must be geographically separated, then tools for conducting virtual meetings such as conference call phones, instant messaging, shared electronic documents and tools are leveraged to minimize the distance and separation </li></ul>
  21. 21. The War Room <ul><li>Team Structure - the basic &quot;who's on the team&quot;, including contact information </li></ul><ul><li>High level plan, Mid Level Plan - The overall project milestones, and the key iterations and release dates, with the anticipated objectives or deliverables for each </li></ul><ul><li>Roles and Responsibilities - A RACI style chart with the internal and external roles and the person on the team who is responsible </li></ul><ul><li>Story Board - The stories for this iteration, what is complete, in-progress, and not started </li></ul><ul><li>Client Deliverables - This may seem straight forward, but a reminder as too what we as a team are trying to deliver </li></ul><ul><li>Client Phase Exit Criteria - What are we marching toward to complete the current phase and achieve signoff </li></ul><ul><li>Story Stack - The scope of the project </li></ul><ul><li>Meeting Agenda - The standard daily team stand-up meeting has a strict, short agenda so we can complete it within 30 minutes </li></ul><ul><li>Issues and Next Step s - The whiteboard list of next steps, dates, owners, to be checked during each team meeting </li></ul><ul><li>Risks - The whiteboard list of risks, impact, and mitigation that needs to be taken (with owner) </li></ul><ul><li>Recognition Awards - Some place to call out great work by the team or individuals. </li></ul><ul><li>Ground Rules - The team derived rules for respecting each other </li></ul>
  22. 22. <ul><li>Agile Principles </li></ul><ul><li>The 5 “Gotchas” </li></ul><ul><li>Setting up your Team </li></ul><ul><li>Organizational Success Factors </li></ul><ul><ul><li>Agenda </li></ul></ul>
  23. 23. Is Your Organization Ready For Agile? <ul><li>Trust pervades the culture of the organization, the interactions between its people, and its clients </li></ul><ul><li>Individuals demonstrate a high level of enthusiasm for or openness toward change </li></ul><ul><li>Management empowers individuals to take risks without fear of repercussions </li></ul><ul><li>Disciplined execution is representative of the organization’s delivery practices or broadly viewed as a goal worth of striving for </li></ul><ul><li>Teams and management alike evidence the commitment and patience necessary to seeing through changes despite challenges and disappointments along the way </li></ul><ul><li>A willingness exists to make reasonable investments in tools, training, coaching and mentoring to facilitate successful adoption and sustained change. </li></ul>
  24. 24. Learning Objectives <ul><li>Learned the major issues teams face when adopting Agile processes </li></ul><ul><li>Walk through the process to train and inspire a team new to Agile </li></ul><ul><li>Learned how to transition roles from a Project Manager to an Agile Coach </li></ul><ul><ul><li>We reviewed the major “gotchas” that can derail a project with team members new to Agile. </li></ul></ul>
  25. 25. Robert McGeachy [email_address]