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 Power is in the Points

How hard is it to estimate how long something will take? The answer is very hard!  But why is this?  Well, there are a few key factors. Mainly, the problem with time is that in a short space of it anything can happen.  It is unpredictable. Estimating in time is risky.  Secondly, people aren’t actually very good at estimating how long things will take.  How many times have we heard “how long will that take?”, only to hear the reply “how long is a piece of string?”.  Sometimes tasks are so massive, we just cannot begin to get our heads around it.   People are, however, much better at measuring how complex a task is.

Let me explain…

If someone pointed at a messed up Rubik’s cube and asked me “Is that complex to solve?”.  Personally, I am really not very good at those things, so I’d be like “Err, YAH!”.  I don’t need to know much to know it is complex.   Complex doesn’t mean ‘hard’.  It’s not exactly ‘hard’, I mean it’s just moving some squares around, but its complex because it takes a lot of thought, and there are so many combinations to process as I move the pieces.

Now, if the same person then asked me “How long will it take you to solve that Rubik’s cube?” I would have absolutely no idea.

This is why in Scrum we measure complexity of work in story points as opposed to in time.  Once the team understands the concepts around points and planning poker, they get pretty good at measuring complexity.  It turns out it is a much more accurate measure of forecasting estimates than time alone ever will be, and this makes story points powerful.

Story Time! Yey!

Do we like story time? Of course we do! Story time is great! We also like this name far more than ‘Backlog Grooming’ which just sounds wrong…

So what is so great about Story Time? Well, are you sitting comfortably? Then I will begin…

Once upon a time there was a meeting called the Sprint Planning Meeting and that was held at the beginning of every sprint in a faraway place (it seems far away to a developer if it is not at their desk…) in a land called ‘Meeting Room’ and it took a lonnng lonnng time. The Sprint Planning Meeting had a very looonnnng time box (8 hours for a month sprint, proportionately less for shorter sprints) and it made the Scrum teams very very tired and not want to go anymore because it was soooo lonnngggg…

Ok, so you get the picture, Sprint Planning can be boring and take ages…So, as a ScrumMaster, what can you do about it and what is Story Time anyway?!

Story Time is also known as the Backlog Refinement Meeting, or Story Elaboration Meeting and it should be scheduled to occur a day or so before Sprint Planning. The point of the meeting is to get the dev/test the team together with the Product Owner (PO) to go through the top priority backlog items that are candidates for the next sprint. The MAIN PURPOSE of this meeting for me is to make sure the whole team understand the requirements of the product Backlog Item (PBI) in question, and provide a gut feeling as to whether it is possible to complete it in the sprint. I know, right?! Gut feelings as opposed to knowing for sure? This sounds like fiction! Especially to all you command-and-control traditional Project Managers out there (naw, bless….sucks to be you).

It is important to stress that the team do not commit to anything in the Story Time meeting; they are just assessing what could be possible to get done in the next sprint. There are two reasons why I find this meeting is great: Firstly, because by the end of the meeting, the PO and the team are on the same page when it comes to the requirements for the top priority backlog items, and secondly, it shaves time off your lengthy Sprint Planning Meeting because the team are already familiar with the story and the requirements. For a two-week sprint, I keep Story Time to a two hour time box. This is not too little, not too much, but is just right to keep the team focused and engaged and most importantly, clear on the requirements for the top priority backlog items.

For a great video on Story Time, see Andrea Druckman’s 60 Second Scrum YouTube video: http://www.youtube.com/watch?v=KRZ201j1ZUk

A really useful sprint planning agenda!

The first sprint planning meeting for a team new to Scrum can be challenging. There is bound to be lots of questions from people, and perhaps uncertainty about what to expect or is expected, especially at the beginning of the meeting. Therefore it is important to deliver the meeting with conviction and confidence, but also get out of it what you need in order to set the team up for a great sprint.

If you are a ScrumMaster about to facilitate a team’s first sprint planning meeting, here is a good agenda to follow to make sure you cover everything in the timebox (Note: I always hold a Backlog Refinement meeting in advance so the team are already familiar with the stories…this really cuts down time needed in Sprint Planning).

1. Write out the agenda on a separate board or flip chart page. Tear it off and stick it to the wall. Tick off items as you go through them. This will help your team stay focused, and know where they are during what can be a long meeting for them.

2. Establish whether there is any leave coming up within the team

  • This will help you plan your capacity. Out of a 7.5 hour working day, I estimate each person to have a capacity of 5 productive hours. If your task’s cumulative estimates end up exceeding your capacity, you can address the impact and even remove stories if necessary.

3. Explain what a sprint planning meeting is and what it is for

  • You should have done some basic scrum training with your teams, but I find ‘setting the scene’ this way gives your team confidence that you know what you are doing and why. It also discourages the team from questioning why they all have to sit through it all in the first place (even if you do but them cookies and donuts)!

4. Explain story points as a measure of complexity, and introduce planning poker

  • Explain very clearly how points is a measure of complexity, NOT a relative measure of time (i.e. 3pts=1day). They need to be clear on this in order to understand the concept of Planning Poker

5. Play planning poker on previous stories using the a consistent scale (e.g. Fibonacci)

  • The team can then refer to these stories as a reference for when they play planning poker on their new stories.
  • Choose a few examples of previous stories the team are very familiar with working on. The examples should include a very easy story e.g. 1 or 2 points, a mid range story of about 8 points and a larger story, perhaps around 20 or 30 points. This way, when the team use the examples as a reference you can help them by asking whether a new story they are trying to estimate is more or less complex than the (X point) example
  • Use the same scale for every sprint planning meeting
  • When the team have found a fitting example, write the story name on a board or flip chart.

6. Discuss the next sprint stories one by one and play planning poker on them
7. Go through the stories and assign tasks

8. Go back to the story points and ask whether the team feel their original estimates are still accurate

9. Commit to sprint goal(s)

  • Write down the sprint goal(s), then read it out. Keep altering the wording until everyone agrees with it (including the Product Owner…very important!) as subtle changes make a difference

The Agenda in a nutshell:

1. Write out the agenda on a separate board or flip chart page. Tear it off and stick it to the wall with blu tack (tick off as you go through them)

2. Establish whether there is any leave coming up within the team

3. Explain what a sprint planning meeting is and what it is for

4. Explain story points as a measure of complexity, and introduce planning poker

5. Play planning poker on previous stories using the a consistent scale (e.g. Fibonacci)

6. Discuss the next sprint stories one by one and play planning poker on them

7. Go through the stories and assign tasks

8. Go back to the story points and ask whether the team feel their original estimates are still accurate

9. Commit to sprint goal(s)