How to manage agile (self managing) teams

Some time ago I read an interview with the founder of a high-growth web 2.0  company. It went something like this. 
“How do build your team?”
”Oh, I get the best people I can and get out of their way”image

Ahhhhhh! At one time, this sounded so true. I felt that my managers where hindered me from doing my work, just get out of my way. Now I couldn’t disagree more.

Some time ago I asked one of the managers about the ABC team. S/he answered, oh, they are doing fine, they are heading forward at great speed. They don’t need my management. They are a self managing team. I don’t want to touch that team, it is working, and anything I will do will just disturb.

The first question that popped into my mind was: Ok, so why do I need you? What value are you adding?

So how do you manage self directed teams?

(hint: The team does need a manager)
  1. Even a self-directed team can get off target, or become complacent, or lose motivation, or lose velocity. A lot of things can happen that can have a negative impact on the team’s performance, and the manager needs to be there to course-correct.

    A perfectly humming self-directed team that is aimed squarely at the target? Sure, let them run. But that sort of accuracy is probably not achievable for the lifetime of the project.

    In addition, the manager absolutely needs to be there to run interference for the team. The manager needs to be actively removing obstacles from the team’s path, be they political obstacles, or bureaucratic, or whatever.

    There’s a role for a manager. If there isn’t, they you’ve either got an all-star dream team, or a terrible manager.

  2. Thanks Chris,
    I think that the manager is not an obstacle remover, quite the opposite, I think that the manager should make sure that there /are/ obstacles in the teams path.
    The manager must lead the team, into the obstacles and show the team how they can make a ‘breakthrough’, and overcome those obstacles. This will make the team grow.

    Fix the Bug that everyone is scared of.
    Refactor the legacy code
    Make sure that they do unit test HttpContext

  3. Thanks Raoul,
    Those are a great read, and pretty old too. 1999-2005

    I always believed that a manager should spend more time with his best people and best teams. If a manager is ignoring his best team and not spending time with them, what value is he giving the team, why not cut the management layer?

    BTW, the manager was far from useless and added loads of value on other teams and personally, just not on that particular team

  4. I was referring to bigger obstacles Eli 🙂

    A more proper way to put it might be to say, I expect the manager to be removing non-coding obstacles so that the team can focus on solving software-related problems.

    This may not be an issue for the teams you work on, or the projects you work on, but at my current position it’s a big deal. I work for a government agency and I’ve been absolutely blown away by the amount of bureaucratic and political obstacles that have been put in our path. And to my manager’s credit, s/he does a good job of bulldozing most of that garbage out of our way so that we can focus entirely on code.

    As an example: a lot of problems can be solved multiple ways. Sometimes the software solution to a problem is overly complex, and the better solution is a personnel change, or a policy change, or a change in the way a task is performed.

    With a policy change in place, the software can be written in a leaner, simpler fashion with fewer bugs. The policy change represents a non-coding obstacle, and I find it a complete waste of time and money for a software developer to get involved with that.

    This is where I see value in the manager for this role, because s/he can take that problem off the developer’s shoulders and get it handled; get to the right people, make the right arguments and get the policy changed.

  5. Sure.

    Example: You’re writing an application to track employee’s time, so they can get paid. The company wants to move away from a paper timecard process to an electronic one, hoping to save time and money on the process of calculating employee pay.

    The software team analyzes how the company currently handles pay periods and determines that it would be quite complex to implement some of the overtime calculations and comptime calculations because the company currently pays its employees once a month, on the last day of the month.

    Difficulty number one is that overtime and comptime are calculated on a work-week basis. Each work week starts on a Sunday and ends on a Saturday. But months do no conveniently start on Sundays and end on Saturdays, nor are they all 28 days long. This creates a problem because employees don’t finish a full 40 hour work week before the end of a pay period when the month ends in the middle of the week.

    In addition, the department currently responsible for processing timecards and paying employees requires that the timecards are turned in several days in advance to the last day of the month so they have time to process the payroll. Thus, timecards are turned in around the 22nd of each month. That requires employees to “guess” how much they’re going to work for the remaining 8-10 days of the month, including guessing how much overtime, or sick leave they might use. Any mistakes they make in guessing then have to be retroactively fixed on their timecard next month, which creates even more work for the software team to code all of these complex rules and procedures into the application.

    The software team says, “Wait a minute, this seems dumb. Especially this guessing part. And why are we paying people overtime on the last week of the pay period when the week is incomplete and they haven’t accounted for 40 hours?”

    The software team discusses this for a while and says, “Why don’t we just move to a two-week pay period that starts on a Sunday, ends on a Saturday, and give people checks a week later, after the pay period has ended?” Seems logical, and a good portion of the rest of the world uses this model.

    Unfortunately, this isn’t something you can just change with code. You have to have a policy change in the personnel manual. For that, you need someone on the team who can approach the right people and perform the correct bureaucratic dance to get things done, so that the software team can write simple, elegant software to solve the problem.

    And if you think this story is made up, it is not. And it is actually much worse than I just described.

  6. Sounds great Chris,
    The solution sounds good, and we all know that changing old customs is hard.
    Your manager sound like a good change agent and it shows that you guys are really trying to simplify the internal processes.

    I think that in the end, we should feel that it is our own personal responsibility that the product is actually used.
    Some organizations add a product manager/owner to the team to help solve these problems

Add Comment

Required fields are marked *. Your email address will not be published.