Bad Management is Mad Management

A while back I went for dinner with an old colleague whom I am still in touch with from when we worked together several years ago in a large financial MNC.  We chatted about our lives and naturally we discussed work.

She told me she had a new line manager.  She was not happy about this.  The new manager was not as personable as her old manager, and in addition, was a bit (a lot) of a control freak.

I asked her to give me a few examples of her new line manager’s behaviour that made her (and it turns out the whole team) feel so disgruntled.

And so she explained.

Firstly, the new line manager, let’s call her ‘Ms Goneril’,  immediately gave the impression to her team that she thought she was better than them; that she was of a higher social status.  Ms Goneril   was a little more ‘mature’ shall we say and so throughout her long career had managed to accumulate the money to acquire more high-end material possessions. A fast car, a big house, that sort of thing.  Whilst the problem was not with her obvious success, this is not a crime and actually I believe all personal successes should be championed, including career success.  It was her attitude that was the problem.  Regularly referring to expensive shopping sprees, expensive holidays, and basically being a bit uncouth around the team was the default stance.  The consequence of such meant that, as my friend said, the team felt she was not personable and was aloof from the team, which made them feel that Ms Goneril thought she was better than the ‘minions’ that do the work.  Ms Goneril had made it clear she wasn’t part of the team. She had lost the ability to identify with her own team and vice versa. She would frequently ask members of her busy team to perform tasks for her that she was perfectly capable of doing herself.  She would demand updates on an unnecessary frequency. She would dictate what time lunch was. She was a stickler for time-keeping and would mention if team members arrived at 9.05am or were not back from lunch exactly an hour after they left their desk.

A little more worryingly, she said that Ms Goneril had access to all the team’s work email accounts so that she could read all the teams’ emails and check their calendars whenever she wished.  Shocking behaviour! So, as I saw it, this ridiculous situation with my unfortunate friend was thus: Her previous line manager whom she (and all the team) liked and had a great rapport with and whom had promoted a more healthy, empowering approach to managing the team, had been replaced with a controlling snob with no social skills. Perhaps there were reasons for Ms Goneril’s behaviours that were not brought to the discussion, but whatever the circumstances were that surrounded the change, the result was a massively disgruntled team that were not enjoying their jobs as much as they did, mainly because their new manager made them feel stressed with her controlling, micromanagement ways. For the business, this meant that they had unwittingly created risk of increased attrition, quality decreasing and sickness becoming more regular due to stress or lack of motivation. All expensive situations for a business, not to mention highly disruptive and potentially debilitating if all the accumulated knowledge within a team is lost.

It got me to thinking, as I’m sure many of us have at some point in our careers, “How has that person got that job?”.  Then I thought “you poor thing” about my friend, then I had some other thoughts about her new line manager but shan’t mention the specifics here…

Clearly something, perhaps many things had gone wrong with the appointment of this individual not just to this team but the company as a whole. How was Ms Goneril able to slip through the net like this?  Nepotism? Everything looking good on paper? Multiple Personality Disorder?? Who knows.  So then I got to thinking about recruitment in and Agile environment.  Regardless of her credentials, would Ms Goneril have been able to cope in an Agile environment where, among things, teams are trusted, relationships are collaborative and leadership is about mentoring and serving the team as opposed to power dressing in Prada?  Would this person have been able to learn Agile values or are they now too conditioned to (and arguably enjoy the perceived power of) Command and Control that there really would be no hope?  Finally, if Ms Goneril were subjected to an Agile transition (the Company I speak of is still heavily Waterfall), would the company be brave enough to get rid if they proved themselves to be incapable of changing their attitude to be more accommodating to an Agile approach?

It’s a difficult topic, and it is hard for companies to know what to do in such situations because there is understandably emotion and attachment involved with people, no matter how useless they may be!

