Ichak Adizes, in his 1976 paper on Mismanagement Styles, identified four roles that a manager needs to play.  A good manager is able to play all four roles (with some roles better than others). A mismanager is only able to play one of the four roles. Based on this, Adizes arrives at various styles of mismanagement. In this post, I’m going to take a look at these mismanagement styles in the context of managing an agile team.

The four roles

According to Adizes, a manager should be

• A producer: Understand the functional and technical know-how to turn out maximal results
• An administrator: To implement a system to achieve those results and keep it running
• An entrepreneur: To initiate new directions whenever opportunities or threats arise
• An integrator: To harmonize individual goals into group goals and individual results into group results

When a manager only performs one of these roles, mismanagement results.

Mismanagement Style #1: The loner

The loner is a manager who is only a producer. The loner is very industrious and knowledgeable, but his main fault is the compulsion to do everything himself. He does not trust anyone else to do anything.

You sometimes see the loner in an agile team. This person is experienced but is the typical solo programmer. He has picked up all the difficult tasks for himself. He doesn’t have time to help others in the team get up to speed. A common complaint of his is that the rest of the team is dragging him down. The loner is often overburdened. Tasks and features are only half done because he doesn’t have the time to do them all.

The micromanaging PM also falls into this category. The micromanager does not trust anyone else to get something done unless they are involved in the task.

Mismanagement Style #2: The bureaucrat

The bureaucrat is a full time administrator, unable to do anything else. The bureaucrat knows the standard operating procedures by heart, more concerned with how things are done rather than what is done. He considers himself the guardian of the system, and primary commitment is implementation of a plan, regardless of its wisdom.

Sometimes the ScrumMaster does down this line. Everything must be done exactly by the book, no matter the results. If results are poor, the result is more procedures and more bureaucracy. Compliance is his favourite word. If the organization has a process group, then they can end up becoming bureaucrats too.

Mismanagement Style #3: The crisis maker

The crisis maker is a manager who is exclusively an innovator. The crisis maker charges ahead at all opportunities simultaneously. Every day it is a new idea on the horizon, even before the old idea has been implemented. The crisis maker changes direction constantly, without making progress anywhere.

Often times stakeholders can become crisis makers for the team. Everyday is a new “simple feature” to be implemented. Even before it is out in production comes another new direction, and another. Meanwhile the project has made no progress towards its goals, only a bunch of half implemented features lie on the floor.

Mismanagement Style #4: The superfollower

The superfollower is great at bringing together people, but nothing else. There is nothing he wants to achieve except the role of conflict resolver. The superfollower has no ideas of his own, and is unable to ensure that ideas get executed upon.

The superfollower is somewhat rare in agile teams. I’ve not seen anyone who really fits into this category. Superfollowers are more common higher up in management where initiatives cut across department boundaries. Have you seen this archetype in your agile teams?

Summary

Have you seen these mismanagement styles in agile teams? Put your experiences in the comments below.

There is a discussion going on in one of the Scrum lists about compensation in a scrum team. How do we reward individual performers when Scrum plays down individual performance?

It’s a mistake to think that rewarding individual performers does not work in a Scrum team. Forget Scrum, it does not work anywhere in the organization!

As much as thirty years ago, Deming listed as Deadly Disease #3 – Evaluation by performance, merit rating, or annual review of performance

This is because performance evaluation kills cooperation, morale and intrinsic motivation. Individual performance appraisal in particular can kill team cooperation. Why should I share knowledge if it would improve other team members appraisals relative to mine?

A particularly bad thing to do is stack ranking, i.e ranking everyone in order from best to worst. In a competitive environment, there are two ways to win – get better or keep others down. Which one is more common? The easiest way to get to the top of the stack is to keep knowledge to yourself.

Now, are these the kinds of behaviour that organizations want to encourage?

Consider this Harvard Business School case study on Hewlett-Packard.  When HP moved to a pay-for-performance system in the early 90s, this is what happened

