MYTHBUSTERS. Is what we hear about Agile fact or fiction? Rowan Bunning. au.linkedin.com/in/rowanbunning

Transcription

1 MYTHBUSTERS Is what we hear about Agile fact or fiction? Rowan Bunning au.linkedin.com/in/rowanbunning

2 Fact or fiction? 1. Agile is a specific methodology 2. A Product Owner is like an agile Business Analyst 3. A ScrumMaster is just like an Iteration Manager or Project Manager 4. An "Epic" is always a really big User Story 5. Acceptance Test Driven Development is only for testers 6. Timeboxes create regular milestones

3 Fact or fiction? 7. A good Iteration Review is about project status and a demo 8. The daily stand-up is primarily a status update 9. Agile doesn t involve any sort of micromanagement 10.Agile means we don't work to a fixed release date 11.Agile should not be used for high risk projects 12.Agile is for IT project teams and does not affect anyone else

4 Agile is a specific methodology Fact or fiction?

5 Where did this Agile thing come from anyway? Agile Scrum extreme Programming DSDM Crystal Feature Driven Development Adaptive Software Development

6 Agile is a specific methodology Agile was coined as an umbrella term for several specific methods sharing common values and principles. Agile as a methodology usually refers to a custom/proprietary mashup.

7 A Product Owner is like an agile Business Analyst Fact or fiction?

8 Some Product Owner responsibilities Maximise the value of the work the Team does. Decide when to release to customer(s). Own the product vision and ensure that everyone involved is engaged with it. Establish goals necessary to optimise the Return On Investment including what, for whom and why. Manage the budget necessary for the work of the team to occur....and lots more!!!

9 A Product Owner is like an agile Business Analyst A Product Owner is a business decision-maker.

10 A ScrumMaster is just like a Project Manager or Iteration Manager Fact or fiction?

11 Where did the Iteration Manager come from? When teams were struggling to find high-priority work to do on one particular project in 2000, the solution was to identify someone who could provide a continual stream of high-priority functionality at a sustainable pace to the delivery teams. This is the role that has grown into the iteration manager (IM). - What Is an Iteration Manager Anyway?", Tiffany Lentz, The ThoughWorks Anthology, The split between release and iteration managers reflects the style and preferences of the two individuals that do it... We don't think our solution is one that necessarily everyone should follow. -

12 Iteration Manager "The iteration manager role, while not prescriptive, entails several daily responsibilities. Some of these are as follows: - Collects time spent on stories - Makes bottlenecks in the delivery process visible - Reports team status to the customer - Addresses issues, impediments, and obstacles raised at the daily stand-up meeting - Controls all work flowing into the team and manages the distribution of that work to maintain a sustainable pace" - What Is an Iteration Manager Anyway?", Tiffany Lentz, The ThoughWorks Anthology, 2008.

13 Project Management as a shared activity Thanks to: our new Certified ScrumMasters in Perth!

14 Separation of concerns Stakeholders What ROI Delivery How Users Develop the right thing SM Develop the thing right Health Process Facilitation Management

15 A ScrumMaster is just like a Project Manager or Iteration Manager The ScrumMaster role is not limited to managing iterations. A ScrumMaster does not act as a connector, not a pipe and supports the team in deciding work distribution etc. With Scrum, Project Management is an activity shared by all three roles.

16 An "Epic" is always a really big User Story Fact or fiction?

17 An "Epic" is a really large User Story An Epic is simply a story that is too big for an iteration.

18 Acceptance Test Driven Development is only for testers Fact or fiction?

19 Acceptance tests help bridge the communication gap Product Owner Management Stakeholders Value driver Feature User Story, Acceptance Criteria, Acceptance Tests Plannable Unit of work Requirement Business Analysts Users Something that would help me Boundary Object A way for communities with different interests to have a conversation with each other Functionality Developers ScrumMaster Backlog item Functionality with boundary conditions Testers Thanks to: Jeff Patton

20 Acceptance Test Driven Development using FitNesse Customer level Shopping cart total Order price? Gold $49.95 $49.95 Gold $50.00 $42.50 Gold $50.05 $42.54

21 Acceptance Test Driven Development is a practice for testers ATDD provides a way for all parties to collaborate on the details of user stories.

22 Timeboxes are about creating regular milestones Fact or fiction?

23 We create iterations within a milestone period Inspect & Adapt Point Inspect & Adapt Point Inspect & Adapt Point High stakes Milestone Iteration N Iteration N+1 Iteration N+2 Iteration N+3

24 Timeboxes contain risk and help us move to Safe fail

25 Timeboxes are about creating regular milestones Timeboxed iterations are an artificial construct that we create within a broader milestone period.

26 A good Iteration Review is about project status and a demo Fact or fiction?

