Agile & Project Management

1. Agile&Project Management Michael Milch April 2011

2. Objective • At the conclusion the audience will have a better understanding of the term “agile” in context with development projects.

3. What is AGILE? Agile is a method that uses continuous stakeholder feedback to deliver high quality code through use cases and a series of short time-boxed development iterations.

4. What is Agile? Agile is not a methodology, but is a conceptual framework for undertaking software engineering projects. • Agile Manifesto (2001 Agile Alliance, 17 key individuals) • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan

5. Agile Adoption Challenges • Potential pitfalls: • Resistance to collaboration • Waterfall culture • Low-trust environment • Unwillingness to change • Rigid management hierarchy • Little development experience • Lack of automated tool support • Very expensive to redeploy the system. • Significant dependencies on new hardware development. • They feel they are doing a good job with non-agile approaches.

6. Agile (or Rapid) techniques have been used for decades, to resolve key challenges that adversely impact solution development projects Common Agile techniques Key Challenges • BUSINESS participation as a project team member • Joint requirements, design and prototyping sessions • Use of visual modelling and prototyping tools • Documentation of results vs. targets • Team elaboration of requirements with flexible scope change • Iterative approach allowing key components to be developed to address “I’ll know it when I see it” mentality Requirements are dynamic and difficult to lock down • Prioritization of requirements based on business objectives • Time boxing to fixed dates and fixed cost • Incremental delivery of highest priority project components first • Decomposition of large initiatives into multiple releases • Small, dedicated, co-located teams in teaming environment • Lean process framework and limited documentation Deliver business value more quickly • Architects participate and direct lead developers • High risk proof of concepts are performed early in the project • Right skills are dedicated to the project team Reduce risk of adopting new technologies

7. Why Are Organizations Adopting Agile Strategies? • Dr. Dobb’s Journal (DDJ) 2008 Project Success Survey: • Agile teams have an average success rate of 70% compared with 66% for traditional/waterfall teams • Agile teams produce higher quality work, are quicker to deliver, are more likely to deliver the right functionality, and more likely to provide greater ROI than traditional teams • Detailed results online at www.ambysoft.com/surveys/

8. Being Agile Needs More than a Set of Practices; It Needs a Change in Thinking! The Old Way The Agile Way Change Avoidance Plan-driven — Prescriptive Task-oriented Mistrust Faith in Process and Technology Technology Driving People Abstraction for Understanding Same Time, Same Place Change Acceptance Empirical Feedback — Reactive Goal-oriented Trust Faith in People People Supported by Technology Abstraction for Execution Anywhere, Anytime The biggest risks for agile adoption are not processes or tools — it's fear of change and misunderstanding agile values.

9. The case for “Agile with Discipline” from the Project Management perspective. • Agile • “We don’t need any stinking project managers” • Just-in-time, next iteration focused, architecture and usability often fall through the cracks • Many missed due to lack of planning • High focus on blocker removal on a daily basis • “Burn down” of effort within an iteration is often the only stakeholder level status provided • Goals for 30 day iterations and sprint selected from backlog of requirements • Agile With Discipline • PM is able to empower and shepherd the team, and keeps team focused and productive • End-to-end planning for agile technique usage with participation of key specialists • Risks are identified and mitigated by proactive, out of the box thinking • Daily issue identification and resolution • PM is always aware of status, and provides summary to Stakeholders on a weekly basis including a burn down of story completion against the iteration baseline • Baseline three iterations, then allow variation of prioritized scope within fixed deadline and budget • Traditional • PM often becomes an un-empowered project administrator • Commit too early to levels of detail that are unknown throughout waterfall phases • Too often accepted and reacted to and allowed to adversely impact delivery • Issue identification lags the need for the team to have it resolved • Something the PM records during their one weekly meeting with the team • Change to scope = change to deadline and budget Role of PM Planning approach Risks Issues Status Scope Mgmt

