Scaling Software Agility:

Transcription

1 Scaling Software Agility: Best Practices for Large Enterprises Agile 201 Seven Agile Team Practices that Scale 1

2 Seven Agile Team Practices That Scale 2

3 1. Define/Build/Test Team 3

4 Conway s Law Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. Mel Conway (1968) 4

5 D/B/T Team Agile Fractal Agile Fractal a team pattern, repeated at larger scales to produce optimum outcomes Fractal Teams can be based on Features Components, subsystems Interfaces Products Infrastructure Team 1 Team 100 5

6 D/B/T Teams Have the Necessary Skills Define Build Test Define Build Test Define Build Test Define Build Test 6

7 Agile Team Rationale Communication is optimized across disciplines Teams have all disciplines necessary Define build test Bid, elaborate, execute Adjust scope and reprioritize Integrate, test, accept The functional and social network optimized for one purpose To define, design, build and test a potentially shippable increment of software 7

8 High Performing Teams Have the right people on the team Are led and challenged, not managed Understand their mission Communicate and collaborate continuously Are accountable for their results 8

9 Open Environment, Constant Communication 9

10 First Level of Scale Functions/Roles: Release manager Product owner System Integration/QA Architect? 10

11 2. Mastering the Iteration The iteration is the heartbeat of agility. Master that, and most other things agile tend to naturally fall into place. 11

12 Plan Fixed Resources Iteration Pattern Story A Story B Story C Story D Story E Story F Story Fixed Time (Iteration) Define 12

13 Short Iterations Systems are build as increments in short iterations Each iteration is a potentially shippable increment of code Literature counsels lengths of 1 week to 4 weeks Experience has shown that an optimum iteration length is often two weeks More than one week to build real functionality Short enough to limit procrastination Natural calendar cadence 13

14 Iteration Cadence Calendar Routine meeting schedules simplify planning, management, and assessment Iteration planning Daily standup Daily standup Prioritize and elaborate backlog Iteration commitment Define, design, develop, test, accept Demo Retrospective 14

15 Iteration Planning From product backlog to iteration backlog Login portal Display minutes Support ticket call Remote login help Update profile Buy more time Single sign-on Log rotation Timer display Automatic logout Usage warning Courtesy Trailridge Consulting, LLC 15

16 Starts with a Goal A short theme or objective for the iteration often increases clarity and commitment Provided by Product Owner Finalize new UE to match design Validate across all browsers Prepare for drop to Alpha customer 16

17 Iteration Planning Meeting Goal: Create a committed iteration plan Objectives defined and stories backlog prioritized prior to meeting Process: Take the highest priority story Identify all tasks - take responsibility, team decides Estimate each task Repeat until full Guidelines The whole team < 4 hours Estimate tasks collaboratively in hours 17

18 Iteration Planning 18

19 Team Commitment If you ask a team to choose items from a (prioritized) list what the members believe they can do in a short time-box, the team will probably choose and commit to a reasonable set of features Once the team members have committed to a set of features that they think they can complete, they will probably figure out how to get those features done within the time-box Mary Poppendiek Lean Software Development But commitments are reciprocal Team commits to delivering functionality Business commits to leave priorities alone for THAT iteration 19

20 Delivering on the Commitment Team self-manages completion, interdependencies, issues Team can add, delete or change tasks as necessary But stories generally unchanged Teams swarm where necessary to complete higher priority stories Team re-estimates work remaining daily 20

21 Track Iterations at the Story Level Simple Visual Status Kanban 21

22 Iteration Status with Burndown Charts Courtesy Trailridge Consulting, LLC 22

23 With Tooling Automation 23

24 Visibility with Daily Standups 15 minute meeting - same time and place every day; the team decides when ALL team members participate Everyone stands up; no problem solving 15-minute time box; 1 to 2 minutes per report, start and stop on time Three comments: What I did yesterday What I plan to do today What blocks or impediments I face THIS IS NOT SCRUM MASTER STATUS It is peer commitments and communication Meet After keep only needed participants for design and problem solving Attendance and length varies daily 24

