 Reforming Project Management |
||
|
|
||
|
Thursday, October 10, 2002
Manifesto for Agile Software Development
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.Become a signatory to the manifesto. I did. Ignore the commonsense? Only if you want to succeed!
Lean project delivery and agile software development are sidling up to one another. Quite a number of the readers of this weblog are from the agile software/extreme programming/scrum development community, or should I say 'communities'. I can't tell yet. I am clear all three camps share a great dissatisfaction with the status quo and conventional wisdom. (Maybe when I'm able to pay closer attention, I'll be able to see the ground they've carved out for themselves.)
Two authors have caught my attention. Mary and Tom Poppendiek are well along to publishing a book on a lean approach for software development. They have posted a working manuscript of the book Lean Development: A Toolkit for Software Development Managers looking for comments from the community. I've been reading the manuscript for the last few days. The book is planned for publication in April 2003. They ask that folks not quote from their working copy, so I'll paraphrase some of their opening comments. (Please note that I take full responsibility for my interpretation.) Mary and Tom claim we have our mental models to blame for the current state of software development. The prevailing view is software is difficult and expensive to change, so we must take the extra time upfront to lock down the requirements to avoid those changes. I sse the same sort of thing outside the software community. People make similar statements about mechanical engineering, architecture, and construction. In all these disciplines the approach is get the client to say what their requirements are then don't let them change those requirements without penalty to the schedule and increased costs. But what is you put the convetional wisdom aside...what if software was no longer difficult to change? What if there were tools and practices that allowed for the quick changeover of code just as Toyota has done with the quick changeover of production machinery? What might be possible? But you say, "Why invest in changing software quickly? It'll never pay off. We don't let our clients change their minds." Right. But what if your competitiors learned how to do it? Where would you be? Both Toyota and Honda are in their second generation of production hybrid automobiles. Detorit doesn't have the first commercially viable vehicle. By the time they come around Toyota and Honda will be on the third or fourth generation. Those firms have taken the lessons of quick changeover from the factory floor to product development: design, marketing, tooling, supply, and process design. It is just this opportunity that Mary and Tom are writing about for software. There's a revolution underway. Many of you are a party to that revolution. The rest of you watch out. There's a hybrid in your review-view mirrow bearing down on you. Read about scrum at Jeff Sutherland's SCRUM Log from the person there at the beginning. Control: Getting Back from the Last Place on Earth
The race to the South Pole is a great story -- but the real race was getting back. I was raised on the myth of Robert Scott, the leader of the English expedition of 1911, and his heroic race to the South Pole against Roald Amundsen leader of Norwegian team. Scott struggled against fierce odds and died 11 miles from safety among brave companions. By contrast, Amundsen seems to have cheated. He traveled light and fast on skis and with dogs. But his real edge was less in technology and more in his approach to control. Scott was at heart a motivationist -- success for him was a matter of will. Real men pulled their own sleds. Amundsen was a learner who won the 1500 mile race to the pole, and the more important one back.
They each started at about the same time but from different places. On the way out, both carried poles to mark the path where landmarks failed. Both stopped and marked the path at regular intervals. Scott placed one pole to mark the path. Amundsen placed at least three, one in the center and the others well to the left and right. Each was marked with colored bands to locate its position& placing poles on both sides of the track slowed his progress on the way out. Coming back, both Scott and Amundsen struggled against the coming winter weather and limited visibility. Each had developed techniques for recording distance traveled and each relied on their poles to guide them back. Amundsen could be right or left of track and still find a pole, and adjust his track back toward the center for the next leg. His targets were wide so he rarely had to stop. Scott was forced to stop and send out searchers. Once the pole was found, the expedition had to be gathered before they could begin again. Point-to-point progress was slow when days mattered and rations were short. Amundsen moved so quickly in his wide path that he bypassed cached rations. He did not have to stay on or find the center of the track. Precise location wasn't required. Knowing he was in the track was enough. Scott's system would have worked fine if it were hardly needed. Amundsen accepted that he would not be able to navigate with great precision and built a control system that led him back. If yer gonna be dumb, ya gotta be tough. (For more read "The Last Place on Earth" by Roland Huntford.) Wednesday, October 09, 2002
Project Manager in a Box?
What project manager hasn’t experienced being boxed in. Been there; done that. But that’s not what this posting is about. Or is it?. Seems there’s a new class of software promising to revolutionize project management. It’s called Product Lifecycle Management (PLM). Andrew Raskin writes about PLM in A Faster Ride to Market.
Raskin describes how the Cannondale Bicycle Company got into the 4-wheel ATV market with an incredible push. After that taxing experience they decided to do something different – they are now using product life-cycle management software to manage product development. Hailed as a cure-all for eliminating waste and speeding products to market, (read one representative paper) it has the potential for being the next big diversion.
CRM is the most-recent example of a diversion. Last year alone $11 billion was invested in CRM software to improve/automate customer interactions. Results as reported have been checkered.
Tuesday, October 08, 2002
PDF Available of CPM: Fool Me Once, Fool Me Twice
You can find the PDF of CPM: Fool Me Once, Fool Me Twice in the left column of the weblog. Or, get it here
 .Project Klogs: Changing Paradigms
