• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Manage It! features in iterations...

 
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Johanna,

A recurring problem in some of the projects I work on is managing the
features in iterations...

An iteration is often enough either too small or too big...

How would you manage this type of issues? Are they discussed in
your book?

Thanks,

Gian
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gian Franco:

A recurring problem in some of the projects I work on is managing the
features in iterations...

An iteration is often enough either too small or too big...



What you really mean is that you put either too many features into an iteration, or not enough, I guess?

How do you estimate your features? How big are the features? How big are your iterations? How do you decide how much you can do in an iteration?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh, and by how much are you off, typically?
 
Gian Franco
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
...maybe around +/- 10% of the time given for an iteration...

The problem is that the customer notices only the -10% part, since the
iteration may end up to contain more features in the same amount of time,
which is actually favourable.

The +10 often comes with working over hours, and when this is not
achievable, due to the current limitation of 24 hours a day ,
with reduced features.

...often there are also additional small features the customer really
likes/wants to be introduced during an iteration, be it minor issues
or forgotten wish list items. These features taken alone would almost be
insignificant in impact, but the context switching involved can cause an
iteration to be delayed.

...and what also influences iterations, and being off target, is the
context switching involved when working on more than one project. Often
enough it is not possible to really work only on one project on one iteration.
[ November 13, 2007: Message edited by: Gian Franco ]
 
author
Posts: 72
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let me try to unpack this and get to what I think the problem is:

1. If you have to context switch during an iteration, your iterations are too long, or you have too many people, or your backlog isn't sufficiently organized to do an iteration's worth of work.

If you have 4-week iterations, move to 2-week iterations. If you have 2-week iterations, move to 1-week iterations. You'll plan to do less, which should help with the over/under-estimation problem and will definitely help with the context switching.

If you have too many people on one project, move some of them to the other project, so you have 2 projects in parallel and no one is multi-tasking.

2. If your estimations are still off, I would look at the size of the user stories. I see off estimations when people are still estimating big chunks instead of smaller chunks.

3. You are training your customer to not add things to the product backlog, but to add things to the sprint backlog. Bad developer! Seriously, if your customer wants more things in an iteration, reduce your iteration duration, so you release to the customer more frequently and the customer adds things to the backlog.

What did I miss?
Johanna
 
Gian Franco
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks!

...and the last point of 'other projects' interfering (for the cases a developer works on more than one project)?
[ November 13, 2007: Message edited by: Gian Franco ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gian Franco:
Thanks!

...and the last point of 'other projects' interfering (for the cases a developer works on more than one project)?



I think Johanna's other tips apply: don't have developers work on more than one project, and/or make your iterations short enough that it doesn't become an interference.

In the end, it's probably management who needs to decide whether the productivity impact by the interference is worth it. What the developers can do is making the costs transparent and providing options.

"Doctor, it hurts when I do this." "Then don't do it!"
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with everything Johanna said, and want to add some additional thoughts...

Originally posted by Gian Franco:
...maybe around +/- 10% of the time given for an iteration...

The problem is that the customer notices only the -10% part, since the
iteration may end up to contain more features in the same amount of time,
which is actually favourable.



10% doesn't sound particularly bad to me. That doesn't mean that you shouldn't work on improving the estimates (I am very fond of Planning Poker), but I also wouldn't be too worried. After all, they are *estimates*. If we knew exactly how much we can do in an iteration, we could call them something else, I suppose.

It sounds like your customer takes those estimates as commitments. That's not necessarily wrong, it's just something you need to consider. One thing to do this is to build slack into the schedule of an iteration. Simply always commit to 10% less (for example) than you estimated you could do, and add some slack features, that you only do when there is time left at the end.


The +10 often comes with working over hours, and when this is not
achievable, due to the current limitation of 24 hours a day ,
with reduced features.



Am I understanding correctly that in some iterations, you are working overtime to deliver more than you committed to? I can easily imagine how that would destroy your predictability and confuse the customer. Why would you want to do something like that?

...often there are also additional small features the customer really
likes/wants to be introduced during an iteration, be it minor issues
or forgotten wish list items. These features taken alone would almost be
insignificant in impact, but the context switching involved can cause an
iteration to be delayed.



Yes. You need to make that cost transparent to the customer and ask him to remove other features from the iteration to make up for it. Give your customer the option to include those features without compromising the iteration, and make it easy for him to decide by enabling him to compare the costs with the value he gets out of it.

Does that help?
 
Gian Franco
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Ilja!

as for your question...


Am I understanding correctly that in some iterations, you are working overtime to deliver more than you committed to? I can easily imagine how that would destroy your predictability and confuse the customer. Why would you want to do something like that?



No the overtime is due to iterations that contain too much features, or
that have been 'disturbed' too much (e.g. by context switching), and in
order to put all the features in there is +10% more time spent in the
iteration.

Cheers,

Gian
[ November 14, 2007: Message edited by: Gian Franco ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see. Do you also go home early when you are finished ahead of time? Serious question.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
I see. Do you also go home early when you are finished ahead of time? Serious question.


Do you?

I know that I don't. I also don't work large amounts of overtime, so this seems like a fair arrangement. I use that time to work on other projects which are behind, our development/process enhancements (maybe we can automate something to save time) or learning/trying out a new technology that is relevant to work.
 
Johanna Rothman
author
Posts: 72
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Warning: rant on overtime ahead

I am not a fan of overtime. I do recognize that every so often, it helps the team finish what they committed to.

But in Gian's case, where (assuming I read correctly) management decides to multi-task people, who then can't finish the work in a timebox? And the technical staff pays for it in overtime? Hello? Why???

One of the best ideas I discovered (and I can't remember where I read this or learned this) a billion years ago was: The person who makes the pain has to pay for the pain. So management, who in their quite-limited wisdom, decides to multi-task people, has to have the pain of not allowing the project team to finish. When the project team stays late to finish what they tried to commit to in an iteration, they train management that it's ok to multi-task. It's not.

Why is it appropriate for you to allow managers to make the decision to multi-task you and not pay for it? Why are you taking care of the managers? They're not taking care of you.

More reasonable words ahead:

Overtime is a short-term solution to the under-estimation problem. If you persistently and consistently under-estimate, you need to learn why and fix that. But extended overtime makes people stupid and tired. When people use overtime, they create defects that are harder to fix and take longer to do so.

Overtime is a sign of lack of feedback somewhere. Make sure your managers see and hear the feedback.

Johanna
 
Gian Franco
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
I see. Do you also go home early when you are finished ahead of time? Serious question.



...there is always something interesting to do, improving the auxiliary tasks like automatic builds, improving documentation, running checkstyle, etc....

But of course I go home early if things allow it, it's not that bad
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeanne Boyarsky:
Do you?



No. And I only work overtime for a day or so when there is an important deadline. *Then* I typically go home early the *next* day to catch up on the rest I missed the day before.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gian Franco:
But of course I go home early if things allow it, it's not that bad



That's good!

I would have thought of it as unfair to have to stay longer when things go bad, but not be allowed to go earlier when things go well...
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic