How NOT to Do Scrum. Patterns and Anti-patterns. Revised July First presented at New York City Scrum User Group June 17, 2010

Transcription

1 How NOT to Do Scrum Patterns and Anti-patterns Revised July 2013 First presented at New York City Scrum User Group June 17, 2010 V , 2013 Qualytic Consulting

2 What this is about Patterns Practices that have proved to be generally effective Anti-Patterns Coplien: an anti-pattern is something that looks like a good idea but which backfires badly when applied Schwaber: what used to make you feel safe While Anti-Patterns may not make your Scrum project fail, we value the Patterns more (Context Determines) 2010, 2013 Qualytic Consulting 2

3 LAUNCH (1) Announce: We re going Agile. All teams will do Scrum Start at the C-level, develop a vision, a value stream, and a product roadmap Only when you have those, begin to spin up teams Transfer project managers into ScrumMaster roles. HR changes job titles from PM to SM Send only volunteer project managers to a formal CSM course, then 1) train with teams 2) they shadow an experienced CSM 3) a coach mentors them Remove all cubicle partitions. Move teams into pods Let the teams decide 2010, 2013 Qualytic Consulting 3

4 LAUNCH (2) Let any available product manager or marketing executive be the Product Owner 1) Carefully screen for availability and engagement 2) send to a formal CSPO course 3) coach and mentor Assume there will be a Vision and Product Roadmap Begin immediately to work with the Product Owner. Engage BAs Handle blockages and remove impediments as they come up Begin immediately to identify and eliminate value stream waste and enterprise impediments Look at time-slicing, unclear roles, deployment delays Map the value stream 2010, 2013 Qualytic Consulting 4

5 TRAINING Train everybody immediately If Scrum has been in place, lead a deep-dive retrospective hooks for micro-training on planning, story estimating, practices for high productivity Observe first, talk not new sheriff in town If a green fields transformation, train people just in time as teams are formed and spin up Assume the Product Owner will catch on naturally Train POs (CSPOs) with the teams they will join, then a coach mentors them Separately train POs on vision definition, release mapping, user story writing 2010, 2013 Qualytic Consulting 5

6 SPRINT PLANNING (1) Trust that the Product Owner is doing real capability and release planning Assume the Product Owner will key user stories to capabilities and vision Buyer can display categories ebarn Buyer can display brands Seller can enter descriptions Item List Search Bidding Assume the Product Owner will do continuous backlog grooming Keep after and coach the Product Owner Engage BAs, whole team (READY) 2010, 2013 Qualytic Consulting 6

7 Must-Have for High Productivity -- READY READY Product backlog prioritized on business value Team understands the release plan / roadmap Stories clearly keyed to target capabilities Stories understood by developers and testers Story Syntax Observed Acceptance tests designed Sutherland 2010, 2013 Qualytic Consulting 7

8 SPRINT PLANNING (2) The PO s a list of user stories The Tech Lead decomposes the stories into tasks The SM assigns story owners The Tech Lead estimates the tasks The Tech Lead assigns tasks Result: Zombie teams Enable the team to self-organize 2010, 2013 Qualytic Consulting 8

9 Must-Have for High Productivity Self-Organization SELF-ORGANIZATION Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done Team decides how to achieve goals Collaborates rather than following instructions Reports to itself, not to the PO or SM Sutherland 2010, 2013 Qualytic Consulting 9

10 COMMUNICATION In daily scrums, have the team members report to the ScrumMaster or Product Owner Have them talk to each other (SELF-ORGANIZATION) Let the team sit at their desks for daily scrums and watch their monitors Have physical stand-ups even with distributed teams Skip the daily scrum if the team is really busy Resist tampering with the framework, don t destroy the cadence Have a status meeting every week (Just kidding) Don t do it except 1-on-1 with the sponsor 2010, 2013 Qualytic Consulting 10

11 SPRINTS Vary the sprint length to fit the work planned Maintain a cadence; destroying it disorients the team Keep an open door No project managers -- or anyone else -- disrupt the work of the team Feed them information sprint goal, progress on capabilities Alternate QA test/fix sprints with coding sprints Remember that Defect Cost Increase after 3 weeks = 24 x (DONE) Let the PO change scope at any time Regulate scope churn make the release plan govern sprint scope Use shorter sprint lengths. Keep developers from meeting 1-on-1 with the PO 2010, 2013 Qualytic Consulting 11

