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 
|
Monday, October 30, 2006
Agile Retrospectives: Learn all about it!
Learn all about it! Diana and I are offering a public workshop based on our book, Agile Retrospectives: Making Good Teams Great  , on November 20-21. Register through the Software Productivity Center in Vancouver, BC.| Thursday, October 26, 2006
bye bye bloglet
I've switched bloglet subscriptions to Feedblitz. I've heard complaints about that, too, so we'll see. | Wednesday, October 25, 2006
As nearly as I can tell, bloglet subscriptions service isn't working. If you are actually receiving notice of new posts from this blog via bloglet, please let me know. Otherwise, I'm pulling bloglet. If you know of an alternative that works, let me know...otherwise I'll only provide updates via RSS (at least for now). ED | Inflicting Help The other morning had an early flight from the west coast to Minneapolis. There wasn't a line at the check in counter, so I walked right up to the self-checkin kiosk. As I approached, a woman wearing an airline uniform approached me. "Let me help you." she said, firmly. "No, thanks," I replied. I put my suit case up on the scale, as I'd done at three other airports in the last week. "You can't do that!" the woman exclaimed. "Take your suitcase down!" I was puzzled. "I do this at other airports, what's different here?" I asked. "Don't put your suitcase on the scale," she replied. I put my suitcase back on the floor and swiped my passport in the passport reader. It didn't work. I reached in my purse to retrieve my credit card for the card reader. "What is your last name," the woman demanded. "I will type in your name!" "No, thanks," I said. "I have my card right here, I'm sure that will work." It was 4:45 AM, and I really didn't want help. All I wanted to do was follow my routine: checked in, pass security, and find coffee. I put my card in the reader and started the checkin. "Press 'Yes' under your name," the woman directed. "Now hit the enter key. Next you will be asked if you want to update your frequent flyer number." I turned to her. "Thank you, I don't need help." She moved to my other side and hovered. As I turned to put my credit card away, she scooted in front of me, pushed me aside and started pressing buttons on the screen. My luggage tag spit out and the man behind the desk spoke: "Going to Minneapolis? Our x-ray machine is in a different building, so we have to send suitcases on these special trays." "Is that why I needed to wait before I put my bag up?" I asked. "Yep," he responded, as he hefted my bag into the special tray. "It's a new procedure here." "Thanks for the information. That's helpful," I said to the man behind the desk. I walked off to the security line, shaking my head and musing about how some people "help." Sometimes coaches (and managers) insist on inserting themselves into situations where their help is neither needed or wanted. They give step-by-step instuctions when information is what's needed. The make corrections without providing the context that would enable the other person to eliminate their own errors. They offer solutions when acting as a sounding board would be more useful (both in terms of developing capability and buy-in for the solution). They "do," depriving the other person of a chance to try and learn (or do competently in a different way). So should coaches always stand back until they are invited in? Of course not. Before jumping in to help, ask if help is wanted. No request for help is forever, or covers every aspect of work (or life). Find out what kind of help the other person wants. Agree on the scope and duration for the help. If someone declines your help leave him alone. And face your own motives: Did you really want to help that person, or did you want them to do it your way? Are you worried about an outcome that may impact schedule or quality or have other down stream consequences? Then maybe what you need to do isn't "help." Maybe what you need to do is express your concern. Inflicting help when it isn't wanted isn't helpful. | Monday, October 23, 2006
Secrets of Agile Teamwork: December 5--7 in Portland
We have a few space left for the PUBLIC Secrets of Agile Teamwork workshop that's coming up December 5-7 in Portalnd, OR. It's a fun, practical workshop in a great setting. You can download the registration form here. | Monday, October 16, 2006
Something odd is happening with my posts... there's a big block of white space at the top. Don't know why it is there. Don't know what changed...but I bet it was just a small change. (Up-until-now, this happened on archives, but not on the main blog.) Bah! | simulations for learning I use simulations and activities to promote exploration and learning in almost all my workshops. Even if you don't teach workshops, simulations can be useful for problem-solving. For example, I sometimes have teams use simulations to see where the bottle necks are in their process or examine team dynamics. The macro is always in the micro. Not only are simulations more fun, people learn more when they discover and explore rather than acting a passive recipients of "knowledge." If you're intereseted in using simulaitons for learning, check out Bill Wake's day-by-day report from the NASAGA conference. | Saturday, October 14, 2006
Cross Polinization
My friend Brent Barton reminded me of another way to put learning into action across the organization. When your team holds an iteration retrospective, invite a coach or scrum master from another team to lead the retro. This has two benefits: 1) The coach/scrum master for the team ending their iteration can participate in the retrospective; his or her part of the story will be included in the data gathering and analysis. 2) The coach/scrum master who is leading the retrospective gets to hear the issues and analysis and will be able to take information back to his or her team. | Monday, October 09, 2006
No, we still aren't plug and play.
Interesting post from Bob Sutton on the obsession with individual talent, and the evidence that people are more productive when they build relationships and work togeher over time. | A cover up? Perhaps not. Someone recently described this situation on the Scrum Development list: "...we've found some members of the Scrum team working extra intensely to cover for poor performing people. The poster wanted to know how to identify and fire weak performers on agile teams. I'd try on some different ideas: Perhaps the developers "cover" for this person because they value something else he/she brings to the team. I've run into lots of people who had "weaker" development skills but brought other strengths that outweighed that weakness. On any team, and especially when people ust collaborate closely, there are people who work "in the white space." Things just go better when they are around, though their contribution may be harder to measure. Of course, I'm only privy to a snippet of the story. There may be other evidence or information that leads the poster to conclude there is a weak performer to be rooted out. But if this team is meeting it's commitments, writing solid code, and surfacing and fixing other issues, I wouldn't assume that there's some one who is too weak to be on the team. | Sunday, October 08, 2006
Putting Learning into Action
Someone recently asked, "How would you go about inculcating the results from retrospectives [sic] back into the culture for the benefit of future projects?" There are two different approaches depending on whether the team holds retrospectives as they go, at the end of every iteration (or at intervals during the project) or at the end. Teams who do retrospectives regularly during the project can apply what they learn right away. When teams reflect and improve as they go, the issues then to be more focused--either issues they can fix or obstacles to getting their work done. These teams incorporate learnings into their team culture as they go and help the current project. To the extent the team stays together, they help future projects. And of course, each person will take a broader set of options to thier next project, along with better problem-solving skills and a focus on continuous improvement. As a facilitator/retrospective leader, I find that some of the keys to putting learning in action are for iteration (or interval) retrospectives are: For end of project retrospectives, especially when the team will disperse, focus on personal action plans (what the individual can do differently the next time) and recommendations that address systemic or management problems--assuming that there is some management team that will work on those systemic issues. If no one is going to work on them, it’s a moot point. Though sometimes I'll do a retrospective any way to bring closure for the team and help them see how they can influence and affect the system. Some organizations use patterns to inculcate learnings into the culture. | Saturday, October 07, 2006
success and failure
Thursday, October 05, 2006
Coaching Toolkit
Monday, October 02, 2006
No waiting
....in line for the ladies room (even with one closed). I'm struck by the ratio of men to women at JAOO, and reminded of a discssuion on the AYE Conference wiki about Women in IT. I am having a lovely time at JAOO. Here's an update on the actual proportion of men to women at JAOO. The organizers announced hat 7.7 % of the participants were women. One guy commented that he was thrilled, since in the database world where he works, women make up 1%. | |