What do Managers do in Self-Directed Teams?

There's a lot of buzz about Self-Directed Teams these days. The concept is very revolutionary and self-evidently beneficial as long as you are not the manager of the team. Think about it, suddenly a team is self-directed - everybody knows what they are supposed to work upon, they pick their work, solve their own problems, meet every morning and update the team of the contributions to it, etc. The team members are very conscious about the business value they are delivering and have managed to get the communication channels set up within the team and built bridges across to the business. Utopia, isn't it? Well, for some it might not be, or so it seems. Put yourself in the shoes of the person who was until a few weeks back was managing this team and ensured that all these things happened. But now, these have started to happen and it is all being managed by everybody. So, the big question this person has is, "What do managers do in self-directed teams?"

Now that the team members are doing what I did day-to-day, what's my role?

Do we need Managers anymore? If this concept of self-directed team is a reality at all (some actually doubt the feasibility of it), then what might possibly be out there that they can't do on their own and would need a manager for? If I am a manager for a team that is on the path of becoming self-directed, how can I save my job? What should I as a manager be doing next that might be valuable?

Some of fronts on which I have seen self-directed teams needing help are:

• Leadership - While the teams is busy managing their own internal affairs, there's some shepherding still required to lead the team in the right direction, which is aligned with the vision and mission of the company. There's a good blog-post I found that very aptly describes the differences between sheep herding and shepherding.
• Removal of Barriers - Barrier Busters: As much as it seems to be non-issue, it is. Teams that are solving cutting edge problem and busy developing solutions for tomorrow, are surprisingly also very poor at removing barriers on their own. It is not because they don't want to, but more often than not it is because their barriers are non-typical. They can be anything from regulatory, trade, and market barriers to politics, bureaucracy, etc. Teams involved in technology generation are usually not very interested in speding their time in these kind of issues.
• Facilitation and Co-ordination
• Development of Staff - Training and Mentoring: Often overlooked and seldom undetook, training is very important. I'd recommend everyone to read The Cycle of Leadership by Noel M. Tichy. Read more about the book at: http://www.noeltichy.com/cycle.html
• Driving Innovation - Innovation today is what strategy used to be until a few years back. You need to be on the bandwagon of innovation. Needless to say, it requires a certain amout of experience and familiarity with the business, a deep understanding of the tools of the trade, courage, and bandwidth of time and resources.
• Sharing Lessons Learned with rest of the Organization - Amongst large companies that are out there the difference between really successful and barely sustaining ones is the difference between their middle managers. In companies where middle managers are messengers of lessons learned and different successfully implemented ideas there is a certain robustness, pride, and confidence. GE is a good example of this model. It's a big job and requires tireless efforts on behalf of the middle management, but seldom picked up by middle managers.
• Continuous Improvement - There are very few teams that like change. Once they have stablized they, infact, resist change. And then there are some changes that are not very pleasant to think of, at least on the onset. e.g. a change to move the team from the wasteful office cubicle layout to open space configuration. A team needs a manager to make such decisions and also to identify other things that can be improved.
• Process Czar - Let's not forget that no matter how self-directed a team is, it'll start to cut corners. It is a manager's job to to make sure that the processes that the team has chosen are being followed by everyone and if not, then to figure out the reason(s) and modify the operating guidelines.

I would also like to encourage the readers to share their experiences, observations and opinions on the role of middle management in their organizations. Please feel free to comment on this post.

Image taken from: http://www.toothpastefordinner.com/070806/manager-set-list.gif

Mingle is Out!

A few month ago I wrote about the importance of a card wall in agile software development projects and the value it brings to iteration and project management. It can be found at: http://bizvalu.blogspot.com/2007/03/card-wall-its-not-reversion.html . There were some comments around the wall being impractical or not suitable for distributed teams or if the team is too large. In my discussions with a project manager recently, it again came up and he expressed his skepticism of card wall specially if managers are working remote or travel frequently.

Thoughtworks (http://www.thoughtworks.com), which is a leader in agile software development, specially distributed projects has released a project management tool called Mingle that is an electronic version of the card wall and is configurable to mimic any variation of a physical card wall layout.

I would highly encourage you to take a look at the tool. You can sign-up for a trial here and see small and quick videos of its features here. Apart from being able to generate your own tags, that serve as meta-data for the cards, and linking code to requiremetns, Mingle generates some of most effective metrics that I have ever seen.

What's your velocity?

For the past couple of years I have been working in teams that measure their productivity and throughput using a term called "Velocity". For a team that is engaged in software development and delivery every story is estimated at certain points worth of effort that is required to complete the story. The sum total of points for an iteration's completed stories is the team's velocity.

It's all about Development

The velocity of a team is its development velocity. That means it only measures the throughput and productivity of the development effort. There are no measures of these parameters for the QA and BA teams. Some of the practical constraints are that these groups are not as insulated as the development group and neither as ideally served. By that I mean that the Development group in an iteration is bound by the time of two weeks to finish their effort and are provided the material (stories) to develop from. So it makes it easier to measure their velocity and the number reflects the nature of a very controlled environment. Business Analysts on the other hand don't have this controlled environment. They have to interact with users and business outside their immediate sphere of influence and control. So the Business Analysts are not bound by iteration length for analysis. They can take anywhere from 1-3 weeks to analyze a story. And it is true for the QA groups as well. So, the problem is that Business Analysts and QAs have no idea of their velocity.

Is that a problem. My answer would be, "it depends". As long as the development team has enough work to do with just the right inventory of stories on which they can stretch if they finish their work early, who cares. On the other hand, there are some who'd want to know their throughput. So, there has to be an indicator for Business Analysts as well. Estimating the Unknown The problem, however, is the concept itself. Velocity is computed from the estimates that are reflected by the developers based on the story details. In case of the Business Analysts, they don't have anything to estimate. They are in the business of creating something that can be estimated. So, the big question is, "How can the Business Analysts estimate their analysis"? The second question is, "Should they even do it?".