esther derby's "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) Syndicate this site (XML)
Archives May 2009 Apr 2009 Mar 2009 Feb 2009 Jan 2009 Dec 2008 Nov 2008 Oct 2008 Dec 2007 Nov 2007 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-2009 Esther Derby |
Friday, February 25, 2005
The Secrets of Agile Teamwork: Beyond Technical Skills
Successful agile development relies on collaboration -- a higher level of collaboration than we've come to expect in traditional organizations with functional silos. Agile success depends on productive self-organizing teams. Effective self-organizing teams rely on personal and interpersonal effectiveness. You could just throw people together and hope they figure out the skills they need to work together. But my pals Diana Larsen and Ken Schwaber and I figured it would be more effective to give people a leg up with a workshop that focuses on the teamwork side of Agile. The workshop will be April 5-7, 2005, in Portland, Oregon. Email me if you'd like to learn more about the workshop. Tweet this Post | | Spammers at work. I'm turning comments off, at least for now. In theory, my comments provider has anti-spam measures in place, but they don't seem to be working here. If you have something to add to a post, send me an email and I'll post it. (Assuming its not spam). Tweet this Post | | Wednesday, February 23, 2005
Random thoughts on Agile change
It seems that Agile is out of the early adopter phase and people are starting to ask about how to do Agile organization wide. So I've been pondering change for an Agile organization. One thing I'm quite certain about is that traditional top-down,deterministic change programs aren't the right way to go. If someone starts talking about "change targets" they're thinking about change in a way that is, in my view, antithetical to self-organization. Moving towards the Agile organization requires a more organic, more participative model of change. I've been looking at Olson and Eoyang's Facilitating Organizational Change. They bring concepts from complex adaptive systems to organizational change and are challenging traditional assumptions about how change happens. Part of moving to Agility is creating the conditions for self-organization and innovation. That means working: the container that sets the boundaries around the system that self-organizes significant differences that determine the patterns that emerge (e.g., levels of expertise, degrees of power) transforming exchanges that pass among people within a particular system and also in/out of the system boundary. ... on a scale broader than several software teams. I've also been revisiting Peter Block's Stewardship, which has useful ideas for shifting the command and control mind-set. I listened to Block's the Right Use of Power on my recent road trip and this statement really stood out for me: "People don't resist change; they resist coercion." More ruminations to come, I'm sure. Tweet this Post | | Sunday, February 06, 2005
Quality results come from quality interactions
Brad Appleton starts his new blog with a post The first thing to build is TRUST. Agreed! If we want to deliver great software, we have to attend to building trust and relationship. The quality of interactions determines the quality of results. Here are five pragmatic ways to improve interactions (and therefore results) #1 Build a Foundation Invest in getting to know the people you will work with. Expand your relationship beyond strictly business transactions. Talk to people when you don't need something from them. And be willing to give as well as take. #2 Focus on Interests Rather than Positions A position is a proposed solution to a problem. An interest is as a concern related to why the problem needs to be solved in the first place. It's easier to find mutually agreeable solutions when you look for common interests rather than argue a position. #3 Seek Solutions Together Mutually developed solutions are always better received than imposed solutions. Let other people get their finger prints on the idea. #4 Communicate Face-to-Face Whenever Possible Face-to-face is rich communication medium -- we hear words and nuance, but also see facial expression, gesture, posture. Once we're removed from face-to-face communication, we have less to go on. And less to go on, means its more likely we'll mis-interpret. When a communication goes of track, move to a richer communication medium. (And work at untangling communication.) #5 Make a Generous Interpretation We make up meaning based on what we see and hear. So we might as well be generous. Making a generous interpretation of others actions gives more options for working effectively. Improving working relationships doesn't require group therapy or group hugs. But a little attention helps. Tweet this Post | | Wednesday, February 02, 2005
Boundary Manager
Susan Annunzio posts on the Fast Company blog: One of the most interesting findings of the Contagious Success research is that in high-performing groups, the leader "protects" the group from the larger company, whether lobbying for more resources or shielding the group from company interference. Sometimes this means bending company "rules" when they are getting in the way of performance. But good leaders use "intelligent disobedience" - knowing which rules they can break and which they can't. This fits with one role a ScrumMaster plays and corresponds with what Diana Larsen and I described as "Boundry Manager." (Download a PDF of the article that appeared in Software Development 8/2004 at Diana's site.) Annunzio goes on to say: But good leaders use "intelligent disobedience" - knowing which rules they can break and which they can't. Hmmm. And how does one know which rules you can bend? Look around the organization to see what happens when other people bend rules. You may get a sense of where the flex is -- but don't assume that just beacuse no one else has bent a rule that you can't. Use the "inform and move forward" method -- notify your boss of your plans to move forward unless he explicitly objects. Layout the consequences of following a rule in terms of delivering working software, then give your boss the choice. I've been in companies (not for long) where following policies and rules to the letter was a higher value than getting work done. Remember Rear Admiral Grace Hopper's advice "If it's a good idea, go ahead and do it. It's much easier to apologize than it is to get permission." Tweet this Post | | |