It's not a secret anymore!*
The moose likes Agile and Other Processes and the fly likes Manage It! features in iterations... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Manage It! features in iterations..." Watch "Manage It! features in iterations..." New topic
Author

Manage It! features in iterations...

Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
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


"Eppur si muove!"
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Oh, and by how much are you off, typically?
Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
...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 ]
Johanna Rothman
author
Ranch Hand

Joined: Feb 10, 2005
Posts: 72
    
    6
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


See all my books
My blogs:Hiring Technical People blog - Managing Product Development blog
Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I see. Do you also go home early when you are finished ahead of time? Serious question.
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30068
    
149

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.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Johanna Rothman
author
Ranch Hand

Joined: Feb 10, 2005
Posts: 72
    
    6
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
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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...
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Manage It! features in iterations...
 
Similar Threads
Pointer in Java
Project ---> Iterations
synchronized block
Is agile smaller dimensions of water fall model?
Development Process