27 It s not just inspecting, it s adapting too During the Sprint Review, the Scrum Team and stakeholders collaborate about what was just done. Based on that and changes to the Product Backlog during the Sprint, they collaborate about what are the next things that could be done. This is an informal meeting, with the presentation of the functionality intended to foster collaboration about what to do next. Source: The Scrum Guide.

28 Avoid smoke and mirror demos Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes....when someone inspecting a process believes that something is done; it must be equivalent to their definition of done. - Ken Schwaber, The Scrum Guide

29 A good Iteration Review is about project status and a demo A good review goes beyond status, beyond a demo, beyond feedback to... implications and decisions for the product going forward.

30 The daily stand-up is primarily a status update Fact or fiction?

31 What is the daily standup for anyway? Co-ordination Self-organisation Optimising the team s path through the work You don t do all this just by talking about the past and impediments! The Daily Scrum should probably be called the Daily Planning meeting because that s what it is primarily about. - Joseph Pelrine

32 Part of the planning onion Strategy Portfolio/Initiative Product/Project Release Sprint Many years Years Many months 2-9 months 2-4 weeks 24 hrs Daily Scrum

33 The daily stand-up is primarily a status update The daily standup is primarily about planning the next 24hrs.

34 Agile doesn t involve any sort of micromanagement Fact or fiction?

35 Does agile involve micro-management? Ye s!!! But not like this --> Who is doing the micro-managing?

36 Agile doesn t involve any sort of micromanagement The team micro-manages itself... assuming conditions are conducive to self-organisation.

37 Agile means we don't work to a fixed release date Fact or fiction?

38 Pick three! Scope Quality Resources Time We can constrain three and then actively manage the other to optimise returns.

39 Flipping the iron triangle Tradit ional Agile Constraints Scope Cost Schedule Plan Driven Value / Vision Driven Estimates Cost Schedule The plan creates cost/schedule estimates Scope The vision creates feature estimates Source: Slinger, M., Broderick, S., The Software Project Manager s Bridge to Agility, Addison Wesley, 2008.

40 Doing better than project success Which would you rather have: your initial feature set, or a successful product? - Joseph Pelrine Project success is not product success - Jeff Patton

41 Agile means we don't work to a fixed release date We can work to fixed time and cost constraints if scope (breadth and/or depth) is flexible.

42 Agile should not be used for high risk projects Fact or fiction?

43 Waterfall and tackling risk Requirements Analysis Design Code Integrate & System Test First build and deliver Potential Impact of Risks being tackled Highest risk activities such as integration, system testing, load testing are tackled late Time Source: Larman, C., Agile & Iterative Development, 2004.

44 Agile and tackling risk First build and deliver Iterations All activities are tackled early Potential Impact of Risks being tackled Integrate & System Test Code Integrate & System Test Code Integrate & System Test Code Integrate & System Test Code Integrate & System Test Code Design Design Design Design Design Analysis Analysis Analysis Analysis Analysis Time Source: Larman, C., Agile & Iterative Development, 2004.

45 Tackling complexity 0.9 Probability of success 0.5 Defined Increased probability of success Empirical Flexible response to unpredictability improves Success to Complexity relationship 0.1 Low Medium High Complexity

46 Risk reduction using Scrum Risk of... Not pleasing the customer Not completing all functionality Scrum Strategy Customer sees product constantly. Customer on-site. Develop in priority order. Poor estimating and planning Small estimates tracked daily. Review and adjustment every iteration. Not resolving issues properly Not being able to complete the development cycle Taking too much work and changing expectations Active daily management. Bi-directional reporting. Delivery of working software every iteration. Team forced to confront issues early. Clear goal and scope each iteration. No change within iterations. Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.

47 Agile should not be used for high risk projects Agile offers strategies for systematically tackling many of the biggest risks early.

48 Agile is for IT project teams and does not affect anyone else Fact or fiction?

49 Transformat ional Salesforce.com saw that Scrum involved not just the adoption of a new business process, but rather as a fundamental transformation of the way work was managed in the company. They were introducing a new way of thinking, speaking and acting in the workplace for both managers and workers. Source: Six Common Mistakes That Salesforce.com Didn t Make, April 18, 2011, Forbes.com:

50 Agile is for IT project teams and does not affect anyone else When fully realised, Agile can be a blueprint for a different sort of organisation.

51 It s a paradigm shift We can t solve problems by using the same kind of thinking we used when we created them. - Albert Einstein

52 The executive business case for Agile

53 Win your agile game! Accreditation courses: Certified ScrumMaster Certified Scrum Product Owner Definitive Agile courses: Effective User Stories Agile Estimating & Planning Succeeding with Agile Agile coaching & consulting: Agility assessment Organisational change consulting Agile kickstart workshops Agile planning preparation and facilitation ScrumMaster and Product Owner coaching Agile Team coaching Retrospective facilitation Advice on agile tool selection Rowan Bunning au.linkedin.com/in/rowanbunning