Sunday, January 22, 2012

Are managers evil?

First, many have said that there are a lot of bad managers in the US, and in the world.

Peter Drucker worked on this.
W. Edwards Deming had his ideas, and worked on this.

And many many business gurus have had their say, trying to improve the managers.

On the other hand, there is in the agile community a bunch of people who feel that managers are evil.

OK, maybe that is an exaggeration, most of them do not think all managers are evil.  But in general, they feel that most managers are evil.

We think that virtually all managers are not evil.

Equally, it is less than useless to think of the workers as bad or lazy. Or evil.

But let us stay with the managers today.

Yes, there are many managers who do not manage well. And some may even manage in a negative or bad way.  But I think the main reason is that they have been badly taught.  No one has taught them or they were wrongly taught. Or they have wrongly learned.  For example, that it is useful to be a command-and-control manager. And we have tempted them with ego rewards, and many have succumbed.

There is, for some of them, and for some of "us", the notion that no one can correct a manager. At least no one who reports to that manager.  This also is an un-helpful notion.

So, to replace this notion, we offer a few suggestions:
* managing people is very hard, and probably requires different skills depending on the situation and the people involved
* hierarchy and power are probably not that helpful. At least in most situations where you have knowledge workers.
* with knowledge work, knowledge creation and motivation are quite important. Perhaps yet another reason to look for a different kind of manager than we used to have.
* we speak of leadership, and some say that we need no managers, only leaders. Certainly leaders who lead us in the right direction and do it well are rare.  And we need more of them; more Steve Jobs we might say.  But I think we still need managers.

We are in the process of changing the management culture throughout the world. This will be a long conversation. There are so many dimensions. We need to talk and fight and argue about how to manage better. And, if we over-simplify things into managers and workers, the workers are very much part of this fight.

But calling one side 'evil' is not helpful.

Sunday, January 15, 2012

Product Owner & the Team

Is the product owner a member of the team?  Yes. Fully and completely.

What is the biggest problem that most teams face? That, at the high level (value) or the low level (details), they don't understand what the customer wants well enough.  

And who is mainly responsible for managing the flow of this 'business information' into the Team?  The PO of course.

And this is a never-ending job. For example, at the lowest level imaginable, as they complete each step of work, he should be giving feedback: "well, that was not quite what I meant", meaning really "I don't think it is quite what the customer will want."

The feeding of the team, this feedback to the team of Devs (meaning, in overly simple terms, creators and testers) is essential.  And must be done daily.

When we start with a past tradition of thinking and working, there are many obstacles to this 'union' or yoking of the PO with the Devs. One is that the Devs wonder "what is that guy doing hanging around here?"  Another is that the PO feels kind of weird around all these geeks and their geek-talk.

But both sides need and will eventually learn how to live and work with each other.  It takes time.

Only together, as a full team, can they win.

Wednesday, December 21, 2011

Public Impediment List !!! - 2

There is a good Scrum trainer who thinks that a public impediment list is not important.  So, if he can mis-understand, then we all can.  See here is a yet better explanation.  I hope.

****

I find that the lack of a public impediment list is a prime indicator of a lack of focus on removing impediments.

This is essential in Scrum.  Why?

Well, first it is important to say that the public impediment list is not the main deal.  The list must be acted on.  But, like 12 lawyers at the bottom of the ocean, it is a good start.

The real deal is removing impediments, and making the lives of yourself, your team and your customers better.  And the impediment list is one way to do that.  Or, better to say: fixing impediments is one way to do that.  And the impediment list (public) helps you do it better.

Why have a list?  Well, we believe in doing one thing at a time, and getting relatively quicker results from that. Rather than working on many things and usually not making any tangible progress.

So, the list enables the team and the firm to order the work on the impediments.

How? Well, first an impediment is anything, anything slowing the team down. Or, if fixed, would speed the team up. (Speed meaning both higher quality and higher productivity.)  The team gets greater benefits sooner by working on the top priority impediment.

But we forgot to mention that the first one might be the one that gives us the greatest bang of the buck, meaning "business value" divided by effort. (Business value for impediments might, too simply, be thought of as the velocity increase for the team.)

So, we can always be working on the top item on the list.

And, by the way, every team has not reached anything close to optimal velocity, so there is always a top impediment.  In fact, always a list.

Why public? Well, so everyone can see and offer feedback on what are our team's biggest impediments.  Otherwise, Brian thinks he told George about Item X, but George forgot to put it on his personal list....so, it was forgotten. All these little human errors are less likely with a public list.

And we mean everyone.  People in the team and people outside the team.  And including the higher level Impediment Removal Team (IRT).  Anyway can make suggestions, and help us get better.  [I call it IRT.  Ken Schwaber and Mike Cohn and others have their own names for it.  I assume you are in a company with 4 or more Scrum teams, where an IRT starts to make sense.]

A public list reminds everyone that someone should be working on the top item, well, and that would be today!  "Has anyone started?" "Oh, yeah, I'm about to start that!"  Human nature again.

And a pubic list enables Mary... who was sure her Item B should be number one, but shows as number 10 now.... identify the problem. So, now she knows to go to George the ScrumMaster and make the case why her Item B should really be #1 on the list.  Otherwise, she might just guess that George "got it" after their hallway conversation (where he actually was thinking about the Christmas presents he needs to get).

****

The list is prioritized. If the priorities are not obvious, then the ScrumMaster breaks ties.

And the real juice is that the SM is making sure the top impediment is always getting worked.  And indeed someone is fixing one almost daily.

Again, there never comes a day when there is not a top impediment. (We never become perfect.)

Now, it may also be that the public impediment list reminds the SM (and everyone else around) why the heck we have an expensive person (the SM) over here *not* doing "real work." (By the way, I think the SM easily pays for himself by removing impediments. But you do the math. Of course, that assumes that the company culture does not stifle all the impediment removal efforts -- which has been known to happen.)

For you all into Lean, a public impediment list relates to Visual Management and to Kaizen.  Two big practices (or ideas) in the Lean community.

The exclamation marks in the title are there to suggest that way too often we find teams without a public impediment list.

Finally, let me recommend a public list of impediments already fixed.  How quickly we forget our successes.  Oh, yeah, that's why we have the stupid ScrumMaster around....

Your thoughts?