10. Key Messages Position Paper Overview • Project Management is still required. • Agile Projects must comply with the Business Management System where they operate. • Agile Projects requires some type of Project Management System tailored the the existing project management methodology. • Agile projects typically form a component or portion of a larger project • Requires a light PM system at the Scrum level • Most of the PM system resides at the overall project level • Existing Agile management methods (e.g., Scrum) form a minimum PM system with many activities of the total PM system residing outside of the Scrum.

11. Mainstream Agile Practices • Continuous Integration • Test Drive Development (TDD) • Refactoring • Regular Deployment of Working Software • Non-Solo Development • Configuration Management • Agile Testing • Agile Documentation

12. Length of Iterations (% respondents) 82% have iterations between 1 and 4 weeks in length: Source: Dr Dobb’s 2008 Agile Adoption Survey

13. Scrum Management Methods Project Overview • Scrum has emerged as the predominate method to manage Agile Projects. • Scrum has well defined methods to manage code development and test. • These methods form a minimum PM system within the Scrum • Minimum planning is required in the form of a Release plan and Iteration Plan. • Tracking and Control occurs via Daily Scrum Meeting and Burn down charts. • Technical Change Management occurs as a byproduct of Agile. • Risk is minimized via frequent stakeholder reviews and input. • Issue Management occurs informally and through the Daily Scrum meeting.

14. Project Overview Role of the Project Manager in managing the non Agile aspects of the project which is similar to managing a traditional project. However, managing the Agile portions requires some changes in behavior. • Overall Project requires a Project Management system and managed by a Project Manager • Project Manager must off load or buffer the Scrum from activities that are not related to code development and test to enable the Scrum to be fully Agile • If the Project Manager is also the Scrum Master then the role must change from PM of the overall project to Facilitator when working with the Scrum • Role of the Scrum Master is different that PM and is defined by the Agile approach as a facilitator and not a manager.

15. The overall project with a project management system needs to offload or buffer the Scrum Team from: 1. Business Management System Requirements. 2.Activities not related to code development and unit testing. 3. Executive and Management reporting. Enable the Scrum team to remain totally Agile.

16. Disciplined Agile Teams • Produce working software on a regular basis. • Do continuous regression testing, and better yet take a Test-Driven Development (TDD) approach. • Work closely with their stakeholders, ideally on a daily basis. • Are self-organizing, and disciplined teams work within an appropriate governance framework. • Regularly reflect, and measure, on how they work together and then act to improve on their findings in a timely manner.

17. Agile project teams, when compared to waterfall project teams. • Enjoy higher success rates. • Deliver higher quality. • Have greater levels of stakeholder satisfaction. • Provide better return on investment (ROI). • Deliver systems to market sooner.

18. Improvements from using Agile Methods 82% 77% 37% 78% Source: Dr. Dobbs Agile Community Survey

19. Before starting an Agile Project, the Project Manager should: Project Overview 1. Become familiar with AGILE and take some education. 2.Complete specific Agile training for your Company and Business Unit. 3. Read materials on the Agile. 4. Contact other Agile Leaders within your organization, business unit, company, industry and try to get any other guidance.

20. Agile Development combines Iterative & Incremental Delivery Waterfall Concept Plan Develop Qualify Roll out A/B/C Agile Iteration 1 Iteration n Iteration 2 Iteration 3 Iteration 4 Integrated & Aligned SMB (Europe & AP) Brands (above Client Id) Refine & Add Function Concept Rollout Refine & Add Function Requirements Design Develop/Test User Acceptance Usability Test Integration Test with XXX to BBB Requirements Design Develop/Test User Acceptance Usability Test Integration Test with XXX to AAA Requirements Design Develop/Test User Acceptance Usability Test Requirements Design Develop/Test User Acceptance Usability Test Requirements Design Develop/Test User Acceptance Usability Test User Acceptance Usability Test Prepare Education & Communications for Users

21. Ask about the handout! Agile-Plus Process Flow April 2008 Raleigh

