RE: [scrumdevelopment] Dynamic Scrum
MessageI think this is why a 30-day Sprint also works best for most. It allows us technical people to reallyconcentrate on what we are doing.As developers/architects/programmers *we strongly value* the time that people allow usto have for technical work. Although we value planning, tracking, estimation, customer interaction,developers interaction, testing, integration, release management, etc.; we don't want to be interruptedor distracted from our technical work so often that it makes it impossible to complete quality work,- MikeRobert Henley wrote:
Speaking for myself, I find it hard to interrupt thinking through a complex
issue. There is an intense focus involved in wrapping my head around a
problem. I find it very hard to shift gears, and generally it costs me
significant time and
extra work when I have to do so and then go back to the work later.
working through such an issue in the code takes me several days.
I find it similar when a feature is partly done, but not completely working,
during complex debugging. Those are times when stopping on a dime means
tossing what's in progress rather than carrying it through. Maybe I can
resurrect my work later, but most likely I have to recreate the thought
process that brought me to the point where I left off, and that costs
I prefer the stability Scrum provides for this, except in unusual
when an Abnormal Termination is called for and work must be discarded.
So I disagree that incomplete rewrites can be stopped without cost or "wait
indefinitely to be plugged in." At least not by me.
Certified Scrum Master
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
- Out of curiosity, does anyone's sprint length vary
due to the length of a contract? i.e. If you
ran a 3 month contract, would you stick with 3
sprints, or use 6.
Or does most of the discussion on sprint length apply
to product scale development, where the durations
might be 6 months to 2 years? I assume that there
would be minor variance in sprint lengths in either
On Wed, 2004-03-03 at 19:12, Mike Beedle wrote:
> I think this is why a 30-day Sprint also works best for most. It
> allows us technical people to really
> concentrate on what we are doing.
> As developers/architects/programmers *we strongly value* the time that
> people allow us
> to have for technical work. Although we value planning, tracking,
> estimation, customer interaction,
> developers interaction, testing, integration, release management,
> etc.; we don't want to be interrupted
> or distracted from our technical work so often that it makes it
> impossible to complete quality work,
> - Mike
- Bradley Singletary wrote:
> Out of curiosity, does anyone's sprint length varyI operated a 10-week contract this way: 3x2 weeks, then 4x1 week. As we
> due to the length of a contract? i.e. If you
> ran a 3 month contract, would you stick with 3
> sprints, or use 6.
got closer to the end, we increased the rate of delivery and feedback so
that the customer could steer more precisely. We did this mainly in
response to the fact that we were not going to deliver everything we
expected to deliver and we wanted the client to have maximum flexibility
for choosing the last four weeks' worth of features.
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand
- In my previous not on "Dynamic Scrum" it may not have been apparent how we handle loose ends, how the product owner manages the sprint backlog, and other features that deal with a multitude of issues raised yesterday on the list, in a completely transparent way.
1. Any issue an any time can be entered by anyone into our Scrum tracking system. I have worked hard to keep this totally open. If anyone bitches from the field they are not getting something they need, they are asked where are their entries in the Scrum tracking system. It they are not there, they are told to stop bitching and start using the system. If they object to priorities, they are told to work it out with the product owner who owns the priorities. This has eliminated a huge amount of noise.
We use the open source GNATS bug tracking system modified with a very few extra fields for this. So it just looks like a bug or task. The "bug" or "task" initially goes into a Triage category not attached to a release milestone.
2. The product owner (Product management in our case) manages issues out of the triage list. She consults with the Director of Engineering so development needs are always a key priority. "Bugs" or "Tasks" are move out of Triage into a Release Milestone on a daily basis.
3. The current Scrum works on tasks in the current Release Milestone. The product owner can move "Bugs" or "Tasks" in or out of the current Scrum as appropriate to meet changing needs or requirements. Since the tracking system automatically generates charts and graphs every day that are sent to everyone, this is a highly visible action and impact on dates can immediately be seen, as well as who in development has become a new bottleneck on the critical path.
4. Since the action of the product owner is so highly visible to everyone, including its impact on delivery dates, it may cause management to scream, development to scream, sales to scream, or client services to bitch. As a result it becomes a somewhat democratic process which culminates in a weekly Product Steering Committee. Every key person in the company is at that meeting. The meeting is led by the product owner and the CEO is the tie breaker on hot issues.
As a result of this open process, the product owner is very deliberate in what she does, and carefully balances competing needs.
5. Developers only work on tasks assigned to them for the current release milestone. This is the first thing they look at in the morning and the last thing they update at night. The tasks are specified as high, medium, or low priority. The developers prioritize their own work given the list they see.
6. If new tasks appear that need updated user stories, the developer simply reassigns the task back to the product leader for feedback.
The bottom line is that all of this has become so transparent and routine, that most of the questions about how to prioritize things or where to add them have just vanished. The "Dynamic Scrum" has become part of the corporate culture. High noise level and high energy clashes are confined to a one hour Product Steering Committee meeting once a week among key players.