A real-life overview of Agile workflow practices

Embed Size (px)

DESCRIPTION

I gave this talk March 18, 2013 as part of Villanova University's Computer Science Colloquium series - http://csc.villanova.edu/colloquia/view/725

Text of A real-life overview of Agile workflow practices

  • 1. A real-life overview of Agile workflow practices Michael Toppa @mtoppa www.toppa.com 3/18/2013

2. Mike Toppa19 years of experience in web development, project management, andfunctional management Currently: Rails Engineer, ElectNext Previously: Director of Development, WebDevStudios Director of Web Applications, U Penn School of Medicine Web developer at: Georgetown University, Stanford University, E*Trade, and Ask Jeeves 3. Overview Theory Waterfall vs Agile Practice My experiences at U Penn ...and ElectNext 4. TheorySo whats the problem? 5. The software development dilemmaQuality Features Pick any twoFast LowSchedule CostIve explained the triangle to dozens of clients over the yearsProgramming is not magic 6. Traditional Waterfall ApproachSourceFeatures determine the cost and scheduleDefine all requirements up frontLogically break down the workEstimate the effort / durationsPlan out all the workAnd only then begin the developmentwhile trying to limit any change that willthreaten the plan. 7. A perspective on the traditional approachSource 8. Information is lost in handoffsSource 9. No opportunity for feedback I nd your lack of faith disturbingSource 10. Over-production of features SourceAsk customers what they want at the beginning, when they really dont knowPenalize them for adding things laterTCL example 11. Low success rate The main thing that pushed Agile and Scrum was that the success rate on traditional projects was terrible; it was 45%. If that was a car-manufacturing place, that would mean youd throw out every other car you built. Ken Schwaber, co-creator of Scrum, 6/21/2011Source 12. SourceCost in software projects means manpowerBrooks Law: adding more manpower makes late projects later 13. Source 14. Agile: frequent feedback SourceEvery iteration ends with a retrospectiveAlso, feedback from clients during iteration review 15. Agile: inspect and adaptSourceSingle loop learning is how can we do better?Double loop learning is Why do we believe that?Double loop learning means challenging fundamental assumptions 16. Agile: incremental and iterative SourceDevelop systems in small portions at a time (incremental), through repeated cycles (iterative),and take advantage of what was learned in each cycle (for both features and implementation) 17. The Agile workflowSource 18. Why? The pace of business keeps getting faster Feedback is essential Time is scarce Things will change 19. Incremental development:slice vertically, not horizontally SourceThis is where developers unfamiliar with Agile freak outHow do you develop a UI or a database in pieces? This seems like it would lead to a giantmess. Remember the iterative part - we can sketch out the overall design, but we buildincrementally, eshing out the details of whats needed soonIt is possible, it is practical, and there are a lot of people doing it.Its actually the opposite of messy hacking. Doing it well requires a very disciplineddevelopment process, and strong application design skills, as you are trying to maintain asolid application design while always being ready to adapt to change. 20. The Agile Umbrella SourceAgile is a mindset and a set of values. There are multiple methodologies that implement it.Ill focus on the most popular one, Scrum 21. Scrum: overviewSource 22. Scrum has 3 roles Product owner Scrum master Self-organizing, cross-functional team 23. Scrum role: Product Owner Responsible for what the team will work on,and setting priorities, but not how the work is doneResponsible for what the team will work on, but not how the work is doneWorks closely with clients to understand their needsGathers and writes business requirements in small pieces, called user storiesBased on client needs, sets priorities for the teamDoes not have authority over technical design decisionsCannot tell an individual team member what to doA good Product Owner is: available, business-savvy, communicative, decisive, empowered 24. Scrum role: Scrum MasterA servant-leader for the teamA servant-leader for the team - analogous to a physical trainerCan coach and evangelize, but not issue commandsBut does have authority over the Scrum processRemoves obstacles for the teamA good Scrum Master is: responsible, humble, collaborative, committed, inuential, andknowledgeable 25. The team: self-organizingand cross-functional SourceCross-functional team takes collective responsibility for estimating the work, and doing theworkDoing it in the priority order they are asked to followKeeping quality high by working together (inspecting each others code, discussing besttechnical solutions, etc) 26. So whosthe boss? SourcePersonnel management exists completely outside this structure.Works best in relatively at organizations where people are given autonomy and achievablegoalsAntithetical to top-down, command and control hierarchiesMore on the this later 27. Practice My experiences at U Penn 28. The team 15 web developers and designers Ad-hoc development process: hadnt heard of waterfall or agile Independent: developers worked alone on projects (a huge businessrisk) Customer service oriented: say yes to everything Focused on fast delivery 29. The situation Ever growing number of clients and projects Hiring freeze Sparse project management, little documentation Ambiguous lines of authority Reactive planning, daily reghting No one in a position to prioritize -> politicized decision making 30. Mike: Why Agile? Why Scrum? Maintain frequent interactions with clients Enable planning Reduce risk Improve qualityMaintain frequent interactions with clients- Provides quick feedback, Existing good relationshipsEnable planning- make commitments, and meet them, Reduce need for reghtingReduce risk- Have more than one person know a projectImprove Quality- Reduce misunderstandings, Reduce missed requirements, Have fewer bugs 31. I expected our scrum adoption to look something like this... SourceI read Mike Cohns book Succeeding with Agile: Software Development using ScrumI taught the team core scrum concepts, I explained the new process to clientsA small team did a pilot project rst, Then the whole group switched 32. But it turned out like this... SourceTeam didnt like it, and clients didnt like it. It felt like just adding a new set of work andprocesses on top of the existing work 33. The Scrum Promise In my Scrum classes I warn attendees of what I call the Scrum Promise: If you adopt Scrum, there will be a day you come into the ofce nearly in tears over how hard the change can be. This is because Scrum doesnt solve problems, it uncovers them and puts them in our face. Then, through hard work we address them. Mike Cohn, Agile TrainerBut what was really going on was that it was bringing previously unrecognized andunarticulated problems to the surface 34. So I brought in a Scrum coach SourceA skilled external coach is often key for driving change - they bring a wide range ofexperience and can see things objectivelyIf youve never led an Agile transition before, its surprisingly easy to do it wrongYou need at least enough management support to pay the coachYou need to make sure youre bringing in someone good 35. Problem #1: false start SourceThrowing people together and calling them a team doesnt make them a team- stepping on each others toes in the code, not familiar with each others projects, someunwilling to share workI misunderstood the roles:- The clients were acting as their own product owners, The scrum masters were our formerproject managers, and continued doing traditional project management- I had several scrum-buts - aspects of our process where we didnt follow scrum and stuckto how we always had worked before 36. Problem #2: too much work9 developers, 2 product owners, and me supporting- 22 clients with 124 applications3 designers and 1 product owner supporting- about 200 static content web sitesTaking inventory itself was a huge undertaking 37. Estimating: story points andplanning pokerPhoto by Kelly HiranoUsed with permission- How did we generate that chart?- The teams give story points to the work by playing planning poker (the work is expressedin a format called user stories)- People are bad at estimating time, but were good at estimating relative size or difficulty- Team based estimates are more accurate than estimates by individuals 38. Velocity enables scheduling andsustainable pace SourceAfter a few sprints, our teams had velocities, which allowed us to make time estimates forprojects.Also gave us a solid basis for not saying yes to every new work request.And this is key to the Agile goal of sustainable pace 39. Problem #3: task switching SourceContext switching between two projects eats about 20% of a full-time workers schedule 40. Problem #4: Misalignment ofauthority and responsibilityCartoon by Mike Lynch Used with permission- Following this advise lets you cover yourself politically, and is a great way to make everyonewho works for you miserable- Ive found that misalignment of authority and responsibility can explain a lot of dysfunctionthat happens in organizations- When you have responsibility for your work but not enough authority over it, you will feellike a cog in machine 41. What makes a job enjoyable? Autonomy Reward for effort Challenging/complex workWork that fullls these three criteria is meaningful. Malcolm Gladwell, Outliers: The Story of Success 42. In the end... Team improved practices, quality, and predictability Attempts to better align authority and responsibility with clients (bymeans of creating an advisory board) failed 43. PracticeMy experiences at ElectNext 44. The team 6 person company -> freedom of action Spread out across 3 cities - meetings are online Team was already doing a couple Agile practices: daily stand-ups andweekly sprints But not other practices -> some confusion around goals andworkow No external clients: designing and sel