22. Iterations allow for mid course corrections Zone of success Planned Completion Increasing Knowledge Planned Path Start Actual Path As Knowledge increases Leaders use iterations to guide project towards enhanced goal Actual Completion 22

23. Closing thoughts about Projects Source: Znet The more desperate the situation the more optimistic the progress report. Nothing is impossible for the person who doesn’t have to do it. If at first you don’t succeed, rename the project Everyone wants a strong project manager - until they get him. The worst project managers sleep at night. Projects don’t fail in the end; they fail at conception.

24. Agile Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/

25. Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software. Welcome changing requirements, even late in 
development. Agile processes harness change for 
the customer's competitive advantage. Deliver working software frequently, from a 
couple of weeks to a couple of months, with a 
preference to the shorter timescale. Business people and developers must work 
together daily throughout the project. Build projects around motivated individuals. 
Give them the environment and support they need, 
and trust them to get the job done. The most efficient and effective method of 
conveying information to and within a development 
team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence 
and good design enhances agility. Simplicity--the art of maximizing the amount 
of work not done--is essential. The best architectures, requirements, and designs 
emerge from self-organizing teams. At regular intervals, the team reflects on how 
to become more effective, then tunes and adjusts 
its behavior accordingly. http://agilemanifesto.org/principles.html

27. The SCRUM Process NOTE: Sprint and Iteration are used interchangeably and mean the same thing

29. Pigs and Chickens

30. SCRUM Roles

31. SCRUM”S Key Artifacts

32. Key Meetings • Sprint Planning Meeting • Hosted by ScrumMaster • Attended by all • Input: Product backlog, existing product, business and technology conditions • Select highest priority items in Backlog; declare the sprint goals • Team turns selected items into Sprint Backlog • Output: Sprint Goal, Sprint Backlog • Daily Scrum • Hosted by ScrumMaster • Attended by development team • Same time every day • Answer • What did you do yesterday? • What will you do today? • What’s In your way? • Team updates Sprint Backlog • Scrum Master updates Blocks List Sprint Review Meeting Hosted by ScrumMaster Attended by all Informal, 4 hour, informational Team demos increment All Discuss Hold reflection Announce next Sprint Planning Meeting NOT status for the ScrumMaster BUT Commitments in front of peers

33. The SCRUM Process

34. Daily Scrums • Daily 15 minute status meeting: • • Same place and time every day; • • Meeting room; • • Chickens and pigs; • • Three questions; • –What have you done since last meeting? • –What will you do before next meeting? • –What is in your way? • • Impediments; and • • Decisions

35. Scrum Masters Responsible for: Removing the barriers between development and the customer so the customer directly drives development; Teaching the customer how to maximize ROI and meet their objectives through Scrum; Improving the lives of the development team by facilitating creativity and empowerment; Improving the productivity of the development team in any way possible; and, Improving the engineering practices and tools so each increment of functionality is potentially shippable. A Scrum Master is always driving towards conformance to VALUE, not conformance to PLAN.

36. Done ?!

37. Definition of “Done” • At the end of each iteration: • No Sev 1s or Sev 2s • No Sev 3s or Sev 4s the team has not agreed to • Code is unit tested, function tested, system tested, performance tested, tested end-to-end, and included in appropriate green threads • A meaningful stakeholder review has been conducted • Can this really be done? This puts a high premium on: • Valuable, maintained, nested automation • Appropriate code coverage (e.g. 80%) • True test-driven development • Avoiding technical debt • Continuous integration (e.g. Cruise Control) • Really understanding what quality code looks like

38. Technical Debt

39. Nokia Checklist • You know you’re not iterative when • Iterations are longer than 6 weeks. • They are not time-boxed. • Team tries to finish all specification before programming. • Iteration doesn’t result in workable code. • Iterations don’t include testing. • You know you do not use Scrum when • The team doesn’t know who the product owner is. • Your product backlog doesn’t contain estimates. • You cannot generate a release burn-down chart and you don’t know your velocity. • There is a project manager in the project who is interfering with the team (not the Scrum Master).