The teams were frustrated that factors out of their control, such as the delivery of parts, affected their work. The high-performance teams often refused to admit people whom they thought to be below their level of expertise, leading to disparities among the teams. There was reduced mobility between teams, preventing the transfer of learning across teams. Employees built their lifestyles around the higher level of pay, and were angry when they could not achieve it consistently.

The case study also says “pay-for-performance can cast a pall over self-esteem, teamwork, and creativity” and “scholars have argued that the real problem is that incentives work too well. Specifically, they motivate employees to focus excessively on doing what they need to do to gain rewards, sometimes at the expense of doing other things that would help the organization.”

More recently, Jeffrey Pfeffer testified in the US Congress on Personnel Reform. He said in his testimony,

There are numerous examples of widely diffused and quite persistent management practices, strongly advocated by practicing executives and consultants, where the systematic empirical evidence for their ineffectiveness is just overwhelming. Third, the idea that individual pay for performance will enhance organizational operations rests on a set of assumptions. Once those assumptions are spelled out and confronted with the evidence, it is clear that many — maybe all — do not hold in most organizations. Fourth, the evidence for the effectiveness of individual pay for performance is mixed, at best — not because pay systems don’t motivate behavior, but more frequently, because such systems effectively motivate the wrong behavior. And finally, the best way to encourage performance is to build a high performance culture.

Finally, a quote from the classic Peopleware book,

Internal competition has the direct effect of making coaching difficult or impossible. Since coaching is essential to the workings of a healthy team, anything the manager does to increase competition within a team has to be viewed as teamicidal. Here are some of the managerial actions that tend to produce teamicidal side effects:

• Annual salary or merit reviews
• Management by objectives (MBO)
• Praise of certain workers for extraordinary accomplishment
• Awards, prizes, bonuses tied to performance
• Performance measurement in almost any form

Another book that comes to the same conclusion is Alfie Kohn’s Punished By Rewards.

Coming back to agile teams, here is a must read article by Mary Poppendieck on the subject – Unjust Desserts (PDF)

There is no way to succeed without good teamwork. Agile requires a collaborative environment in which a cross-functional team can work together. So here are five articles on teamwork from an agile perspective.

• Agile, Multidisciplinary Teamwork: A good article on how to get a diverse cross-functional team to work well, keeping them energized and productive.
• Seven Essential Teamwork Skills: Seven soft skills that every team member need – Active Listening, Questioning, Logical Argument, Respecting, Helping, Sharing, Participating.
• The Seven Pillars of an Agile Team: What are the abilities that team members need to posses? Product Sense, Collaboration, Focus on Business Value, Supportive Culture, Confidence, Technical Excellence, Self Improvement.
• How Not to do Resource Management: An excellent article on creating agile teams: Instead of assigning people to a project, keep the team constant and assign projects to the team.
• Meeting Facilitation for Agile Teams: Facilitation skills for meetings, retrospectives, standups and planning workshops.

I gave a talk on programmer spaces in the recently concluded Chennai BarCamp. During the presentation, the conversation moved to actions taken by managers that ended up having unintended consequences.

Linear Mental Models

Mental models are models that we have based on which we take decisions.  A linear mental model is a model where an action causes an outcome. This model is shown below

For example, we could say that working longer hours leads to more work done. In this case, “working longer hours” is the action and “more work done” is the outcome. Using this model,we can work in reverse and determine the action that will cause a given outcome. So if “more work done” is the desired outcome, then “working longer hours” could be one possible action to cause the outcome.

Most managers intuitively apply linear models to determine the actions required to drive the system towards a desired outcome. Here are some examples

• Desired outcome: More work done. Action: Work longer hours
• Desired outcome: More work done. Action: Add more developers
• Desired outcome: Improve performance. Action: Introduce competitive bonus structure

Circular Models

Unfortunately, most systems are not simple cause -> effect structures. A cause may have side effects which are not accounted for in the linear model. The outcome could also have a feedback which works against the original goal. The model looks something like this