12 SPRINTS (2) Put all pending work into the backlog - tasks or intermediate deliverables Put only work resulting in product functionality into your backlog It s Ok to deliver untested software to QA it s their job Deliver only tested software for customer feedback (not necessarily released to end-users) Let developers postpone unit tests to end of sprint Test as you code (preferably do TDD) 2010, 2013 Qualytic Consulting 12

13 Must-Have for High Productivity -- DONE DONE team defines Stories are Closed within a Sprint Feature Complete and Tested Code Complete and Clean No Known Defects Production Ready Approved by the Product Owner Done-Done Sutherland, Cohn 2010, 2013 Qualytic Consulting 13

14 SPRINT REVIEWS Always demo features whether they are complete or not and promise to fix the bugs Let the team know it s safe to fail (DONE) Have only the ScrumMaster or tech lead do the demos Anyone can demo, rotate Put the customer behind the keyboard to run the application 2010, 2013 Qualytic Consulting 14

15 LEADERSHIP Assume your newly-minted CSMs actually know how to lead a sprint Give all CSMs how-to training Buy the best ALM tool right away First establish the framework stay manual for a while if teams collocated - tactile experience and social interaction If teams are distributed, go for an ALM early on, and use it properly Rotate the ScrumMaster role among team members Encourage emergent leadership Just keep the developers writing great code Make sure everybody knows the bigger picture the business purpose of every story, sprint, release 2010, 2013 Qualytic Consulting 15

16 STAKEHOLDERS Assume the Agile sponsor still has the influence he/she had when you came in Stay alert to power shifts. Build and nurture relationships Trust that C-level management knows what you re doing Feed them information on velocity, defects, adoption metrics, impediments, release goals Let them know progress along the roadmap release burndown/up capabilities implemented this sprint, release get maximum face time no status documents Update RTM date estimates after every sprint No more than one shock per release (Cohn) 2010, 2013 Qualytic Consulting 16

17 ENGINEERING Assume adequate infrastructure capacity, speed, availability Sharing servers with other projects => false positives: latency, crashes Get your own DEV, CM, INT, CI, QA environments Hard-code system interfaces Use mock objects Daily builds and continuous integration are very difficult for distributed teams so once a week will be OK SCM: Bazaar, ClearCase, etc. ABM: Cruise Control, Anthill Pro, Hudson Automated testing tools are really difficult to set up so we ll wait a while Automate testing ASAP to enable high productivity UI Service Code 2010, 2013 Qualytic Consulting 17

18 ORGANIZATION Urgent Need: Sr. QA with experience in an Agile Scrum environment Apply for this job QA s often do just manual exploratory / UE testing Manual testers don t easily transition to automated testing Urgent Need: Test Engineers hands-on experience installing and using automated testing tools e.g., can write FitNesse and junit test fixtures A PM of a Tech Lead gets assigned to supervise the work Give the PM useful work to do infrastructure impediments, licenses, ALM tool, stats, risk tracking Put tech leads to work coding 2010, 2013 Qualytic Consulting 18

19 CULTURE We need regular status meetings and reports My CEO wants to see an end-to-end project plan We need complete requirements You haven t defined the end state We need a resource-loaded project plan We need to see actual hours by task and developer When do you assign tasks? Keep information flowing: progress along roadmap, new capabilities, burnup to completed working features 2010, 2013 Qualytic Consulting 19

20 Resistance When anyone isn t following the Scrum framework, point out how benefical Scrum is, be persuasive, run a training session. Escalate. Look at resistance not as a problem to be solved, but as a person to be understood N. Nicholson Fear at the Edge of Chaos Relapse Modes Waterfall Thinking Command and Control Denial of Physical Laws Schwaber 2010, 2013 Qualytic Consulting 20

21 LEARNING Trust that improvement (kaizen) will happen naturally After every sprint, make a list of what went wrong Do a mindful retrospective after every sprint -What we nailed -What we ll avoid next time -What we ll start doing Do a deep-dive retrospective after every release 2010, 2013 Qualytic Consulting 21