Should managers worry about extended coffee breaks?

I firmly believe that most organizations would run better if managers managed a bit less. The problem is that most managers do such a horrendous job themselves and drive others to do horrendous job as well, that if they did not manage at all, things would be better themselves. And they should definitely try and keep themselves away from SCRUM teams or should I say “fully functional teams.” And this means doing these [and much more]:

  • Not keeping a count of how many coffee breaks a person takes
  • Not keeping a count of how much time ABC spends on phone
  • Not raising an eyebrow seeing an employee sleeping on the desk

Its sometimes also called reactive management. In fact I dont call it reactive or proactive. Its just another style of management and pretty effective one IMO for you can focus only on results and the behavior which drove the results. In case you use Agile, you can ruthlessely focus on results every two weeks or so. This allows for self correction in teams. Self correction driven through self introspection and committment to try out new things for better results seems to be a better driver for well, better results. Is that not what the management wants in the first place?

Here is why focusing on behavior first is harmful. Lets take the example of server administration teams. Lets say the server administration team [they do a great job and thats probably why] sit idle most of the day and only mostly answer email or do jobs which are completed in 15 minutes flat. Once in a while they are busy like hell, taking back ups and what not, but mostly you find them reading hacking articles, blogging, networking and boasting. There is another team with 3 developers [who do more than some 6 member teams]. However, you find most of them in canteen, laughing, blogging and in passionate discussions. CTO just passes by and after three such sightings can not control and makes this sarcastic mark “So you guys have outsourced your work too?” Managers wandering by and making sarcastic remarks about outsourcing, or whatever half-assed other smart comments they may make, demonstrates management inability and lack of awareness. Frankly, the manager should hope to see those ’slackers’ always ’slacking’, because that implies there are no server administration problems happening, which has to be a good thing.

IMO you need to avoid looking at the slacking [for instance] even if it is in your face. If you are doing Agile, what you need to look at it is what was committed [and assuming this was reasonable commitment] and what was delivered. You can obviously ask question like “What made you miss the commitment?” Slacking can be one answer and Low Morale [because of a manager just walking past and seeing team engaged in tea 5 times a day and remarking sarcastically, have you outsourced your work] can be another too. The managers job is to unearth the behavior for poor performance and not “seemingly” poor behavior itself. However, day after day we see poor management results [sliding profits, non paying customers demanding bug fixes and holding teams hostage, poorly trained teams] due to management proclivity to focus on trivial and urgent but not on important but not so seemingly urgent. It makes you realize how ingrained “command and control” is in our mindset as managers. The notion of a self functioning team just does not exist. The underlying assumption is that they will surely do something wrong and when that something wrong does not happen [well obviously because they would not commit to a 45 man months of work in 5 months, which management wont have any qualms over committing to by the way], issues like longer tea breaks, too many training sessions, not pushing too hard, there is an easier way to do this work, bottom 10% need to go, appear.

Taking everyone along in Agile Implementation

One of the thoughts which strikes me everytime I think about Agile Implementation is our CTOs comment “Project Managers need to be on top of things all the time.” And yet, as a project manager of Agile Implementation myself, I have not been the most Agile Project Manager over the last few months. I have not adhered to the Agile principle of carrying everyone forward. I have allowed people who do not quite understand Agile to dictate how we should structure our Agile Implementation. For instance, one of the junior most designers who was earlier a part of our truncated sessions for 3rd group is no longer considered to be worthy enough to take the sessions. This is because the current thinking is that Agile sessions are for employees with certain “IQ” and “who can take us forward“. The argument put forward is that we need to explain to employees why someone is allowed to take these sessions while others are not allowed/ considered. Hence, only the very best [or at least the very best in our eyes] should be allowed to take the sessions.

The other side of the story comes from the usual office politics. Some project managers will not allow anyone from their team to take part in the sessions. This is because they either do not like what we are doing or they have problems with people in the Agile Implementation group.

In both the situations above, it indicates that the reason why we are not able to take everyone along is because we cant get people in top management to be carried along as well. The implementing group has been thinking of it as some kind of agenda that we will implement Agile without the support of top management. This is obviously not going to happen. Also, this alienates them to the extent that before Agile is going to become a total reality we have already create a group that does not want to hear anything to do with it. In the first case [where a designer was barred from attending 3rd session] it indicated failure of communication internally in the group and in the second case [where office politics was at play], we were at failure in getting along everyone in top management.

We know its hard to work with people whom you have passionately hated all your stay in the office but we need to decide what is more important for us, Agile Implementation or Our own Comfort Zone. The answer is not that simple. But one thing is for sure, we need to find a way to get everyone along.