What Will Happen To Me - Part II

In the last blog entry, I talked about the effect of moving to agile on individual contributors. In this entry, I'll talk about the effect on management.

Development Managers

You're a likely candidate to take on the scrum master role. Instead of command and control, you'll focus more on facilitating. The team will take on more responsibilities and you'll help them identify and resolve things which aren't going smoothly. You're the one who will make sure all blocking issues are quickly resolved. You'll strive to keep things releasable. You'll ensure that the team is working on the most important things from the backlog. You'll help to make sure the team acts as a team, not just a bunch of individuals.

QA Managers

You're also a candidate to take on a scrum master role. If not, your focus will be on two things: keeping your team members up with development and keeping automation of functional testing up to date. Automation is critical in agile because it is the piece that tells you quickly if anything has been broken. This quick response makes it easier to track down issues (since less has changed) and gives the developers the confidence to refactor as needed. It is a key to staying releasable.

Project Managers

Before your role was to put governance in place such that you could track the team's progress and put the necessary checks and balances in place. Now your role is to minimize the impact of those kinds of corporate taxes on the team (their necessity is less since agile adds transparency to everday life). Everything needs to add value. If it doesn't, it should be eliminated or its impact minimized. You're also in a good position to help the team with its agility by providing objective feedback across teams.

Product Managers

Previously product managers would queue up the requirements for the release. Much work was done on features that never saw the light of day. Now, the goal is to create a prioritized list of work. The items at the top get the most detail. Those further down don't get that level of attention until they work their way to the top. Drilling down into a feature typically occurs in the iteration it is done. Before that, estimates are high level and planning is only done to the degree that it is necessary (items with lots of unknowns receive more planning than more simplistic items).

Instead of committing to the list of requirements for the release, you commit to those items that are done. Items closer to the top are more likely to make it than those further down. The backlog becomes a conversation with the customer. Did we prioritize this right? See http://www.walterbodwell.com/node/5 for some more thoughts on setting expectations in agile.

Senior Managers / Directors

Before agile, senior managers and directors dealt with changes to the plan. If something unexpected came up, it often escalated to you. That's still the case if the team can't handle it themselves. With agile, you have a much better view into what is going on and the progress that has been made. You'll likely make a transition from component based teams to feature based teams (more on this in a future blog). Your goal is to get the furthest down the backlog that you can as quickly as you can. You're (along with the project managers) in an ideal position to promote lessons learned accross teams.

Every one has a unique take on their role. Every company does things a bit differently. The above is a generalization based on what I've seen happen.