Granting authority (and freedom) to someone doesn’t guarantee they will be empowered. If the environment is unsafe, or perceived to be unsafe, then the fear factor is likely to be too great for that person to speak up or take action. It feels like empowerment is something that comes from the environment itself. It’s constructed between people, by the actions they take individually in the (physical and mental) space they occupy.
Having the right environment is essential. When it’s safe and fun people are motivated by trust. They begin to demonstrate the courage to be creative and they take risks and make mistakes. An environment that tolerates mistakes to cultivate learning helps people face their fears and act decisively. And when people are able to perform freely they become energized and create a buzz.
Empowerment is not something that can be assigned. I can’t give you empowerment and you can’t give it to me. So don’t try to empower people. Concentrate on creating the right environment for people to construct their own empowerment and step back.
2 Comments
The definition of Empower is:
1 : to give official authority or legal power to
2 : enable 1a
3 : to promote the self-actualization or influence of
I agree, a system can empower people. How often, however, is that system present vs the scrummaster creating a subset within a larger, less empowering system? In that instance the srummaster is empowering.
There's another aspect to the concept: taking on responsibility. If you act on your empowerment you are also taking responsibility, "ownership". Two sides of the same coin in a lot of ways.
I've found that many people are reluctant to take on responsibility, to be empowered, in IT environments (or other corporate environments). The tendency is also for someone filling one role or another, to take on a quasi management posture. Perhaps it's the product owner. Given some of the definitions of the product owner role that I've seen that's not unexpected. Perhaps it's a senior technical person in the group.
In an ideal situation the scrummaster should be able to take the role of facilitating the group's activities. That's a very soft "hand" and much like what's written about in this post and the post about inconspicuous authority. That assumes an Agile environment already exists. The question is how do you get to that state.
That assumes, for example, that everyone feels empowered, takes on their responsibilities.... and that the scrummaster has defined those responsibilities and roles. A scrum has different expectations than a highly managed team.
Depending on the larger environment the scrummaster can need to take a pretty strong position. At the very least in terms of isolating (yes at times protecting) the team's self determination. In addition making sure everyone on the team understands their roles through real experience, not just reading or following rules.
I don't see much discussion of that, yet it seems to me that's an essential aspect to developing an effective scrum team. A team where everyone follows a set of rules is not going to be Agile. Agile will not happen until empowerment, self determination, responsiblity is taken on equally by all members of the team.
When that is accomplished, and the team delivers, then the concept of Agile/scrum starts to drive outwards into the larger corporate environment.
(I have no idea how this "comment as" works. ) Steve Kovacs wolfbyte@aol.com
Thanks Steve for your insightful comment.
The 'Comment as' is a feature of Google's Blogger and is basically asking people to identify themselves using a suitable account, e.g. Blogger or Wordpress, or by simply typing in their name or remaining anonymous. We'll be moving away from Blogger in the coming weeks because Google are discontinuing their ftp service.