Lets take an example to illustrate. Our desired outcome is to get more work done. To achieve this, we tell the developers to work longer hours. According to the linear mode, working more hours should get more work done. But there is a hidden side effect: Developers get mentally and physically tired. This side effect is not taken into consideration in the linear model. The outcome of the developers tiring is that they start to get less work done per hour. Thus, the side effect impacts negatively on the desired outcome.

The red line indicates that it has a negative effect on the outcome. The developers are not tired to start with, so output shows an initial increase, causing people to believe that the decision is working. But developers keep getting tired as time goes and the desired output keeps dropping over time. After a point output falls below the initial value.

Once output drops, what does the manager do to increase the output? Work even more of course! Which only makes matters worse. This is the problem with applying a linear mental model to systems that have circular models.

Unintended Consequences

As in the previous example, applying a linear model to systems with circular models leads to decisions that can have unintended consequences. The intuitive response in such a situation is to push harder on the original action, but as shown above, this only makes matters worse. The correct response is to try to understand the entire model and work on the side effects and feedback effects. In future blog posts, I’ll talk about various examples of situations where a given action caused unintended consequences.

Pradeep has a really nice presentation on interviewing candidates. It focuses on interviewing testers, though many of the principles can extend beyond that.

One of the points that has always baffled me is how the candidate is never asked to actually do anything. Instead they are asked a whole bunch of meaningless questions. I’m constantly reminded of this quote from Peopleware:

Circus Manager: How long have you been juggling?
Candidate: Oh, about six years.

Manager: Can you handle three balls, four balls, and five balls?
Candidate: Yes, yes, and yes.

Manager: Do you work with flaming objects?
Candidate: Sure.

Manager: … knives, axes, open cigar boxes, floppy hats?
Candidate: I can juggle anything.

Manager: Do you have a line of funny patter that goes with your juggling?
Candidate: It’s hilarious.

Manager: Well, that sounds fine. I guess you’re hired.
Candidate: Umm … Don’t you want to see me juggle?

Manager: Gee, I never thought of that.

In my previous company we made candidates actually write some code. We would give them a simple program to write in half an hour and they could use a computer to code it. They had access to online help, so they could check up on syntax. And sitting in front of a computer allowed them to work in a natural environment. This process of selection worked out pretty well for us. I’ve always wondered why more companies didn’t do that. Any ideas?

If you have been even half alive in India over the past month you would definitely have seen the IPL. I think one thing that the IPL proved was the importance of the team and man-management. It’s not the rock stars that matter, but the team that plays best together. Throughout I was thinking about the agile philosophy of valuing the team over individuals. Check out this fantastic interview with Darren Berry, director of coaching at Rajasthan Royals where he talks about their management style:

http://content-ind.cricinfo.com/magazine/content/current/story/353445.html

Some snippets:

Q: What was the role of the coaches, or man managers as Warne calls them?

Berry: The key to our success was our man-management early: we got all the players in one-on-one and I tried to understand them, what made them tick. What happens normally is, a lot of coaches tell people what to do but you’ve got to actually understand what motivates them.

Q: How difficult was it to build a winning unit in such a short time?

Berry: Very difficult, no doubt. It’s about making people feel at home and part of the family. Having spoken to a lot of Indian players, we realised that within their first-class cricket there are different levels of hierarchy, whereas what we had was the biggest name in world cricket sitting next to Dinesh Salunkhe, who is not even a first-class cricketer. You can’t measure how much that made people grow.

Q: There was this unique sense of camaraderie among the Royals. You seemed to be able to make the players believe they were one family?

Berry: I believe that was the difference between us and the rest of the sides. It’s an immeasurable thing but it was important. During a mini-break in mid-May, when some of us foreigners went to Goa to relax, Asnodkar, who is a native, invited us to have dinner at his family home one night. Warne, Shane Watson, Graeme Smith, myself and Snape got into a car and drove 45 minutes to Swapnil’s house. His parents were there along with his grandfather, who came up later and said, in Hindi, “I can die a happy man. Shane Warne sitting in my lounge room …”

