• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Does the book help with Agile/Lean where developers have >1 project at a time?

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi again Mary & Tom,

In our resource-strapped organisation, most developers are working on > 1 project at any given time.

Do you think this is an obstacle to us implementing agile/lean, and does the book have any techniques to overcome it?

Thanks,
Katie
SCJP
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even in more conventional (less lean) software development methodologies it is usually indicated that a primary resource that is not fully dedicated to the project (i.e. as the only project) has to be identified as a project risk. It is usually permissible to be transitioning out of one project and transitioning into another for a limited time period.

As Human Task Switches Considered Harmful outlines there is very little to gain from task switching - unless there isn't enough work from just one task. Basically rather than having one task done now and the other later, you trade off by having both done later - were is the benefit?

Methodologies that focus on the essentials always want to expend the current effort on whatever has the most business value. Situations that "waste" effort on "context switches" (which will happen when you work on multiple projects) are depriving the organization of business value and therefore are not in-line with an "essential" mindset.

So you have keep educating "management" of the impact that yet another project in your in-basket will have on the projected completion on your remaining workload and the impact that will have on the organization. Each additional concurrent task implies that the previous tasks aren't that important as it is apparently permissible to delay the completion of the earlier tasks (even further).

Tim Ottinger: How Many Feathers
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Katie Portwin:
In our resource-strapped organisation, most developers are working on > 1 project at any given time.



This seems to imply that having a developer work on more than one project at a time makes for a more effective use of resources. I'm not at all convinced that that's true.


Do you think this is an obstacle to us implementing agile/lean, and does the book have any techniques to overcome it?



One big part of being Lean is identifying and eliminating waste.

I'm sure that a closer look would reveal that having a developer work on more projects than one at a time is quite wasteful.

Has the book something to offer to eliminate that waste? Interesting question...
 
author
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Katie,

As unintuitive as it may seem, multitasking almost always takes more time than doing one thing at a time, and is a huge source of waste. If you look into in carefully, multitasking is usually a symptom of management teams not wanting to make tough priority decisions, not a way to make best use of scarce talent.

We talk about this in the book and have a diagram to show why task switching generally makes things worse, not better.

Mary Poppendieck
 
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was always against this multitasking nonsense . Think of all setup and cooldown times you waste for each task comin in between .

Regards,
Darya
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah. See also the second point at http://www.stsc.hill.af.mil/crosstalk/2006/11/0611Derby.html
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What's missing in Joel's example is what makes multi-tasking worth while in computers: one thread is blocked so the CPU is free to run another thread.

If you suggest managers only give humans one task at a time, they'll ask what that person is going to do while blocked? For example, we rely on services from partner systems. We often wait for them to become available or implement some defect correction.

Seems that a potentially difficult part of making one task work is to never be blocked. For this partner system example, one might mock out the partner until they come around.

Never being blocked is addressed in TOC with buffers, no? Does Lean have other nifty ways to handle it?
 
Mary Poppendieck
author
Posts: 62
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are going to get blocked on a task, then you can have a fall-back (low priority) task. But that is very different than having multiple high priority tasks fighting each other for your attention.

Note that our servers cannot operate at 100% utilization. Anywhere above 80% utilization they start slowing down, and about at 90% utilization they are crawling. Same thing happens in development - only we don't recognize in development that scheduling full utilization is in fact a bad idea.

Mary Poppendieck
 
brevity is the soul of wit - shakepeare. Tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!