Agile Guru Q & A. Michael James Software Process Mentor and Scrum Trainer. March 29, 2013 ENTERPRISE CLOUD DEVELOPMENT 1

Size: px

Start display at page:

Download "Agile Guru Q & A. Michael James Software Process Mentor and Scrum Trainer. March 29, 2013 ENTERPRISE CLOUD DEVELOPMENT 1"

Jason Hines
6 years ago
Views:

Learn More Lead Better with Agile Training Date Location Trainer Type Sept. 04-05 Baltimore, MD Gregory Smith, CST Certified Scrum Master Sept.

11-12 San Francisco Jimi Fosdick, CST Certified Scrum Master Sept. 11-12 Sacramento, Michael James, CST Certified Scrum Master CA Sept.

18-19 Salt Lake City, Adam Weisbart, CST Certified Scrum Master UT Sept. 23-25 Boston, MA Jimi Fosdick, CST CSM and PMI ACP Prep Sept.

2 Learn More Lead Better with Agile Training Date Location Trainer Type Sept Baltimore, MD Gregory Smith, CST Certified Scrum Master Sept Vancouver, BC Adam Weisbart, CST Certified Scrum Master Sept Dallas, TX Gregory Smith, CST Certified Scrum Master Sept San Francisco Jimi Fosdick, CST Certified Scrum Master Sept Sacramento, Michael James, CST Certified Scrum Master CA Sept San Francisco Jimi Fosdick, CST CSM and PMI ACP Prep Sept Dallas, TX Gregory Smith, CST Certified Product Owner Sept Salt Lake City, Adam Weisbart, CST Certified Scrum Master UT Sept Boston, MA Jimi Fosdick, CST CSM and PMI ACP Prep Sept Chicago, IL Gregory Smith, CST Certified Scrum Master 10% off Use promo code mjames_guru 13 when you register Offer valid until 9/30/2013 Sept New York, NY Michael James, CST Certified Scrum Master Plus Many More! 2 Copyright 2012 CollabNet, Inc. All Rights Reserved.

3 Who are we? Michael James (MJ) is a Scrum team member, Software developer for many years, Scrum trainer/coach Reading advocate. What is the webinar? Sound check: If you cannot hear any webinar audio by now, something is wrong with your settings! 3 Copyright 2012 CollabNet, Inc. All Rights Reserved.

See Also: Scrum Training Series http://scrumtrainingseries.

6 See Also: Scrum Training Series I learned more about Agile in that [online] training than all of the "on the job" stuff I've learned, which is basically misinformation on Scrum. How true the statement most companies "using Scrum" are using not much more than the name. to MJ from Dallas TX, 20 Aug Copyright 2012 CollabNet, Inc. All Rights Reserved.

10 Acceptance Criteria Write Explicit Definition of Done on Each Story Business Criteria often forgotten degree of feature richness usability performance timing, scalability, reliability, etc. cross-cutting concerns compliance with corporate integration needs external regulations (i.e. legal) whether/when regression failures allowable

11 Acceptance Criteria Write Explicit Definition of Done on Each Story Example engineering criteria to prevent Technical Debt pair programming, code/design review manual test automated test coverage unit tests system tests prefer same language (e.g. Java, not brittle capture/playback or proprietary scripting languages) refactoring changing internals without changing behavior incrementally remove duplicate code, business logic in your presentation layer (JHTML, JSPs, etc.), complex conditional logic, poor naming, obsolete libraries... impractical without automated test *

12 Sprints Beginner pattern: mini waterfall Sprints. Analysis Design Sprint planning Code Advanced pattern: do some of everything daily. Development Story X Design Test Implementation and Developer Testing QA and Acceptance Testing Sprint Review Detailed Requirements Analysis Deploy Everything Else Required for "Done"

14 Small Team, Clear Goals, Short Iterations Small, Cross Functional Development Team Product Owner Shippable Sprint Product Goals Stakeholders

15 Small Team, Clear Goals, Short Iterations possibly leading to ingenuity Time boxing Team binding* Impediment Resolution Cross-functionality Self-Organization Protection from distraction ( wolves, etc.) Clear Acceptance Criteria Scrum Team Sprint Goals * ref: Slack, Tom Demarco **