When Yusuf Pathan was selected for India, we all gave him a standing ovation because we all felt part of it – we felt that this tournament launched him to higher levels.

There was Zahir, our bag man. He lost his mother during the tournament, but he stayed on with the side. We wore the black armband in respect. He was important, too. Before leaving to go home he came to my room crying.

You can’t quantify emotions and passion in people. It all has to do with trust, honesty and respect, and you only get that if you treat people fairly, evenly.

Q: In any team environment participation from all sections is the key to success. How did you deal with differences of opinion?

Berry: From the Indian perspective, I don’t think there were any big egos in our side, and that might’ve been another strength. As for internationals, Graeme Smith and Shane had differences when they played against each other, but here they sat together having Coke as best mates.

Q: Was your dressing room full of whiteboards, overhead projectors, flip charts?

Berry: It was pretty simple – minimal. We had a whiteboard with four or five points for each game. Our team meeting on the day of the game would average between 15 and 30 minutes. Some teams met for two hours and did video analysis and all that. That definitely was not Warnie’s style.

One of the best posts I have seen in a while. Cory Fox on what matters more, people or process:

It’s a good question. I saw good code at places with crappy practices. And I saw crappy code at places with good practices.

But in almost all of the places, I saw code that was on par with the motivation of the teams in place. In other words, teams that were excited about what they were doing, and kept up with trends, etc, often had code they were proud of. Teams that liked their job, but basically were just there had code that worked and had issues, but they didn’t mind. And teams that were just in a crappy place had code that was crappy.

One of the more important aspects of general management is facilitating meetings. It’s rather surprising how boring most meetings are. Given the frequency of occurrence you would have thought that people would have gotten pretty good at it. But no, most meetings are dull, boring and go on for far too long.

The ability to have good meetings becomes even more important when doing agile software development, because there is a lot more emphasis on social interaction when compared to traditional processes. Indeed, one of the core skills of being a good Scrum Master, Coach or Project Manager in an agile setting is to be a good facilitator. Almost all agile processes have a meeting to plan the iteration (eg. Sprint Planning meeting in Scrum), a daily standup meeting and a closing iteration retrospective or reflection meeting. Key to the success of agile is the ability to keep these meetings short, interesting and productive and thats where the facilitation skill of the Scrum Master or Project Manager comes into the picture.

As a result, I’m always on the lookout for good, interesting articles and books on meeting facilitation. Here are some ideas, click the link name to go to the original article.

Meeting Facilitation

Meeting Facilitation: This is a nice link on meeting facilitation. Apart from the usual advice like keep an agenda, create action plans and manage the time, this link also has a few interesting snippets.

Pick a large, open spot where everyone can sit down in a big inclusive circle, leaving room for the inevitable straggler or two.

This is a good one. The arrangement of the seats has a big bearing on the type of discussion. A typical conference room arrangement is rectangular or oblong, and the project manager tends to occupy the head of the table. This arrangement will lead to a status report type discussion, where others ‘report’ to the head. On the other hand, a circle tends to lead to a more open discussion.

With the raised hand & speakers list system, it is a challenge to maintain order and efficiency without stifling the flow of discussions. An excellent tool to address this is The Levi Hand Signal Technique (LHST). The LHST allows meeting participants to register their intent to make two distinct kinds of comments: those that are directly in response to someone else’s comment (‘reactive comments’) and those that are separate thoughts (‘unique comments’). Intent to register a reactive comment is signalled by a different hand signal than is intent to register a unique comment. We used an index finger for the former and a full hand for the latter.

An interesting technique for maintaining the flow. In a meeting, it is very easy to go off topic as one point leads to another. Before you know it, you are far away from what you started with. At the same time, you don’t want to inhibit the discussion by repeatedly cutting off people.

Read the full article: Meeting Facilitation

Agile Retrospectives