25 End of Iteration Review and Demo Demonstration of all stories to key stakeholders (in and outside team) Occurs each and every iteration Acceptance (or not) of each story Acceptance (or not) of the entire iteration 25

26 Iteration Retrospective What is it? Review of the team & process Review of impediments Guidelines minutes After every iteration Whole team participates Three Questions What should we stop doing? What should we start doing? What should we continue doing? 26

27 3. Two-Level Planning and Tracking There have been countless ambitious but doomed attempts to plan large software projects from start to finish in minute detail, as you would plan the construction of a skyscraper.... In an iterative process, we recommend that the development be based on two kinds of plans. A coarse-grained plan: the phase (release) plan A series of fine-grained plans: the iteration plans So, in agile methods, the investment in long-range (longer than one or two iterations), speculative plans is reduced, and the lack of precision and accuracy in such plans is acknowledged. Release plans, therefore, are intentionally coarse-grained, less comprehensive, and less precise Kruchten,

28 Two Level Planning and Tracking Product & Release Cycle Release Vision Drives Release Planning Release Scope and Boundaries Iteration Cycle Iteration Planning Feedback - Adjust Review & Adapt Develop & Test 28

29 Two Levels of Planning Plan Releases at the System Level Three to six months planning horizon Release theme sets overall objective Prioritized feature sets define proposed/estimated content High visibility and confidence near term (Release next and next+1 ). Lower visibility longer term Plan Iterations at the Component/module/feature Level 4-6 weeks planning horizon Define story cards and tasks for next 1-2 iterations Adapt and adjust at each iteration 29

30 Planning at Scale Release plan at system level System Fea1 Fea2 R1 Fea3 Fea4 R2 stories Requirements pyramid

31 Plan Fixed Resources Iteration Pattern Story A Story B Story C Story D Story E Story F Story Fixed Time (Iteration) 31

32 Release Pattern Stories Release timebox 32

33 Iteration Planning is a Routine Event Happens at iteration cadence boundary (2 weeks) Can be done under local authority of team Subject to collaboration with other component teams Consumes ½ to 1 day of every iteration cycle Priorities and objectives driven by Product Owners 33

34 Release Planning is a Big Event A full day (or two for larger teams) for every release Most everyone attends in person if at all possible Product Manager owns the feature priorities Development team owns story planning and high-level estimates Architects work as intermediaries for governance, interfaces and dependencies Adequate logistics and facilitation Big room with lots of whiteboard space Break-out rooms for multiple teams Preview- Agile at Scale 34

35 Track Releases at the Feature Level 35

36 4. Smaller, More Frequent Releases Shorter release dates days Releases defined by Date, theme, planned feature set, quality Scope is the variable Release date and quality are fixed 36

37 Benefits Rapid customer feedback reduces waste Earlier value delivery against customer s highest needs Frequent, forced system integration improves quality and lowers risk Low cost to change Accepts new, important customer features Reprioritize backlog at every iteration & release Reduced patching headaches It s only X days the next release, that feature can wait Or easy, high-confidence patching Smaller increments for higher productivity Leaner flow through the entire organization to customer 37

38 Fix the Dates - Float the Features 9/24/ /1/ /1/ /1/2006 1/1/2008 2/1/2008 3/1/2008 3/25/2008 Teams learn that dates MATTER Product owners learn that priorities MATTER Agile teams MEET their commitments 38

39 Organizing Release Backlog Courtesy BMC Software, Inc. Time 39

40 Communicating Expectations 40

41 Delivering Customer Agility New requirements can be added in real-time Do not get stuck in the backlog Certain features get demoted to backlog Customer gets the release in 3-4 months max Courtesy BMC Software, Inc. 41

42 5. Concurrent Testing Philosophy of Agile Testing All code is tested code. Teams get no credit for delivering functionality that has been coded, but not tested Tests are written before, or concurrently with, the code itself Testing is a team effort. Testers and developers all write tests Test automation is the rule, not the exception 42

