Introduction to Agile and Scrum

Transcription

1 Introduction to Agile and Scrum Bob Schommer, CSP, PMP, MCTS Senior Project Manager Skyline Technologies, Inc. PMI Northeast Wisconsin Chapter May 3, 2011

2 About Skyline Technologies Microsoft Gold Certified Partner supporting five practice areas including: Business Intelligence, Custom Software Solutions, Enterprise Portals, Online Marketing and IT Business Consulting. Skyline s IT Business Consulting group: Builds IT strategies that transform IT from a cost center into a strategic asset; Integrates IT into official business processes so companies can exploit technology to drive profitable growth, control costs and improve customer service; Guides and mentors people in best of breed development methodologies, business analysis techniques and quality assurance programs; Provides certified (PMI and Scrum) program and project managers, senior quality assurance professionals and experienced business analysts. Proud sponsors of PMI-NEW and the Northeast Wisconsin Agile Users Group Partnering with You to Deliver Business Ready IT

3 Agenda Agile Principles The Scrum Framework Case Study: Crew Self Service Implementation Considerations PMI Agile Certification Final Thoughts and Questions

4 What does it mean to be agile? Iterative and incremental development (IID) Working software in each iteration Evolutionary and adaptive Inspect and adapt Visibility Iterative and adaptive planning Risk driven Value driven Self managed and self organized teams Time boxed

5 History 1957: IID was used on NASA s Project Mercury 1970 s: Successful use on numerous large, lifecritical systems (e.g. space, avionic, defense) 1992: Canadian ATC system 1994: DoD adopts new standard that prefers iterative and evolutionary methods 1995: Jeff Sutherland and Ken Schwaber first formalized Scrum 2001: Agile Manifesto emerged during a weekend meeting of seventeen agilites in Utah

6 Agile Manifesto 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 Working software over Customer collaboration over Responding to change over processes and tools. comprehensive documentation. contract negotiation. following a plan. That is, while there is value in the items on the right, we value the items on the left more.

7 Agile 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.

8 Agile Principles 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.

9 Triple Constraint Does Not Go Away Traditional Methods Agile Approach Scope Scope Prioritized by business value Scope drives budget and schedule Budget and schedule drives scope Cost Time Cost Time It is impossible to fully define requirements until the client actually begins to use the product.

11 Scrum Terms Scrum Sprint Product Backlog Sprint Backlog Not an acronym. Sometimes used to refer to the daily stand up meeting An iteration typically 2-4 weeks in duration A prioritized list of product features with estimated effort Detailed list of tasks that the Scrum Team has committed to deliver during a sprint Scrum Board Used by Scrum Teams to track sprint progress typically a white board with post-it notes Burn Down Publicly displayed chart showing work remaining either for the sprint or a release

12 Scrum Roles

13 The Scrum Framework Potential Deployment Product Backlog & Team Formation Sprint 2-4 Weeks Team Retrospective Sprint Planning 2 Parts: Selection and Decomp Sprint Review Daily Scrum

14 Scrum Planning Sometimes called Sprint 0 Primary work product is a healthy Product Backlog Typically in the form of user stories (product features) Whatever your company requires to initiate a project Establish team, team rules, sprint length, space, Co-located team is most optimal Do not try to define all requirements More time spent here means that the team is not creating software

16 Sprint Planning Prerequisite: A healthy Product Backlog Beginning of each sprint Part I: Selection and capacity assessment Time box at 1 hour per week in sprint Product Owner shares vision for the product and goals for the sprint Team members provide capacity for the sprint Part II: Decomposition and design Time boxed at 1 hour per week in sprint Team decomposes user stories into tasks Product Owner is available for questions or changes

18 Daily Scrum Daily 15 minute meeting usually stand up Same place and time every day At a time when all team members can attend Team members speak, anyone else can observe Three questions What have you done since last meeting? What will you do before the next meeting? What is in your way? Fourth question: How are we doing? Updates on impediments and decisions Sprint Burn Down updates Inspect and adapt for benefit of sprint

20 Sprint Review End of each sprint Assess how well the sprint goal was met Team Members demo each item in sprint goal Not a formal presentation PowerPoint is prohibited! Updates to Product Backlog Product Owner determines whether to release Inspect and adapt for benefit of project

21 The Scrum Framework Potential Deployment Product Backlog & Team Formation Sprint Planning 2 Parts: Selection and Decomp Sprint 2-4 Weeks Team Retrospective Sprint Review Daily Scrum

22 Team Retrospective Process improvement at end of every sprint What went well? What can be improved? Prioritized with input from team members Team comes up with solutions Inspect and adapt for benefit of team

24 Project Overview Objective Offer remote access for all crew members where they can gather all essential information from one site Features Crew schedules Hotel information Crew alerts and announcements Schedule change requests Automated trip sign in Dashboard and technical framework

25 Expected Business Value Reduction in flight delays Real time schedule information Automated sign in Productivity improvements for support staff Reduced phone calls and requests Improved crew member satisfaction Hotel information Schedule change requests

26 The Scrum Team Product Owner: Client Sponsor / BA delegate Scrum Team Four Developers One client Developer ScrumMaster: 50% allocated Co-located two days each week SharePoint and IM for collaboration Two week sprints Nightly builds Testing was not automated

27 Product Backlog Product Backlog User Stories Estimates Technical Framework Sprint Backlog Team Capacity Task Decomposition Sprint Burndown

28 Project Retrospective Too much time spent in Scrum Planning Should have included more of the client team on the Scrum Team Legal process was not agile Product Owner delegate was over-allocated Product Backlog was not always groomed before Sprint Planning Should have provided more Scrum training to team members and business SME s

