Tuesday, May 26, 2009

Participate in change, don't expect it to happen

One of my peers asked me why our manager kept assigning work to specific resources instead of simply prioritizing it and letting the team pick it up as people were available. The upside of this question is that they are starting to understand some of the core agile concepts, but the downside is that this is a hard question to answer. What they want to hear is that I will go convince management to stop meddling with the team and allow them to be self-empowered and self-managed. They want to find the better way on their own, but it's not that simple.

The manager does this for a reason. To him, it is important to sort his desires taking efficiency into account. In his mind, this is most affected by WHO is going to work on it. Instead of pushing for anybody to be able to work on anything (something that seems insurmountable), he re-arranges his desires and works with the system in place. Unfortunately this is a very short-sighted approach, but we haven't provided much of an alternative. Right now, the manager only trusts himself to make these decisions.

I pushed back on my peer. I told them that it was up to the team to change this situation. We have to do more than simple code reviews. We have to actually insure that multiple people on the team know how everything works so anyone can modify it. We have to build trust with management that we can handle work efficiently in whatever order it arrives. It is a slow path to managers having the freedom to prioritize and granting the team control to manage themselves. We have to build the solution, show it exists, and earn management's trust.

I find it is easy to convince a team of the underlying agile values and principles. The harder part is convincing them that they are an active part of the solution. They see all the ways agile solves their needs, but they forget the needs of the business and management. Teams must take ownership of showing managers how agile solves their needs also. Everyone has to understand that we are trying to optimize the whole system and not just the part that the team plays!

7 comments:

  1. Nice post... I often see these patterns with our teams in that they are great at pointing out the problem, but do not offer alternatives. They think it is out of their control. I think your point about the teams not understanding the needs of business and management is particularly important. Scrummasters, managers, product owners need to educate the teams and ensure alignment. Simple in theory, harder in practice.

    ReplyDelete
  2. This maps to my experience as well, and our shop has been doing Agile now for about 2.5 years. I agree with your remarks that the team must be cross-trained and even across individuals as it relates to throughput in order to minimize the effect you see with managers or business owners requesting specific resources for scrum teams.

    Nice post - thanks!

    ReplyDelete
  3. This is an excellent post i am going to give you some blog love , this is one of the frustrations i have faced form both sides of the fence when working with teams and with managers. I think what you have writte on the subject is spot on.

    ReplyDelete
  4. Thanks for the support, I really appreciate it!

    ReplyDelete
  5. I've experienced similar issues with my team, and this is a great way to look at it. I think part of the issue is that programmers typically have the mindset of 'I'm paid to code', when that's only a part of the story. The other day I told my team that their coding skills represented around 25% of the value they bring. I need analysis skills, continuous learning and innovation, and problem solving capabilities.

    I think what you're talking about here, as well, is the maturity of a team to take some control over their own situation. "Self-organizing" doesn't just mean deciding as a team who does what task -- it also means taking on problems and issues to solve themselves without relying on a manager (or Scrum Master) to do so for them.

    ReplyDelete
  6. Great post, Kevin. I guess 90% of dev teams switching to agile can say - yes, exactly, that's what we're facing right now.

    ReplyDelete