43 Concurrent Testing Early and continuous testing is mandatory Because the system is developed in short, workable increments of functionality: various kinds of testing that used to be deferred until delivery must now be immediate Forces a test early and often cycle which becomes integral to the iteration process The programmers and testers write and execute tests as they write the code Learn valuable lessons sooner Peer review of program logic Risks are discovered and addressed earlier Quality is improved We can t accept a story we can t test 43

44 Concurrent Unit Testing Developer written Acceptance Testing Customer, product owner, tester written Component Testing Integrated BVT (Build Verification Tests) at component/module/feature level System, Performance and Reliability Testing Systems Tester and Developer Written QA Involvement It is unit tests that keep our code flexible, maintainable, and reusable The test code is important as the production code Test enable the ilities Robert Martin Clean Code 44

45 Patterns: The Practical World The iteration goal is to have tested and accepted software at the end of every iteration But automation of testing may lag by one or more iterations Over time: the set of accumulated functional test cases + system level and performance test cases serve as full regression tests for iteration and release The release goal is to execute a full suite of release level acceptance testing, full regression and system and performance testing in less than one iteration Often, a typical release pattern develops 45

46 On Test Automation You have no choice Manual tests bottleneck velocity You can t ship what you can t test 46

47 Test Driven Development (TDD) For each new story: 1. First, write the test 2. Run the test and watch it fail a. Test the test itself and test harnesses that hold the test in place b. See how the system will fail if the code is incorrect 3. Write the minimum amount of code that is necessary to pass the test 4. If the test fails, refactor code & test as necessary until the module routinely passes the test 47

48 6. Continuous Integration Continuous integration is neither new nor invented by agile It has been applied as a best practice for at least a decade However, continuous integration is mandatory with agile 48

49 The Problem of Discontinuous Integration 49

50 Three Steps of Continuous Integration The system always runs Source Code Integration Automated Build Management Automated Build Verification test 50

51 Continuous Integration Model Kevin Lee, IBM Rational

52 Teams develop locally Code is checked in to repository Integrate daily System integrate at least weekly Courtesy Trailridge Consulting, LLC 52

53 Continuous Integration Success Team can build at least once a day Effort is inversely proportional to time between builds! A broken build stops production and is addressed immediately Successful builds Checks in all the latest source code Recompile every file from scratch Successfully execute all unit tests Link and deploy for execution Successfully execute automated Build Verification Test Martin Fowler 53

54 Memo from an XP shop The XP environment provides us with many benefits, not the least of which is the incredible pace of progress we are so proud of. Lately we have had a rash of build failures, some related to infrastructure issues, but more related to carelessness. Broken builds destroy the heartbeat of an XP team. Each of you has a primary responsibility to ensure that this doesn t happen... but here are a few tips to ensure that you aren t the one who broke the build: Write your test cases before you write the code Build and test the code on your desktop BEFORE you check it in Make sure you run all of the cases that the build does Do not comment-out inconveniently failing unit tests. Find out why they are broken, and either fix the test or fix your code If you are changing code that may affect another team, ASK before you check it in Do not leave the building until you are SURE your last check-in built successfully and the unit tests all ran The Build master is there to make sure that broken builds get addressed, not to address them. The responsibility for a broken build is yours. Breaking the build will have an affect on your standing within the team and, potentially, your review, so let s be careful out there. 54

55 7. Regular Reflection and Adaptation At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile Manifesto, Principle 12 Periodically, the entire team including owners/end users reflects on the results of the process learn from that examination adapt the process - and organization - to produce better results The team decides what to keep doing, what to stop doing, and what to do differently next time 55

56 Retrospective What is it? Review of the team & process Review of impediments Guidelines minutes After every iteration Whole team participates Three Questions What should we stop doing? What should we start doing? What should we continue doing? Courtesy Trailridge Consulting, LLC 56

57 Sample take-aways Move the daily build to 4 PM so we know it works before we leave for the day Buy a bigger file server to reduce build times We missed on the stories that were not previewed in advance of the iteration Our CM environment &^*#$% Testers weren't able to start early enough we can t drop all the code on the next to the last day of the iteration We underestimated the technical risk of Product owners need to live with us 57

58 END AGILE