Agile Guru Q & A - Collab Guru Q & A March 29, 2013 ... (e.g. Java, not brittle capture/playback ......
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.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
* 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
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
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]