insights you can use |
|
|
"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm)  Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers) 
Archives April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 April 2006 March 2006 February 2006 January 2006 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 Contents (c) 2003-2006 Esther Derby I also publish a quarterly newsletter for people who manage in software organizations. If you'd like to receive the newsletter, drop me an email. It's on paper, so please include surface coordinates - name and full address. 
Syndicate this site (XML) 
Links 
|
Friday, December 29, 2006
More evidence that prima donnas (and prima dons) don't help overall achievement
Bob Sutton points to more research about prima donnas, prima dons, and jerks-at-work: Boris [Groysberg ] wrote me a pair of detailed notes about a series of case studies that he has done that track Lehman Brothers’ research department over a 20 year period. Boris reports that “the rule” [the no asshole rule] helped fuel the rise of the research department there, and then when it was abandoned, was linked to performance problems, and when it was reinstated, performance again improved. It seems that while we love the myth of the brilliant-but-difficult star, the data doesn't support our belief. Of course, there are exceptions. There are cases where one brilliant person is the pivot point for corporate success. But mostly it's just bad behavior that supresses overall results. Labels: management | Wednesday, December 27, 2006
Upcoming public workshops
Thought I'd let my readers know about the public workshops I've got coming up in the next few months: Certified ScrumMaster again with Jens Ostergaard (one of the most active Scrum trainers in Europe) February 1-2 in Portland, OR (at the ever popular Kennedy School) Certified ScrumMaster again with Jens March 15-16 in Dublin, Ireland Managing One-on-One with Johanna Rothman April 23-25 in Minneapolis, MN Secrets of Agile Teamwork: Beyond Technical Skills with Diana Larsen June 5-7 in Portland, OR A little something to help with New Years resolutions to learn something new. ;-) | Wednesday, December 06, 2006
Recognizing the Signs of Design Debt
Dave W. Smith has an interesting post on recognizing the cues that a product is garnering design debt. | Tuesday, December 05, 2006
all tied up in contracts
I keep running into companies that have set project up for failure by tying people up in contracts. Here's how it "works": An analyzst in the client organization writes requirements that are turned over to the vendor. The vendor interprets the requirements and then turns the requirements over to thier own developers. The developers write code. A vendor representative communicates status to a client representative, who in turn, communciates status to various internal client groups, including the development team who is responsible for the product--and will recieve the vendor code. When the code is "done," the vendor representative (not the developer or testers) turns the code over to an acceptance group in the client organization. Some wrangling happens here as the internal acceptance group says "It doesn't work" and the vendor representative says "The code passed all the tests specified in the contract." Back and forth, back and forth. Contract wins. The acceptance group fixes up the code as best they can, then turns it over to development team working on the product. They try to integrate the code, and spend lots of time fixing errors. Much groaning ensues. Progress grinds to a crawl. When it's clear that the client isn't getting the results they want, an executive demands that the internal people (who are tied up by the contract) "do a better job." Or the contract admistrators add more stipulations to the contract to try to force better performance. How is this producing valuable results? It's wonderful, I suppose, if you want to provide job security for the people who write and admisiter the contracts. It's not producing valuable results for the company--and if you look beneath the surface, it's costing much more than those dry numbers on the contract show. It's hell for the developers and testers involved--it robs them of pride in work and increase stress as all the external stakeholders demand better performance (while doing nothing to make better performance possible). Collaboration is impossible under contracts like this. If there are any feedback loops, they are so long and so indirect that they are useless. The answer is to work in partnership, put the developers and testers in contact with each other and with the customer. Work in short development cycles so that problems are found quickly and people can make adjustments to avoid those problems in the next iteration. Mary Poppendieck's has some thoughts on different ways to do contracts here. | |