Comments on SandyWalsh.com: Iterations and Time-boxing are (Mostly) Useless

Thanks Glen ... feel free to use the images.

2011-07-04T17:07:59.689-03:00

Thanks Glen ... feel free to use the images.

Sandy, Great idea. Close to our Planning Packages...

2011-07-04T17:05:56.827-03:00

Sandy,

Great idea. Close to our Planning Packages and Work Packages here in DoD flight systems development.

Can I reuse those two charts in other presentations to the DoD community?

Hi Sandy, Welcome to the Kanban is better that It...

2011-05-22T23:02:24.870-03:00

Hi Sandy,

Welcome to the Kanban is better that Iterations party! For the record, I am BIG believer in Kanban.

I don't think the core of the arguement is about process or efficiency. I think it is more about culture and values.

Reading your post, I really got the sense that you are coming from the perspective of technical excellence. I also hear you talking about the developer's perspective.

This is very striking for me. Scrum and Agile requires a whole, cross-functional team. The values of Scrum are much more around succeeding as a team and growing - perhaps that is why it has not sat well with you?

What you value will tell you how you see effectiveness: on the one hand keeping developers busy and on the other hand working as a team.

So I can see how from your value system, Scrum is probably the worst thing that could happen.

I have written quite a bit about culture since I think it is central to understanding where the Agile/Kanban community is. e.g. http://agilitrix.com/2011/04/problems-with-agile-check-your-culture/

BTW, for the record, "Stories" are an XP technical practice - Scrum has these silly things called "product backlog items".

Regards,
Michael

Thanks Tom! I agree ... really it's just askin...

2011-05-02T16:52:06.609-03:00

Thanks Tom! I agree ... really it's just asking person to person "whadda ya think?" and realizing it's all just an educated guess. 'Confidence' works for me. Someone else suggested 'Morale' ... anything really.

Nice post - lots of food for thought. I would als...

2011-05-02T16:36:15.580-03:00

Nice post - lots of food for thought.

I would also quibble with "sentiment", but don't like the proposed alternatives much either.

How about "confidence" or "comfort level"?

-Tom Bushell

Hey J.B. thanks for the feedback. I agree there h...

2011-05-02T10:50:59.315-03:00

Hey J.B. thanks for the feedback.

I agree there has to be some "thought time" set aside before tackling a problem. I'm talking about what happens after the plan-of-attack has been established. If the outcome of your planning says "I can get this done in a reasonable time, just let me do it". But if the management practice dictates that all tasks have to be broken down to small chunks regardless, there's a problem.

I don't think any effort should go longer than 3 days without a push to a branch for risk of "going dark". I may even argue 2 days. The code is the important thing, not the project management tasks.

I can think of many occasions where developers have ticked off "programming" tasks for the project and still not delivered any production ready code. Devs can go weeks playing that game when poor management is at the helm.

So, do devs hate tasking out a story?Yes, when the breakdown is artificial or provides little value. Do you really need a breakdown of every button on a dialog box? I'm comfortable with that being a fairly blanket statement. Do devs need time to get a plan of attack? Absolutely. And we should all love creating one.

Hm, Sandy. I was with you right up until this: &q...

2011-05-02T10:27:37.349-03:00

Hm, Sandy. I was with you right up until this:

"Developers hate having to break down tasks to such a fine resolution that they can be tracked in 4-8 hr intervals. If I have to think about a problem to 4hr resolution I may as well just code it. Why not 1 hour? Why not task out to every 30 minutes? Simple, it's a case of diminishing returns. The time it takes to document the tasks outweighs the effort itself."

Really? "Developers"? or you?

Early in my career, I met a colleague who told me how to distinguish a senior programmer from a junior programmer: give them a task and watch them for 15 minutes. The junior programmer has already started typing.

My point: few people like planning out their work. Most would rather just do it. Still, in order to avoid doing too much, veering off track, doing the wrong thing, and so on, we train ourselves to plan the work out. This way, we have more signals than our intuition to help us detect when we go off track, do too much, or get stuck.

Even so, I like the overall message, although I'd add that timeboxed iterations are useful as an intermediate step from very long cycles to free (iterationless) cycles. I usually cut feedback cycles in half repeatedly until we reach an effective size, and when the overhead of tracking exceeds the amount we can do in a cycle, then we stop tracking so closely. That equates, I think, with the iterationless approach.

foredecker: thanks! Mark: progress can still be m...

2011-05-01T10:13:59.384-03:00

foredecker: thanks!

Mark: progress can still be measured (in time units) by code getting submitted and reviewed. So long as the developers don't go longer than, let's say, 3 days without doing a push to a branch. As for "what to work on", the customer still controls the backlog, but there are no "time blocking" impediments to picking them up.

xhevahir: heh, yeah, sorry about that :) I like the idea of "morale" as well. The great good of the team. Same principle ... thanks.

blast this out in smaller chunks Was this ...

2011-05-01T02:04:47.543-03:00

blast this out in smaller chunks

Was this supposed to sound totally gross?

Also, I submit that "morale" conveys your meaning, or what I take to be your meaning, better than "sentiment."

I like the overall idea. Not sure if it would be a...

2011-05-01T01:55:40.634-03:00

I like the overall idea. Not sure if it would be accepted by management though due to e.g. the less fine grained and in my opinion thus also less accurate estimates.

Something else: you ask the following question: "I've finished all my work early, what should I do?" And suggest some options: "Should I start working on another story from the next iteration (which includes bug fixes)? Should I perform some other non-development task such as manual testing or documentation? Should I refactor?"

But when you give the example of the DRCS you immediately assume that you'll want/need to work on new tasks/stories. When will those necessary non-development tasks be done?

Interestomg, well written post. Very much what I ...

2011-04-30T13:40:07.578-03:00

Interestomg, well written post. Very much what I champion in my work.