Agile Guru Q & A - Collab Guru Q & A March 29, 2013 ... (e.g. Java, not brittle capture/playback ......

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

Transcript of Agile Guru Q & A - Collab Guru Q & A March 29, 2013 ... (e.g. Java, not brittle capture/playback ......

Copyright ©2012 CollabNet, Inc. All Rights Reserved.ENTERPRISE CLOUD

DEVELOPMENT1

Agile Guru Q & A

March 29, 2013

Michael JamesSoftware Process Mentor and Scrum Trainer

Copyright ©2012 CollabNet, Inc. All Rights Reserved.2

www.Collab.Net/AgileTraining

Learn More – Lead Better with Agile TrainingDate Location Trainer Type

Sept. 04-05 Baltimore, MD Gregory Smith, CST Certified Scrum Master

Sept. 04-05 Vancouver, BC Adam Weisbart, CST Certified Scrum Master

Sept. 10-11 Dallas, TX Gregory Smith, CST Certified Scrum Master

Sept. 11-12 San Francisco Jimi Fosdick, CST Certified Scrum Master

Sept. 11-12 Sacramento, CA

Michael James, CST Certified Scrum Master

Sept. 11-13 San Francisco Jimi Fosdick, CST CSM and PMI ACP Prep

Sept. 12-13 Dallas, TX Gregory Smith, CST Certified Product Owner

Sept. 18-19 Salt Lake City, UT

Adam Weisbart, CST Certified Scrum Master

Sept. 23-25 Boston, MA Jimi Fosdick, CST CSM and PMI ACP Prep

Sept. 24-25 Chicago, IL Gregory Smith, CST Certified Scrum Master

Sept. 28-29 New York, NY Michael James, CST Certified Scrum Master

10% off

Use promo code

mjames_guru

13

when you register

Offer valid until 9/30/2013

Plus Many More!

Copyright ©2012 CollabNet, Inc. All Rights Reserved.3

• 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!

Who are we?

Copyright ©2012 CollabNet, Inc. All Rights Reserved.4

See Also: Scrum Reference Card

• http://ScrumReferenceCard.com

Copyright ©2012 CollabNet, Inc. All Rights Reserved.5

• http://ScrumMasterChecklist.org

See Also: ScrumMaster’s Checklist

Copyright ©2012 CollabNet, Inc. All Rights Reserved.6

• http://ScrumTrainingSeries.com• 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.

– email to MJ from Dallas TX, 20 Aug 2012

See Also: Scrum Training Series

Copyright ©2012 CollabNet, Inc. All Rights Reserved.7

• 6 month free retake policy!– Try different instructors

Other Free Stuff

Copyright ©2012 CollabNet, Inc. All Rights Reserved.8

• Q&A

Copyright ©2012 CollabNet, Inc. All Rights Reserved.9

• How do I solicit commitment for definition of "done"?

Write Explicit Definition of “Done” on Each Story

Acceptance Criteria

• 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

* http://blogs.danube.com/junit-is-not-just-for-unit-testing-anymore

Write Explicit Definition of “Done” on Each Story

Acceptance Criteria

• 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

Sprints

Beginner pattern: mini waterfall Sprints.Sp

rint

plan

ning

Sprin

t Re

view

Advanced pattern: do some of everything daily.

Analysis

Design

Code

Test

Development Story X

Implementationand Developer

TestingQA and

AcceptanceTesting

Design

DetailedRequirements

Analysis

Deploy

EverythingElse

Required for"Done"

Copyright ©2012 CollabNet, Inc. All Rights Reserved.13

• What strategy you would suggest to coach a PO who was well aware of scrum and agile but did not believe in the concept of sprint sanctity?

Sprint GoalsShippable Product

Small Team, Clear Goals, Short Iterations

Small, Cross Functional Development Team

Stakeholders

Product Owner

• Time boxing• Team binding*• Impediment Resolution• Cross-functionality• Self-Organization• Protection from

distraction (“wolves”, etc.)

• Clear Acceptance Criteria

* ref: Slack, Tom Demarco** http://en.wikipedia.org/wiki/Flow_(psychology)

possibly leading to ingenuity

Small Team, Clear Goals, Short Iterations

Scrum Team

Sprint Goals

Copyright ©2012 CollabNet, Inc. All Rights Reserved.

• Project budget forecasting under Scrum

* Portions adapted from Agile Estimating and Planning, Mike Cohn, Prentice Hall 2005.

Measuring Progress and Planning

Strategy

Portfolio

Product

Release

Iteration

Day

"In preparing for battle I have always found that plans are useless, but planning is indispensable." - Dwight D. Eisenhower.

• 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...

Sprint Burndown Chart

19

Tracking Sprint Tasks

Estimate Size, Derive Duration

Desired Features

Estimate Size

Derive Duration

Schedule

Adapted from Agile Estimating and Planning, Mike Cohn, Prentice Hall 2005. Used with permission.

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)

Product/Release Burndown Charts

• Height is the work remaining at the start of each Sprint• Takes into account: work completed, added, removed, and re-

estimated

• New work is added below current baseline• Intersections produce a range of likely finish dates• Empirical extrapolation of schedule

Converging Burndown Chart

What If It Doesn’t Converge?

Recommend Product Owner trim release’s scope every Sprint.

Release Burnup Graph

0

20

40

60

80

100

120

140

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Sprint

Stor

y Po

ints

Total SPs

SPs Completed

• 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

Copyright © 2005-2010 Danube Technologies, Inc. Portions used with permission. All Rights Reserved.Copyright © 2005-2010 Danube Technologies, Inc. Portions used with permission. All Rights Reserved.Copyright © 2010 CollabNet, Inc. All Rights Reserved.26

Earned Business Value

0

0.2

0.4

0.6

0.8

1.0

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

• “Earned Business Value” accrued each Sprint• This graph, along with the previous one, tells a story about late

validation.

* http://www.infoq.com/news/2006/12/jeffries-running-tested-features

(Technical Debt is High Cost of Future Change)

Running (and Tested) Features

Robust “done”

Waterfall

Weak “done”

=Technical

Time

Runnin

g (

and T

este

d)

Feat

ure

s

Copyright ©2012 CollabNet, Inc. All Rights Reserved.28

• What is the role of the BA in an Agile project?

Copyright ©2012 CollabNet, Inc. All Rights Reserved.30

• Is it really to have an Agile where more than 100 people?

Common, and Not Recommended

Integration Layer

Layer 1

Layer 2

Layer 3

Layer 4

Layer 5

Teams Separated Along Layers

Group Teams By Related Features

• 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!).

User Interface Layer

Business Logic Layer

Persistence Layer

Team 1

informal working group

Team 2 Team 3

Scaling: Start Small

• 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

+Scaling

Infrastructure

++

1 1 1

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Staging Team Seeds New Teams

• 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.

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Sprint Planning Part 1

Sprint Planning Part 2 Sprint Planning Part 2

Sprint Planning Part 2

Sprint Planning Part 2

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.

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.

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

Product Backlog Item

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

Copyright ©2012 CollabNet, Inc. All Rights Reserved.Copyright ©2012 CollabNet, Inc. All Rights Reserved.38

Thank you!

Collab.Net/AgileTraining

Collab.Net/ScrumTrainingSeries

Webinar: Monthly Agile Guru

Michael James, CST [email protected]