[sldev] "Tim Lister on Project Sluts and Strawmen" - Slashdotted Q&A bits

[Dzonatas]

How can you blame anybody when you know your working with a strawman 
project to help people articulate?

For those into Q&A and missed or didn't see the slashdotted article: /

"Tim Lister, principal of Atlantic Systems Guild and co-author of 
'Waltzing with Bears: Managing Software Project Risk,' and 'Peopleware: 
Productive Projects and Teams' talks about the patterns that help 
determine software success or failure 
<http://blog.businessofsoftware.org/2007/07/from-project-sl.html>. 
Patterns good and bad include project sluts, Brownian motion, the 
strawman, and the safety valve."/


----


    July 12, 2007


       From project sluts to strawmen: An interview with Tim Lister

Tim Lister is a principal of Atlantic Systems Guild and co-author of the 
acclaimed books, /Waltzing with Bears: Managing Software Project Risk/, 
and /Peopleware: Productive Projects and Teams. /Freelance writer Bob 
Cramblitt spoke with Lister about the patterns that help determine 
software success or failure.

*Cramblitt: /You're working on a new book.   Tell us a bit about it./*

*Lister:* Actually I'm working on it with the five other principals of 
Atlantic Systems Guild.  The book is tentatively titled /Project 
Patterns: From Adrenalin Junkies to Template Zombies/.  It's a series of 
nearly 100 short essays on project patterns for good and bad.  If they 
are healthy patterns, we talk about how you promote them within the 
organization.  If they are dysfunctional, we tell you how to stop them.

*Cramblitt: /Let's start with the bad ones.  What are three things that 
project teams can do to ensure failure?/*

*Lister:* One is what we call /Brownian Motion/, based on the physics 
term defining a constant state of random motion.  In our definition, it 
means loading a project with people when you still haven't decided what 
you are actually going to do.

Another pattern is /project sluts/ -- organizations that can't say no; 
they have far too many projects for the staff they have, and things 
never get done.

We also see a pattern called /dead fish/.  This is a project that is 
doomed from the start because the schedule is outrageously unrealistic.

*Cramblitt: /What are some good patterns?/*

*Lister:* One of the best is /strawman/: building low-fidelity, low-cost 
prototypes for projects even if you know the approach isn't right.  
Strawman projects help you discover where you are going wrong early on, 
and help people articulate what they want and need.

/Seasons for change/ is a pattern that specifies that changes will be 
made only during certain windows of time, avoiding problems with 
constant tinkering.

/Testing before testing/ describes a pattern of doing quality assurance 
in parallel with the project, instead of waiting until the end.  This 
helps everyone understand project specs in the early stages of the project.

/Safety valve/ is another one.  People involved in projects need to blow 
off steam and do goofy things like jump up in the afternoon and go 
bowling.  There are other things related to this that are important too, 
such as sharing food, and setting up opportunities for people to get to 
know one another outside of work.  My dad once said, "it's hard to hate 
someone when you know their name."

*Cramblitt: /Has project management improved in the 20 years since you 
co-wrote /Peopleware/?/*

*Lister:* Yes, I think so.  More organizations realize that system 
building is a deeply human activity, rather than a high-tech, 
engineering effort.  People are looking at bigger projects differently.  
Good organizations aren't doing things in a ballistic way -- where you 
aim a gun, shoot, and the bullet goes where it goes.  The new approach 
is more like driving a car: you drive a bit and if don't like where you 
are going, you steer in a different direction.

I think the agile development people have a tiger by the tail.  They 
don't attempt to build a perfect spec that will be the bible for the 
next two years of development.  Instead, the approach is to spec a 
little, build a little, run it by people and get some feedback, then get 
another cycle going, continuing until you hit the moving target.  Larger 
projects are much riskier, and agile development is a way to minimize risk.

*Cramblitt: /What do you think about the reliance on best practices?/*

*Lister:* I get chills when I hear that phrase.  From my point of view 
there are some pretty good practices, but no best practices because that 
implies generic software development.  All projects are related to the 
domain they're in.  A best practice for defibrillator software is not 
the best practice in another domain.  I'd like people to think about 
patterns -- abstracting their work and recognizing the patterns they're 
in, good and bad, and making informed decisions to promote those 
patterns or replace them.

/Tim Lister will talk about project sluts, strawmen, safety valves and 
much more at the Business of Software 2007 conference, October 29-30 in 
San Jose. /


-- 
Power to Change the Void
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070713/060fb965/attachment-0001.htm