Archive for September 2007
Now that the team members are doing what I did day-to-day, what's my role?
- 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
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?".