However, I am of the belief that in order for Agile to flourish, the right sorts of people are needed to be part of it and make it work.  Regarding the latter clause, ‘making it work’ means for ever, not just through a transition.  For ever and ever, project after project, until the end of time.  That’s ages, isn’t it?  Companies do need to be tolerant of difficult individuals and individuals who struggle to change, but there needs to be a clear message that attitudes of the troublesome need to change within a reasonable timescale. ‘Reasonable’ meaning what the company feels is a just amount of time for an individual to adopt the attitude needed to facilitate Agile principles. The company should provide ongoing support and training to everyone throughout a transition and even beyond so that they have every reason to succeed, but, after a ‘reasonable’ time has passed, sadly, the Company needs to have the courage to cut those people loose and recruit replacements with more suitable experience or just a great attitude.

The behaviours of managers like the one my friend described should not be tolerated in any company, not just an Agile one.  To me it is basic common sense that such a violation of trust and obsessive control by a manager will never bring any good to a team’s morale or their performance; it will only create distance as the ‘us and them’ culture perpetuates.  So many companies still ignore how management affects teams on a daily basis.  Therefore, in conclusion, all I can say to all this is for companies to be careful who they hire and especially who they give team responsibilities to.  Agile or not, the approaches of the line manager I have discussed above is disgraceful behaviour that should not be tolerated at any level.  Bad attitudes from anyone but especially from management all contribute to a more global negative culture that is very difficult to turn around later.

The Scrum/Kanban Killer Kombo

Most projects require input from your infrastructure team, and this one team can be responsible for supporting possibly several on-going projects. How can Scrum Masters and Product Owners (PO’s) make sure this team are doing what is actually the most important thing as opposed to being reactive to whichever project shouts the loudest (especially if your organisation still hasn’t conceded to the fact that Project Managers do not have a role in Scrum)? On the flip side, how do they stay flexible enough to expedite emergency items?

A great combo that I have seen work really well is when the Infra team run off Kanban, and your project teams run off Scrum. When the Project Teams are in Sprint Planning, you should bring in a representative from Infrastructure so that a) they are familiar with the Infra requirement b) they can be notified of a ‘due by’ date that they can integrate into their Kanban backlog ‘stack rank’ and c) because the project’s scrum teams are sprinting, your Infra guys know when the release date, or dates will be, which may be their ultimate ‘due date’. It is really important that Scrum teams are honest with Infra about due dates because it will dictate to a large extent the stack rank of the Infra team’s Product Backlog. Other things that will play a part in the stack rank are technical dependencies, or expertise availability (someone may be on holiday). Other pre-requisites for the Scrum teams is that they are realistic with any due dates that they expect of the Infra team, and don’t put the team under unnecessary pressure to deliver a Product Backlog Item (PBI) in the first week of their sprint when in actual fact it is not really needed until the second (or third, or fourth!). They also need to make stories/requirements clear so that your Infra guys can come up with the best solutions. The Scrum teams should also keep the Infra guys well aware of any change in requirements so that they are not continuing to commit to delivering unnecessary and therefore wasteful items. To help prevent this, the Scrum Masters should attend the Infra stand ups as a chicken and keep an eye on their backlog items. They should listen to the conversations going on in the stand-up (yes, as technical as they may be, stay with it Scrum Masters!) and any concerns should be raised early.

The Kanban limited Work In Progress (WIP) work streams lends itself really well to infrastructure teams, because a lot of the tasks they do will be the same or similar variations of work they have done before. To get full buy in from the whole team, ask THEM what they think the work streams and their limits for each should be (as well as the Definition of Done for each). They can always change it later if it doesn’t work. You are still required to inspect and adapt with Kanban! In the past I have seen a flow similar to the below work really well:

Infrastructure Kanban WIP Work streams

  1. Backlog (always stack-ranked). Contains user stories with defined requirements and acceptance criteria
  2. Analysis. The design and approach is established by whoever picks up the story
  3. Analysis Review: The design and approach is peer reviewed
  4. Development. The code is implemented
  5. Test. Tests are run, bugs raised etc.
  6. Ready for release: If the code is to be released at the end of a Scrum team’s sprint
  7. Done. The Definitions of Done are met and the PBI goes on the ‘Wall of Done for all to admire.

Make sure you have regular retrospectives with the Kanban-ers because like XP, it is fast paced and therefore is very important to address issues and make any changes to avoid conflict, promote best practice and most importantly, prevent burnout.