30 What s Wrong With Waterfall? Nothing if your project is: Low-change Low-novelty Low-complexity Pushes high-risk, high-difficulty elements toward the end of the project Testing Integration of major components Clarification of interfaces Fail-late Fosters analysis paralysis Include all functionality now while funds are allocated Fear of signing

31 What s Wrong With Waterfall? Paperwork Analysis and design documents Approvals Adverse to change Relies on accurate up-front estimates Complete definition of the product before anyone has seen it Which usually ends up being during testing at the end of the project Scope management procedures to govern changes Plan the work Work the plan Comprehensive schedules Baselines Tracking of actual hours worked

32 Agile Methods Scrum Extreme Programming (XP) Crystal Methods Unified Process (UP) Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) Lean Development Adaptive Software Development Evolutionary Project Management (Evo)

33 What tool is best? That s like asking what is better a hammer or a screw driver Depends on the job you are trying to do Agile methods are often called lightweight Fewer constraints than traditional Some are more prescriptive than others * More prescriptive More adaptive * From Kanban and Scrum making the best of both (Kniberg & Skarin 2009)

34 Why is it so hard to be agile? Both top-down and bottom up support is needed Old paradigms are hard to break Most leaders were taught waterfall in school Best practices can derail continuous improvement efforts Emergent design can appear like hacking to some What made you competent before The end state is unknown Requires personalization for your organization Almost everyone and everything is impacted Not just an IT initiative

35 Agile Skeleton and Heart Skeleton Build the right thing Fairly easy to implement Within weeks for many Customers begin seeing improvement Heart Build the thing right Can be more difficult Can take months or even years Change in culture, behavior and organization Opportunities are exciting!

36 IT Impacts Roles will change Project Managers Business Analysts Developers QA Middle Management Change management Technology enablers Continuous build Test driven development Automated testing Location of team members

37 Organizational Impacts Sales Human Resources Finance PMO Facilities Company culture and commitment

38 Co-Existing with Traditional Methods Possible scenarios Waterfall up front Waterfall at the end Waterfall in tandem Governance Stage-gates designed for waterfall Not evil but should not dictate how project is run Build trust Compliance (CMMI, ISO 9001, Sarbanes-Oxley)

39 The Agile Business Case High Value Features Faster to market Adaptable to changes even late in development IKIWISI Deliver what is needed, not necessarily what is requested Higher Quality Test early and often Improvements to testing as you iterate On Time, On Budget, On Target Power of time boxing People remember slipped dates, not slipped features Schedule and Cost are constants Scope is the variable

40 The Agile Business Case Risk Mitigation Agile is lower risk than waterfall development Early risk mitigation and discovery Improved Visibility into Projects Predictability Meaningful metrics working software Team Morale Confidence and satisfaction from early and repeated success Self organized, self managed and empowered Face-to-face communications No death marches Process Improvement Within the project, team, IT and the company Sushi delivery

42 Agile Certifications Scrum Certifications ScrumMaster (CSM) Scrum Product Owner (CSPO) Scrum Developer (CSD) Scrum Professional (CSP) Scrum Coach (CSC) PMI Agile Certification

43 The Certification Debate Agile purist viewpoint Need less certification not more Discriminates against great people who are not certified Being certified does not guarantee competence PMI and PMBOK is what agile-ists rebelled against I am already competent in agile, so why do I have to get certified? It s only about the money

44 The Certification Debate Why PMI? Responsible project delivery across industries PMBOK does not preclude agile PMI is not to blame for bureaucratic control freaks using the PMBOK to enforce standards that stifle creativity Credibility Over 400,000 registered PMPs More than 3 million copies of PMBOK in circulation PMI appeals to a critical mass of project managers Members and companies are requesting it

45 Common Ground Both PMI and agile strive for successful projects and happy stakeholders 65% of PMI members are engaged in IT projects Gartner predicts that 80% of software projects will use agile methods by 2012 PMI s Agile Certification will be more rigorous than most other agile certifications

46 PMI Agile Certification Criteria Pass a three hour, 120 question exam High school or equivalent education 2000 hours of general project management experience within the last 5 years Does not apply for anyone currently holding a PMP 1500 hours of agile project management experience within the last two years In addition to the 2000 hours of general PM 21 hours of agile project management training

47 PMI Agile Certification Timeline Candidates can begin applying for pilot program in May 2011 Open to anyone Examination Content Outline is available now Exam will be released during the third quarter of 2011 Pilot program participants will receive scores approximately weeks after taking exam

49 Themes to Take With You Have you added any tools to your toolbox lately? Focus on features not tasks Working software early, often and valuable Embrace change Importance of individuals and the team Involve your team Collaboration among the team and stakeholders Ideally co-located Continuously improve Best practices promote complacency Know what is enough documentation Agile projects done right are fun!

50 Challenge the Status Quo Agile is consistent with continuous improvement Lean for software development Anything that slows down the team should be challenged Governance PMO Even regulatory (Do just enough to pass) Impetus for holistic organizational improvements

51 Resources Web Sites Books Agile and Iterative Development: A Manager s Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Kanban and Scrum: Making the most of both by Henrick Kniberg and Mattias Skarin Succeeding with Agile by Mike Cohn NEW Agile Users Group ( Next meeting: Thursday, May 26, 2011 at 5:30 PM Fox Valley Technical College: Room C101

52 Questions?

53 Thank You For questions or more information, please contact: Bob Schommer, CSP, PMP, MCTS Senior Project Manager at Skyline Technologies