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 May 2007 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 
|
Sunday, February 26, 2006
Fatal Delegation Mistakes
In BCD, Johanna and I wrote a section “Setup for Successful Delegation.” We wanted to help managers think through the boundaries of a task they’re delegating and be clear—with themselves and the other person—about requirements, unacceptable solutions, progress reporting, and desired results. Delegation can build trust and capacity when done well. When managers screw it up, the person delegated to feels set up and loses trust. Some common mistakes: The dictionary definition for delegate is “to commit or entrust to another.” Every time a manager delegates, there’s the possibility to build commitment and trust or erode trust and engagement. Managers—because they are human—won’t do it perfectly every time. When that happens, managers can maintain trust by owning the part of the miscommunication that’s theirs. That might be: “I didn’t make it clear that here were some solutions that were out of bounds.” “I wasn’t clear that I intended that I retained final approval for the product.” “I wasn’t clear that I wanted you to bring options, not a final product.” And if you get some bright ideas once you see that product, make that clear, rather than announcing the new idea as a criticism or rejection: “Now that I see what you’ve produced, I’m getting some new ideas on how do to this. I sure wish I’d thought of this earlier. I think it’s important enough to reconsider.” | Saturday, February 18, 2006
"A" work or "C" work
On Friday I gave my talk, The Value-added Manager: 5 Pragmatic Practices at the SQUAD Conference in Denver. I had a great time. One of the practices I cover in my talk is making a to-do list and a not-to-do list and getting clear on priorities. A woman in the audience offered that she also talks in terms of A work, B work and C work… by which she means that in addition to knowing the priority of a project or task, you need to know the quality that’s required. Most of us group up with adages such as “If it’s worth doing, it’s worth doing right.” That’s a nice saying, and like most old saws, it leaves out the context. Sometimes it is worth doing something “right.” Other times 80% “right” is good enough, and the effort and cost required to achieve 100% “right” doesn’t make economic sense. So along with priority, define what *done* means, and what *good enough* means for the task at hand. A work vs. C work is a nice short hand for the concept: in reality, it's important to be specific on the desired results. | 6 Reasons *not* to have a Retrospective Retrospectives are a great way for teams to inspect and adapt their methods and teamwork after each iteration and release. And they’re a great way for teams to build on success, learn from hard times, or bring closure when a project ends. But they’re not for good for everything. Don’t do a retrospective if you want… On the other hand, if you want to learn from experience, build on what works, gain perspective, and decide what to do differently, a retrospective can work for you. | Friday, February 10, 2006
Secrets of Agile Teamwork: June 6-8 in Portland
Back by popular demand: Secrets of Agile Teamwork! Beyond technical skills, Agile success depends on productive self-organizing teams. How do you develop, grow, and maintain a functioning self-organizing team? It’s not magic, but it doesn’t just happen either. Effective self-organizing teams rely on personal and interpersonal effectiveness. In this hands-on workshop, we’ll discover the secrets to developing the skills you need to succeed and lead on a self-organizing team. Audience: Team leaders, team coaches, XP coaches, ScrumMasters and others leading and working in teams. Pre-requisites: A desire to be best team member or team leader possible. Logistics: We'll be at the Kennedy School in Portland, Oregon. Benefits: Here’s what people who have attended the workshop are saying: “Great workshop! Very thought provoking.” “This workshop gives you great skills in communicating with co-workers. “I think this is a must-attend workshop for almost all levels of “Very positive. Worth the time and energy if you want a better “Not boring corporate techniques. Real processes that help and “Interesting. Illuminating. Introspective.” “Esther and Diana teach the soft skills that you think you already have You can download a registration form here. | Jerry Weinberg on the AYE blog Jerry Weinberg finds wisdom in Japanese proverbs in this post on the AYE blog. If I were to give advice to a young professional starting out in the world, I could do no better than quote three Japanese proverbs: We learn little from victory, much from defeat. Even a thief takes ten years to learn his trade. If you believe everything you read, better not read. | Thursday, February 09, 2006
Smallest Lever
One of my readers asked me to explain how I use Next Action -- which is a little different than described in David Allen's book. So maybe I should call it something else like "Smallest Lever." I use Smallest Lever for tasks or projects that Rather than think about doing the whole thing, which brings on a bout of MDD (Motivational Deficit Disorder) I identify the smallest possible action that will move the task forward-- a task that will take only a minute(or less) and is not at all onerous. So I might: Once I take that small action, I'm usually started with the project and have enough momentum to make significant progress. Completing the entire task usually takes much less time than I put into finding other things to do so I could feel productive while avoiding this other task. Some days managing myself takes all my time. ;-) | Wednesday, February 08, 2006
Retrospective Workshop in Denver
I'll be at the SQUAD Conference in Denver next week doing a full-day workshop on Retrospectives on 2/16 and giving a talk on The Value-Added Manager on the 17th. | Monday, February 06, 2006
Continuing the rif on Managment and Leadership
Sunday, February 05, 2006
Next Action
A while back I listened to David Allen’s Getting Things Done on audio book. (I remember noticing passive voice—which struck me as odd in a book about taking action.) I haven’t implemented the system--or purchased the gear. But I am practicing Next Action. For me, Next Action helps me get started on projects that don’t play to my strength (logistics planning, for example) or I don’t like, but have to do (like taxes). Rather than having to figure out the entire project or devote hours, I decide on the simplest, smallest action I can take that will move the project forward. When I take the smallest action, I usually keep going, and complete the project—in much less time than I spent thinking I *should* be working on it.. Next Action busts through inertia and gets the nasty tasks out of the way so I can do something I enjoy. I suppose I could decide on the Next Action to implement the whole system… Nah. | |