In my post of Sept 22, I speculated about new verbs for project managers. Seems I’m quite behind the times. John Udell, formerly of Byte Magazine, wrote about his own use of weblogs for project management in May 2001 Telling A Story. He explores story-telling as an important element in successful projects.
Email and the readable web are the two pervasive forms of interaction on the internet. Two other methods are gaining influence: instant messaging and blogging. Weblogs are a part of the writeable web. But people are not writing. Those of us who do write are an anomaly. Just like email brought about changes in communication (less careful, full of punctuation errors and misspellings, spam) IM has brought about more spontaneity in communications (abbreviations, jargon, profanity). Blogging brings out the writing skills and more importantly the expression of opinion, sharing of knowledge, and story-telling. Udell puts it this way, "What (weblogs) can do -- and it is no small thing -- is help people with latent abilities in these areas discover and grow their talents."Projects lack story-telling, particularly the kind that shapes a context for what is occurring on the project. Udell outlines design requirements for a project klog: "At the intersection of (email and the readable web) there is a niche for a storyteller to occupy. The story that needs telling is a project weblog." See picture and description.Udell's proposed structure for project klogs puts the otherwise unstructured nature of day-to-day interaction in the forefront for the team. It is the same dynamism of the interactions that leads to project breakdowns and that keeps us on track and leads to breakthroughs. The usual practice on projects is to keep the baseline project schedule in the forefront for the sake of establishing a mechanism of control. That practice interferes with the dynamism of interaction and, in so doing, dooms the project. Udell's proposal recognizes projects as human endeavors that depend on the quality of interaction, specifically trust-building and coordination. In essence, making assessments and moving to (new) action is central to project success. Equally important is keeping team members aligned…avoiding hearsay, bad moods, and breakdowns in relationships. His proposed structure lives outside the commonsense of the PMI. Beware: project klogs are not nice add-ons to the usual practice of project management. They belong to a different paradigm altogether, where planning is conversation, where doers are planners, and where the future unfolds. There's no straddling paradigms. You're in one or the other. Choose. Monday, October 07, 2002
Comments on the Fool Me Once, Twice Comments
Some very thoughtful comments were made on some of the postings from last week's series on CPM. I urge you to read those comments. Just click on the "Comment (#)" link at the end of each posting wherever you see a number other than zero in the parentheses. I urge you to leave comments as well.
A few people asked me what I was planning to do with the Fool Me Once, Twice series. Based on the requests I’ve decided to compile the five postings as a single document that I'll link on the site. That document can be freely downloaded and distributed. I hope you find it valuable. Now for those wondering what got me going on the series in the first place, I’ve been somewhat concerned about people who set out to adopt a new approach (to anything) while trying their hardest not to give up what they are doing. If what they were doing was working there'd be no reason to do something else! We know in the case of project planning and control that it routinely doesn’t work. Continuing to do the old has three negative effects on succeeding with the new:
Stop the craziness of doing the old and the new. Visit the Archives for more postings |
 Reference Papers
|
|
| ||
