Friday, January 27, 2006
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:
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.
Andy and I have tried to think differently about publishing. We came to it knowing nothing about the industry. We did, however, know how to make projects work. So we took what we knew and applied the principles, if not the practices, to what we did.
Now other publishers are copying some of their innovations.
… 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?):
Your beliefs become your thoughts.
Your thoughts become your words.
Your words become your actions.
Your actions become your habits.
Your habits become your values.
Your values become your destiny.
(I’ve seen several variations on this quote. I came across this one in a workshop.)
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
Wednesday, January 04, 2006
Where have you been?
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.