| |
|
|
|
|
If you don't know where you're going, any road will do. Chinese Proverb
If you don't know where you are, a map won't help. Watts Humphrey
|
|
|
|
|
|
| |
Thanks Scott Shultz
It's good to see that a little known strategy used by Scott Shultz at Dupont in the 1980's is finally making in roads into all types of methodologies from Dynamic Systems Development Method (DSDM) to XP Programming.
Timeboxing is focused on getting things done within a specified timeframe, i.e. 30 days. It is customer/business focused because it reduces scope and provides a factual artifact.
The heart of timeboxing is delivering on agreed features within a set deadline. The deadline is set in stone.
To get management buy-in, tell them it's Risk Management on Atkin's.
- Achieving a real delivery, however small, affords the team a victory, which improves morale;
- Delivering a certain amount in the fixed period gives everyone feedback on just how fast the team is moving;
- Achieving the timeboxed delivery forces people to stop agonizing over a perfect decision, and has them make a usable decision.
Iron Triangle
Timeboxing acknowledges the schedule is the most important factor and therefore flips the Iron Triangle on its ear to compensate for resources and scope.
Common Project Complaints
They didn't give us enough time.
They didn't let us estimate; they just told us when it was due.
We had to skip most of the system testing in order to deliver on time.
Why Timebox?
- Ensure you deliver on priorities
- Avoid cost and time associated with priorities that have no real payback
- Consensus and buy-in in terms of what actually has to be delivered
Timebox Process Summary
- Customer provides lists of features
- Customer ranks features in terms of Must Have's, Should Have and Nice to Have
- Developers provide estimates
- Customer picks the features
- The only overhead is that design must incorporate subsequent phases!!!
- Project is scheduled into the appropriate number of phases
Art of Timeboxing
You're a project manager. You have too much work to fit into a project (scope) and not enough time to do it. What do you do? Timebox.
Timeboxing is a technique to fit what you can accomplish (some of the scope) into the time you have allotted. Timeboxing works when you have fixed schedule and fix team size, but the feature set is variable. If your users/customers don't help you prioritize the choices, the project team will choose which features to implement.
Agile projects timebox as a matter of course, because they have fixed the people and iteration size, and then decide which features/stories to attack in a particular iteration. Since each iteration is of fixed duration, you only start what you can complete in that iteration, given the number of people you have available to perform the work.
...
Timeboxing is a technique to force the project team to make structured choices about what fits into the product and what doesn't. The team works on one thing at a time, finishing that piece before going on to the next. If you can't figure out how to complete all the work in the available time, and you can't use an agile lifecycle, use timeboxing to force smaller pieces into fixed periods of time.
Johanna Rothman, Art of Timeboxing - March 14 2005
MoSCoW Rules
The Dynamic Systems Development Methodology (DSDM) includes something it calls the MoSCoW Rules, which derives its name from the categories into which its practitioners sort requirements.
I prefer to use the below list to keep customers focused on what really matters.
- M - Must Have - is critical to the system.
- S - Should Have - important but not critical to the system success.
- C - Could Have - Could have but not critical
- W - Won't Have - Won't have this time, but potentially later
Prioritizing Features
For this to truely work you Must Have and I mean Must Have a Senior Analyst / Developer to guesstimate the development time.
| Feature |
Customer Ranking |
Dev. Estimate |
| The system shall allow the paid members to download songs |
Must Have |
3 days |
| allow the paid members to pay for song downloads by PayPal |
Must Have |
4 weeks |
| allow all members to search songs by genre and artist |
Must Have |
1 day |
| allow all visitors to listen to song samples |
Should Have |
2 day |
| list all the songs for a CD |
Should Have |
1 day |
| list recommended songs based on the highest selling CD's |
Could Have |
2 days |
| record and list the top 100 downloaded songs |
Could Have |
2 days |
| Amazon Mashup |
Won't Have |
4 weeks |
Resources
| Article |
Author |
Description |
| Timeboxing For Top Team Performance |
Rick Zahniser |
Provides factual support for Timeboxing and flipping the Iron Triangle on it's ear! |
| Teaching a Goliath to Fly Applying agile methodologies in a large legacy codebase |
Salim Nair, Prasad Ramnath |
This paper describes from a software-architecture perspective, the transformation of a largely waterfall-based development strategy into an agile, test-driven practice.. It looks at the obstacles and difficulties we faced during this change, the way we approached refactoring legacy code to make it testable. |
| Estimating in actual time |
Moses Hohman |
a proposal for an experience report that describes my team's experiences with an estimation scheme that avoids the confusing notion of "ideal" time, uses an appropriate level of granularity for the size of the story, and which acknowledges the uncertainty inherent in estimation. |
| A False Measure of Success |
Richard K Cheng |
This experience report examines the changes in workflow and processes for the web development teams at a major US financial market and the results thereof. The workflow and practices of these web development teams, though not perfect, did satisfy the teams' internal business customer. |
| Rules of Xtreme Programming |
Rick Zahniser |
So what are the Rules of XP? One of the main reasons the three authors have come together from different organization is to validate that the rules apply across a variety of organizations. Each of our organizations have different ways in which we apply these rules. Each of us have been involved in multiple XP projects whose implementations of XP have varied. Lastly, each of us have seen projects which attempted to do XP but fell short in one way or another. |
| What is SCRUM? |
Marc Clifton, J. Dunlap |
SCRUM is a loose set of guidelines that govern the development process of a product, from its design stages to its completion. It aims to cure some common failures of the typical development process such as Chaos due to changing requirements, Unrealistic estimates of time, cost, and quality of the product and Developers are forced to lie about how the project is progressing |
|
|
|
|
|
Previous
