Wednesday, September 17, 2003

Updates Suspended

Due to a family medical emergency, I have to return to Scotland for a few weeks. Updates will resume when I return to Seattle, possibly at the beginning of October.

It’s an Outsource World! - enough said…

<!—StartFragment—>CNN Money has an article about Outsource World Expo in New York…. 

“Workers, from software developers to system administrators to engineers, are very frightened about what this trend means about the future of the industry and the future of their jobs,” Joshua Sperry, an organizer with the Communications Workers of America, said this week in a press release announcing a protest of offshore outsourcing.

Tuesday, September 16, 2003

Reduce Variation Reduce Cost

Hal Macomber is discussing good and bad variation. Variation is getting attention from a some other bloggers too. Why is variation important? Because the more of it you have the more it costs to get work completed.

If project promises are to be met and software delivered on-time, then schedules must be buffered against common cause variation. This requires an understanding of the performance of a team in the past, and a prediction that their performance will be similar in the future. For example, if historically it has taken 2.2 days +/- 1.0 days to complete Features of complexity rating 3, then it is likely to take a similar time in future.

To be sure of delivery a manager will need to buffer 1.0 days over the mean 2.2 days for such a Feature. A whole project of similar Features would require a buffer determined from the square root of the sum of the squares of those 2.0 individual buffers. For 50 Features, the required project buffer is 7 days. The total project length is 110 days + 7 days = 117 days.

If the manager improves the team skill level with mentored training in analysis, then variation may fall. Say it fell to only +/- 0.4 days. The result would be a requirement for a buffer of only 3 days for 50 Features. Saving 4 days of effort.

Reducing variation, through better, more repeatable analysis of software deliverables, saves money by reducing the time to deliver projects.

Monday, September 15, 2003

When New Policies Move the CCR

Introducing a new policy can move the system capacity constrained resource (CCR) and create problems throughout an organization. These problems are foreseeable when a manager understands the effect of policies on the CCR. Policies are a type of constraint. The introduction of a new policy might make it the overall system constraint.

For example, let us imagine that the chief architect is becoming uncomfortable with the quality of emerging code and feels that the original architectural intent is not being achieved. With a simple announcement, he introduces a new policy that all designs must be reviewed by him before coding commences. In an instant, the chief architect is now the overall system constraint. A one-man bottleneck. It doesn’t matter where the constraint was before - UI design, Testing, Usability, Requirements or Coding - the new policy moved the constraint.

What are the effects of moving the constraint? People downstream in the process find themselves idle for periods. Work upstream begins to stock pile. People producing designs can’t get to “complete” without a long wait. The project schedule can be abandoned. It too needs to be re-written. The PMO (if there is one) needs to re-write the master schedule. Customers get frustrated and their expectations need to be managed.

When the CCR moves, everything changes. New policies can move the CCR. Changes in CCR should be planned and the overall system-wide effect understood in advance, otherwise chaos ensues, leading to accusations, blame and loss of trust. The introduction of new policies cannot be made locally. New policies should be agreed system-wide after being fully understood by the value-chain of line managers affected.

Saturday, September 13, 2003

Advanced Praise

“At last! While software engineers will design systems around the common principles of software engineering, the same level of rigor has not been paid to the management principles. I highly recommend this book to anyone who is looking to bridge current thinking on management and process control to the management of software development. If you are accountable for not just software development but also making your business a success, then read this book.”

Craig Hayman, VP Development, IBM Pervasive Computing

“In 2001 Sprint PCS faced the challenge of how to literally invent thesystems and applications necessary to launch the first full-scale productionimplementation of 3G high speed wireless data in the world. David Andersonand a small team of a smart people in Kansas City with lots of passion andvery little sleep met the challenge. In August 2002, Sprint introduced PCSVision nationally in the U.S. ...”

Scott B. Relf, former Chief Marketing Officer, Sprint PCS

“A tremendous contribution to the literature in the field. This is going tobe required reading for my teams going forward.”

John F. Yuzdepski, former VP and GM Openwave

“Finally, a book that takes Theory of Constraints and Critical Chainthinking and applies them to software development. Reading this bookwill change how you think about software projects.”

Mike Cohn, Director of Articles, Agile Alliance

“The book is great! I’m conversant with the Theory of Constraints already so it may be that understanding comes easy, but your book has really helped me fine-tune my ideas. I think the focus on ROI will be really useful. I’d never thought to use the concepts in those terms until now.”

Dana Smith, Development Manager, Corel Corporation

“The book is very well articulated.  I like your style of teaching the conceptsand leading the reader from one point to another.  Well done!”

“I see this as an important, ground breaking work formanagers, in that is allows them to understand and implement TOC concepts inthe agile software development environment.  Reading it is definitely timewell-spent!”

John (Mac) Felsing, co-author of “A Practical Guide to Feature Driven Development”

“As a general manager in a technology company, I found this book to be very enlightening. It gave me an entirely new perspective on the process of software development and the struggles of my peers in engineering.”

Keith J. Mitchell

“The declining economy and intense competition have forced IT organizations to do more with less resources. IT organizations are challenged to produce quality software with a tight budget without compromising on requirements. How can this be possible? “Agile Management for Software Engineering tackles the present-day challenges of software development. David presents a variety of proven metrics that can be applied to software development. In the post dot-com bomb era, survival of IT professionals may very well be dependant on how managers utilize the tools and theories described in this book.”

Pujan Roka, Project Manager and Business Analyst