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 |
Friday, January 27, 2006
You heard it here second
Thursday, January 26, 2006
Leadership and Management
Every so often, someone declares “We don’t need managers, we need leaders.” Statements like this imply that people are either one or the other, and that management is somehow less valuable than leadership. I don’t buy the idea that management and leadership are mutually exclusive or that one is more valuable than the other. Organizations need BOTH. John Kotter lists these different management and leadership activities in a number of his books. I paraphrase here: Management is... Leadership is... Effective people are able to do things from both lists. The emphasis may shift – more “leadership” actions and behaviors in some positions and situations, more “management” actions and behaviors in others. I’ve worked with people who were all “leadership.” When they lacked management behaviors – follow-through and attention to practical implementation --they left chaos in their wakes (and didn’t actually produce much useful change). I’ve worked with people who were mostly “management.” And in some cases, it worked okay, as long as they had enough personal warmth to navigate human relationships. (In accounting areas, you don’t necessarily want creative ideas or big charisma – think Enron.) | Friday, January 20, 2006
Congruence between practices and culture
Two bits that I came across in my reading this week are sticking together in my head. In his post, Imitation is the Saddest Form of Flattery, Pragmatic Dave talks about other publishers imitating what they do at the Pragmatic Bookshelf.
Dave continues: … surface-level imitation is flattering, but ultimately it’s unlikely to succeed. Behind the stuff that you see us doing, there’s an underlying philosophy and set of practices. They all reinforce each other. Then I came across this in an old entry in my journal the other day (Aren’t journals wonderful?): Here’s how these two pieces are connected for me: A while back, I talked to a group that implemented the workflow of Scrum. The applied some of the visibility practices. The teams aren’t self-organizing or applying inspect-and-adapt practices that work with, and reinforce the workflow part of Scrum. They’re missing some of the practices I associate with Agile software development. And, practices are built on principles. Principles are an expression of beliefs and values, as is corporate culture. From what I’ve gleaned, many of practices this company isn’t doing rest on values that are outside of the dominant culture of the company. It doesn’t make sense to transfer practices without examining fit. Some practices may transfer well within the existing culture and others won’t. The reinforcing effect that a set of practices have won't be there. And the effort, energy, and time involved in changing culture isn’t trivial. The benefits of a new practice may not outweigh the cost of culture change. (This assumes that existing practices are achieving acceptable ROI for the company—which in many cases of top-down, mandated adoption of Agile methods seems not to be the case.) | Friday, January 06, 2006
Supporting Organizational Change
Here's my article in CrossTalk on how managers can support organizational change (adopting/adapting Agile methods, for example). | Wednesday, January 04, 2006
Where have you been?
Well, first I was on the road, then my dog fell ill, then I was on the road again, and then it was the holidays and I went skiing. And now I'm back for a bit. | Observations on Corporate Culture and Agile Methods Adoption/Adaptation I see (and hear about) more and more companies that are jumping on the Agile bandwagon. All too often, a top managers direct the organization to implement Scrum or another Agile method. Sometimes implementing Agile top down succeeds in establishing the a few engineering practices or the workflow changes – they create a requirements backlog, and start having release and iteration planning meetings, and maybe something that looks like a stand up meeting (sort of). But the organization struggles, and pretty soon bits and piece of the Agile method fall away because “they don’t work here.” (Which is different from deciding which practices to adopt to solve the most pressing problems.) This sort of top down implementation often ignores one of the core factors involved in implementing Agile methods: Culture. (Structure and systems are an issue, too, but that’s for another time.) Culture has to do with how people use power, how people treat each other, beliefs and practices about motivation, and values. Here’s one lens to look at types of culture: Power cultures rely on control over the currencies of power – money, privileges, promotions, assignments, working conditions. Motivation is via rewards and punishments. Leadership resides in the person – and his/her ability to control access to resources and mete out punishments and rewards. When it works well, the upside of Power cultures is responsible, benevolent (and often paternalistic) leadership. The downside is abuse of power, political infighting, and rule by fear, where people spend their time and energy keeping their heads down. Bureaucratic cultures use procedures and structures to organize and control people and performance. Roles and duties are clearly defined and bounded, as are rewards. Each level and part of the organization has a defined set of responsibilities and authorities. The upside of Bureaucratic cultures is stability and efficiency – as long as the external environment is also stable. When circumstances and influences aren’t stable, Bureaucratic cultures have a hard time keeping up with rapid change. (Every so often, I hear someone complain, “We can’t move the boxes on the org chart fast enough to keep up.” This is the sound of a Bureaucratic culture falling behind in a high change environment.) Both Power and Bureaucratic cultures assume that people can’t really be trusted and therefore, attempt to control them so they don’t do something stupid, and manipulate them so they don’t slack off. Achievement cultures hold a belief that people like their work and want to contribute – rewards are intrinsic to the work. The organization has a clear purpose, and people willing sign on to achieve that goal. People make decision in reference to the overall mission/purpose rather than in reference to a person who has power. When the work, Achievement cultures are high-energy and exciting. People seek out what needs doing and do it. The downside can be under-organization (which people compensate for with “can do” attitude) and burnout. Relationship cultures value the humans who work there: people aren’t just cogs in a production machine. People come to work because they care about the people they work with, and feel cared for by their co-workers. People communicate openly, cooperate, and help each other out. Relationship cultures can feel wonderful… and they need a dose of Achievement culture to stay results oriented. On the downside, Relationship cultures can be so conflict averse that people sweep serious problems under the rug. Most companies have a mix of these cultural characteristics, or have pockets of different culture with in the dominant culture. In my experience, a mix of Achievement and Relationship cultures is more conducive to Agile methods—it's a natural fit. OTOH, it’s an uphill battle to introduce Agile methods in a Power or Bureaucratic culture because the values and principles behind Agile methods are at odds with the values of the dominant culture. That doesn’t say you can’t use Agile methods in those cultures; Agile may thrive in pockets within a larger Power or Bureaucratic organization. But widespread adoption/adaptation of Agile methods will work better with attention to shaping the culture to support Agile principles and values around self-organization, collaboration, and adaptation. | |