Can Scrum Teams Have Managers.

"Is it safe to say PM has to acquire new skills to make himself fit in the scrum process? " 

This question was asked in a scrum forum on Linked In, and many interesting and valuable answers were given.

It is pasted here verbatim because I want my answers to this question to come home with me, and to be available to my clients, peers, and colleagues.

The fear of "working without management" or "losing my management job" is pretty fierce in larger organizations, and I think it can be a misplaced or imaginary fear.

This answer was specifically pointed to people in a Scrum-specific forum, but information here applies generally in any number of organizational change contexts. Even in our migration to Anzeneering, we have seen/felt the powers permission and support.

On to my answers:

Strictly, yes. 

The biggest and most difficult difference is not telling individuals what to do. It's hard for the individuals at first too. It's easier, once accustomed to command-n-control ("masters n minions") to continue the habits that kept things harmonious in the previous project. 

But let's leave "strictly" for a moment. 

Managers tend to be stewards of the 5Ts (Time, Talent, Target, Treasury, and Trust). They have influence on budget, can hire/rent/fire/shuffle people, can help communicate or coordinate scope changes across organizations (not just scrum teams), and have a certain budget to manage. They extend or withhold trust & permission, which greatly influences team behaviors.

These 5Ts are not "part of" the scrum framework, but with these, a manager of an organization composed of scrum teams can have a great deal of impact and influence -- hopefully for the better. 

In addition, someone who was a manager has an extra superpower: Perspective. People need to know how an organization is navigated and how to serve it (yes, in addition to serving the customer). 

Trust might be the most powerful of the 5. People tend to not do things that they do not feel the permission to do. Lacking a sense of permission, people keep their tools, practices, and quality exactly as they have always been. It is safer, organizationally, to work within the trust you have been granted, to "stay in your lane." 

The ugly fact about larger companies is that the delivery of valuable software is a secondary concern. The primary concern on most people's minds, most of the time, is their position and longevity in the organization. Becoming brave and blazing a path is fine for contractors, but it can get you fired from a job you want to keep. Being conservative and not making waves, we can stay in our position even if we have late deliveries, bugs, and problems provided we work within the system.

Being mediocre and avoiding attention feels safer. 

It is not something we are comfortable talking about publicly, but it's true nonetheless.  Managers control empowerment.

In a larger org, the manager has a very important transitionary role and a very important supportive role, even if he does not have an official place INSIDE the scrum framework.

Your agreements, disagreements, amplifications, and puns are welcome in the comments section. 

QCon London: Taking back development (Take Agile Back).

Ruud Wijnands and I just completed QCon London. I have a few new contacts, a few new stories, and we were able to present "Take Agile Back" -- a talk in three parts:

• Take Back Agile: "If this is agile, take it back."
• Take Back Agile: "Give me my agile back."
• Take Back Agile: "... to your team." 

The point was not to shore up the defenses and protect the whole velocity/timebox/points/meetings nightmare, but to remind people that there were reasons that XP (and scrum) worked, and to return our thoughts to the experiments that resulted in a successful, productive, social process that got stuff done.

There are underpinnings to consider.

Safety (anzeneering) is one. It has to be safe to experiment in order to do things more intensely. We see people repeat some practices, but deny the right to modify the system via experiments and validated learning. This is a mistake. We need to find our own "two questions" and focus on never stockpiling our pain.

Permission is a key type of safety. Ruud and I both talked about finding permission, and how our mental impersonators (your "inner forbidding boss") need re-calibrating. We discussed the context shift developers need in order to get permission, and how trust and permission can be obtained in a transactional way. 

But most of all, it starts with concern for our value:effort ratio. This relates to the lean concept of "perfection" (absolute value with zero waste) and Ruud explained that it can be addressed with the accumulation of small improvements (see 2-Second Lean for more details). 

There was about an hour's worth of stuff, so I'm not going to use up this space with a recap.

However, I got a story from a developer in my elevator ride from the interview I had with Ben Linders on Friday: His team started to estimate the time it would take to clean up the code in order to implement a feature. He said it was the moment that everything changed for the better. They didn't ask permisison, they just included it in the estimate instead of estimating the time to type the new feature's code onto the pile of rotting code that they already had.

This story resonated with me. If you are that developer, please contact me so I can write more about your journey. I've seen this before, and I would love to hear more.

On The Agile Manifesto

Everyone points to the four "preferences" part of the manifesto and ignores the more important first paragraph, and the far more important second page ("principles").

Key phrase: "We are uncovering better ways of developing software by doing it and helping others do it."

That's different than "we are cementing our idea of software development process by teaching it and certifying others to teach it." It's different from "we are making people feel better." It's different from "we don't write documentation" or "we force velocity as high as possible"

If we lose that key phrase, we lose it all.