17 Measuring Progress and Planning Strategy "In preparing for battle I have always found that plans are useless, but planning is indispensable." - Dwight D. Eisenhower. Portfolio Product Release Iteration Day * Portions adapted from Agile Estimating and Planning, Mike Cohn, Prentice Hall 2005.

18 Sprint Burndown Chart Daily summation of work remaining in Sprint Often goes up before it goes down Useful for team, not upper management Please don t draw trendlines here...

19 Tracking Sprint Tasks 19

20 Estimate Size, Derive Duration Desired Features Estimate Size Derive Duration Schedule Adapted from Agile Estimating and Planning, Mike Cohn, Prentice Hall Used with permission.

21 Velocity Measure of a team s rate of progress per iteration Number of Story Points completed per Sprint Velocity can be used to derive duration and extrapolate schedule Estimating Velocity: Use historical values. We prefer empirical methods! Run an iteration. Make a forecast. (last resort)

22 Product/Release Burndown Charts Height is the work remaining at the start of each Sprint Takes into account: work completed, added, removed, and reestimated

23 Converging Burndown Chart New work is added below current baseline Intersections produce a range of likely finish dates Empirical extrapolation of schedule

24 What If It Doesn t Converge? Recommend Product Owner trim release s scope every Sprint.

25 Release Burnup Graph Story Points Total SPs SPs Completed Sprint Top Line is the Product Backlog size at the beginning of each Sprint See the scope creep? Bottom Line is work done to date Note the nearly constant velocity

26 Earned Business Value Earned Business Value accrued each Sprint This graph, along with the previous one, tells a story about late validation. 26 Copyright Danube Technologies, Copyright Inc CollabNet, Portions used Inc. All with Rights permission. Reserved. All Rights Reserved.

27 Running (and Tested) Features Running (and Tested) Features (Technical Debt is High Cost of Future Change) Robust done =Technical Weak done Waterfall Time *

31 Teams Separated Along Layers Common, and Not Recommended Integration Layer Layer 1 Layer 2 Layer 3 Layer 4 Layer 5

32 Group Teams By Related Features Team 1 Team 2 Team 3 User Interface Layer Business Logic Layer Persistence Layer informal working group One code base with continuous integration Informal dotted line working groups span teams as necessary to fend off technical debt, co-ordinate integration (early and often!).

33 Scaling: Start Small Scaling Infrastructure Single Product Owner and Product Backlog Start with a single Staging team Team prepares for scaling by building real product, establishing continuous integration and TDD practices, etc. Team decides when it is ready to scale, if necessary

34 Staging Team Seeds New Teams Sprint Planning Part 1 Sprint Planning Part 2 Sprint Planning Part 2 Sprint Planning Part 2 Sprint Planning Part 2 Original staging team members (workers, not only managers) seed new teams One single integrated product increment each sprint Each team needs a ScrumMaster, especially in the beginning.

35 Example Scaled Planning Meeting In the morning, original seed team tentatively commit sensible PBIs to the Sprint with PO, just as they did in Sprint Planning Part 1 when they were the only team. In some cases seed team may involve PO in tentative plan of which spawned teams will do which items. In the afternoon, seed team members involve the spawned teams in task breakdown, often on separate taskboards. PO remains available for clarification or renegotiation. One large conference room subdivided for multiple teams is ideal. Final thumbs up from all team members at end of day commits the Sprint goals.

36 Alternative: Multiple Virtual Products Treat each team s effort as a virtual product even when they are a single product from a marketing and build perspective. Separate backlogs. Separate planning and review meetings. One Product Owner can handle about three teams, or uber Product Owner can delegate to team Product Owners in traditional hierarchy.

37 Scaling: Integration is Difficult It must all come together as a single product increment. Try to integrate as often as possible, avoid big-bang integrations. Each team integrates as often as possible, optimally this is continuous on check-ins. Bugs produced by check-ins/integrations should be discrete enough such that the source should be easily identifiable. The more continuous your integration, the easier it is to identify the source of bugs Daily builds are for wimps - Kent Beck

Scrum - Introduction. Petri Heiramo. Agile Coach, CST

Scrum - Introduction. Petri Heiramo. Agile Coach, CST Scrum - Introduction Petri Heiramo Agile Coach, CST Scrum Started in the Harvard BR. The relay race approach to product development may conflict with the goals of maximum speed and flexibility. Instead