Agile Retrospectives: This is a book actually. It’s about conducting the end of iteration retrospective meeting (also called reflection meeting). Retrospectives are used to assess the iteration that just ended and how the team can learn from it. Unlike typical meetings that have a fixed agenda, retrospectives are more exploratory and free form. Therefore you need more right-brain activities to bring out the data and analyse it. However, exploratory does not mean unstructured. The book presents a retrospective framework as follows:

1. Set the stage
2. Gather data
3. Generate insights
4. Decide what to do
5. Close the retrospective

The book then goes on to describe a number of activities for each stage of the framework.

Read about the book at Amazon: Agile Retrospectives

Innovation Games

Innovation Games: Yet another excellent blog post by Mike Griffiths. I’ve linked to Mike’s blog before and he has a lot of good stuff on it, so head over and read the rest of his blog as well. Okay, coming back to the topic, this particular blog post deals with innovation games during iteration and release planning. Agile retrospectives laid a framework for the end of the iteration. This one has activities for the start of the iteration. The blog post presents three activities from the book Innovation Games by Luke Hohmann. The three activities are

1. Remember the Future
2. Shape the Product Tree
3. Sailboat

Using these three activities, Mike shows how you can gain a deeper understanding of the project and how to break down features for releases such that they are logical and coherent.

Read the full article: Innovation Games

Patterns of daily stand up meetings

Patterns of daily stand up meetings: We’ve talked about general meetings, iteration retrospectives and iteration and release planning. That leaves the stand-up meeting. The team will be having this meeting every day of the iteration, so it is important to make sure that it is really short and useful. The last thing you want is for everyone to get irritated with a long, boring meeting every single day right? That’s why this article by Jason Yip is so useful. The article mentions several patterns and anti-patterns of the daily stand-up. If you think there is scope for improvement in your stand-up, take a look at this article and see how you can improve it.

Read the full article: Patterns of daily stand up meetings

Summary

Thats four ways to improve your meetings. One for general meetings and one each for the iteration plan meeting, the daily stand up and the retrospective meeting. Apart from these, there is a lot of literature on structured approaches to meetings, decision making, meeting facilitation, creative planning and problem solving. While these are aimed towards general management, they are often just as useful for agile teams as well. So if you see something that you think might be useful, don’t be scared to try it out a few times and then see how it works out.

In an organisation you often hear about the “business side” and the “technical side.” The business side includes roles like management and business analysts, while the technical side includes development and testing. The terminology of the “business side” and “technology side” is the worst possible thing that can happen in a company because it deepens the divide between managers and developers and ends up creating an us vs them situation. [More about that here: Managers and developers: Are you two teams or one?]

As someone said in an email discussion, there is no “non-business” side. Everyone working in a company is on the business side in some form or the other. Developers are on the business side by developing products that help the business. Managers are on the business side too. Don’t get fooled into thinking that only a small group of people are on the business side. Everyone is on the business side — and if not everyone should be.

Does your company have a “non-business” side?

I was discussing estimation of software projects, when it hit me that in many unfortunate organizations, estimates are not about reality, but about politics. Really, how often have you seen a discussion like this -

Manager: How long will the whole thing take?
Dev: Depends on the requirements and if they change. We’ll estimate on a 2 week basis. That way we can keep the plan close to reality and also adjust easily if requirements change.
Manager: We need to give the board a date
Dev: We can go through the requirements, but the final date will be very uncertain at this point
Manager: Doesn’t matter, lets just fix a date

<do some estimation and come up with some date>

Manager: We cant have that date, the board wants to have it done by the end of the year. Lets just cut the estimate to fit it in.
Dev:

<after one week>

Client: We’ve had some project changes here, so use this new requirements document
Manager: Sure.
Dev: We need to restimate all over again
Manager: Lets not, I’ve already committed the date to the board. I’m sure you guys can do it.

<at the end of the year>

Manager: So are we done?
Dev: No, we are about 40% there
Manager: What?? Your estimating sucks. What do I tell the board now? That you screwed up?

Amazing isn’t it? We’ve all been in situations where managers are more interested that the date be something that makes them look good than they are in having the date be realistic. If that is the aim of the estimate, then who can complain when the estimates are missed?