Heading up the AgileAustin workshops I get to meet with a lot of passionate Agile practitioners working in the real world. What I find amazing is how we all have similar experiences and common challenges. Below are some of the common themes I’ve observed from my own career and also from talking with other ScumMasters, maybe you’ve seen the same thing:
Adoption
This is the holy grail question of anyone looking to start going Agile, “How do I get adoption at my company?” Adoption is best started at the ground level (according to Ken Schwaber). The reason he identifies this is because of command-and-control (what I call ‘old-school management thinking’). Teams who are under command-and-control only act when they’re told to, and don’t take the initiative on their own. Also managers who practice command-and-control believe it is their job to provide the team with answers (both what and how), instead of waiting for the team to figure out a solution on thier own (and that includes making mistakes).
Understanding the New Roles
So if it isn’t the role of the manager to provide answers, what is their role? The role of a manager in an Agile organization is that of a servant leader. Their job is less about control and more about service — you help remove impediments to the team. A good servant leader values collaboration, trust, empathy and the ethical use of power. Your primary objective is the enhance the grow of individuals, increase teamwork in the organization and personal involvement.
Product owners are responsible for prioritizing and organizing the backlog (a list of features to be completed). They develop acceptance criteria so that the team understands what is required for a feature to be considered “done” and they work with the team to estimate the features (usually by size). They own the “what” question (what should be built, what’s most important or not, etc) and define releases.
In an Agile organization the Product Owner is the “single wringable neck.” This is to say they’re ultimately responsible for the product’s success or failure. The are probably the most important individual on a Scrum team since they decide what features get built and thereby set the direction of the team.
Team members, other known as ‘pigs’ (because they are committed to doing the work), are responsible for selecting the work they take on. They do so inside a time-box, meet frequently, and at the end demonstrate their work. The team is responsible for the “how” question (they own the implementation details, design, etc).
Anyone else is a ‘chicken’, that is someone who contributes but isn’t committed. (Mike Vizdos has a great cartoon explaining the pig and chicken metaphor). Chickens can be anyone from an outside consultant or subject matter expert to a CEO. They might attend the daily meetings with the scum team, but they are not participants in these meetings (because they’re not committed to the work).
Assuming it’s About Developers
These role changes are often not fully embraced or recognized. Organizations might take some steps in the right direction: they create a backlog, they move to 1-2 week sprints, they might even have daily stand-ups and demos/retrospectives. Scrum is more than just an adjustment to the lifestyle of the developer. Their needs to be a strong product vision that everyone understands and is behind. Concensus is very important, people who are not sold on an idea are not going to put their passion into the work.
This is where leadership needs to inspire (not measure) everyone on the team to the goal set before it. The team has to be self-directing and encouraged to self-organize to reach it. Scum is about changing how your organization approaches problems and comes together to work as a whole team – manager, product owner, and the scrum team. I recommend Jean Tabkia’s Collaboration Explained for some exellent inight into teams and how they work.
If there is a manager-type stomping around telling people how, what and when to get things done – you’ve missed the boat.
Individual Performance Evaluation
The last big impediement I often observe is what I call ‘team self-destructive behaviors.’ These are agile anti-patterns that primarily come from old-school management philosophies and lack of education about teamwork. Some of these ideas are: workers are inherinantly lazy, workers need to be told how to properly do their job, worker productivity equals hours worked, etc. What ends up happening in some organizations is that managers task out the work for the team, will estimate it for them, and even sometimes assign tasks to specific members. (In short, the team is deprived the ability to be self-directing and self-organizing).
Any behaviors that focus on the individual and measures individual performance, rather than the team’s performance, are counter productive to building a good team! When you value individual performance a strange rivalry is born between team members which stops them from working as a team. For example: Steve and Bob are both working on different features. The feature Bob is working on is highest in priority. Steve finished his feature early – instead of helping Bob with his, he moves on to another story to show Bob up and make himself (Steve) look good to the management. The sprint ends without Bob finishing the most important feature.
Ester Derby wrote an interesting article about performance and appriasial. She suggests that the idea of ‘merit pay’ should maybe fall out of style. We don’t want to reward people for knowing how to work within the system, we want to reward people for improving the system.
