Bits 'n Widgets
Thoughts on real-world, practical, common-sense approaches to Agile software development using Scrum and XP
Monday, January 26, 2009
« Estimation, Wideband Delphi, and the Con...
|
Main
|
Agile Developer Series - Video - What ma... »
Transparency
One of the large benefits of agile teams should be the transparency to see how things are going at any given time. A team typically has a burn-down chart that shows daily (or more frequent) updates to tasks and stories. This chart is a key to seeing if the team is on-target for delivering what it committed to at the beginning of the sprint. Sometimes the estimated time remaining actually goes up, indicating that delivery will be delayed. This information is critical in trying to manage a project. Problems with delivery are part of the software development game, and should be visible so they can be mitigated.
If we see a trend either flat or upward in the burn-down chart (burn-up as it's called), we should be able to react to this information by talking with team members about what is preventing progress from being made. We can take a variety of actions to address impediments - cut stories, re-focus other team members to swarm on tasks, and other things to try to get back on track making progress toward delivery. However, if we don't have the rapid feedback of the burn-down chart, it's hard to see what the current status of the project is. This chart is the heartbeat of the project.
Team members should do their best to estimate stories and tasks, but as we all know, estimation is usually less accurate at the beginning of a task. When we know more, we should be updating the task estimates for time remaining. Using tools like Rally, Scrumworks, or other products, the work and time it takes each team member to add new tasks and change the time remaining estimates should be minimal and manageable. Make sure to remind team members how important it is to keep the tasks up to date on at least a daily basis.
As an agile team, we should be able to see where we are at all times. This information ideally should even be radiated real-time in the team space so everyone can see how things are going - even the casual passer-by. Problems should never be hidden. Problems always come up, and they get solved not by secrecy, but by publicity. The more minds we have on solution, the faster problems can be resolved. We should never look at problems or impediments as either personal or team failures, quite the opposite in fact.
The team should always be able to see how it is doing, and a good self-directing team will notice its own burn-down impediments and re-focus itself on solving the issue without outside help. Newer teams may need the assistance of a scrum master to call out impediments, but the team should still be responsible for addressing its own issues. Only in personnel or political issues should "management" be brought in to assist with solution. If there are roadblocks, the team should be able to call on the scrum master to assist in bringing in anything needed from outside the team.
Once a team really understands the real power of task breakdown and continuous update of time remaining, they can gauge themselves on their own progress and what needs to be done to address anomalies, avert crisis, and succeed at delivering their commitments.
Team
Monday, January 26, 2009 11:07:49 AM (Pacific Standard Time, UTC-08:00)
Disclaimer
|
Comments [0]
|
Trackback
Related posts:
Planning, Estimation, and Load Factor
Making Differences Work on an Agile Team
Pair Programming - A Guideline
Automated Acceptance Tests - Who Should Write Them, Dev or QA?
Become a Certified Agile Developer!
#region is a Code Smell.
Comments are closed.
On this page....
Archives
<
March 2010
>
Sun
Mon
Tue
Wed
Thu
Fri
Sat
28
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
1
2
3
4
5
6
7
8
9
10
September, 2009 (3)
April, 2009 (1)
February, 2009 (2)
January, 2009 (1)
December, 2008 (1)
November, 2008 (1)
October, 2008 (1)
September, 2008 (4)
August, 2008 (4)
July, 2008 (4)
June, 2008 (2)
May, 2008 (7)
April, 2008 (3)
March, 2008 (1)
Total Posts: 35
This Year: 0
This Month: 0
This Week: 0
Comments: 21
Search
Navigation
Agile FAQ
Agile Alliance
Agile Manifesto
Extreme Programming
Test Driven Developer
Test Driven Development, Defined (Wikipedia)
Test Driven Design
Test-Driven.com - Agile development tools
NUnit
Book: Test-Driven Development in Microsoft .NET
CodeProject - Advanced Unit Testing: Unit Test Patterns
John Boal's Personal Blog
John Boal's Agile Development Blog
Tags
ABN (3)
Acceptance Testing (2)
Agile (3)
bugs (2)
Design (3)
DSL (1)
Estimation (1)
Lean (1)
Pair Programming (1)
Refactoring (1)
scrum (10)
Security (2)
source control (1)
TDD (3)
Team (12)
testing (5)
User Interface (2)
Categories
ABN
Acceptance Testing
Agile
bugs
Design
DSL
Estimation
Lean
Pair Programming
Refactoring
scrum
Security
source control
TDD
Team
testing
User Interface
Blogroll
#2782
Ade Miller's Tech Blog
Agile Development
Mitch Lacey's Agile Development Blog
Agile FAQ
Frequently Asked Agile Questions - Vibhu's Blog
Espresso Fueled Agile Development
Mike Puleio's Blog
Geek Noise
Noise de Peter Provost
About
© Copyright 2010, John E. Boal
E-mail
Sign In