Running retrospective with a small, dysfunctional team

Question

I've started at a gig that (for the purposes of this question) is an established but struggling company using IT as a business enabler, but not a core function. Around 200 staff with 6 IT staff (desktops, CRM, back office, etc.) and one developer; they're struggling to keep people. This sole developer - let's call him Bob - may be a familiar archetype. He's in his 20's, highly talented, enthusiastic, but also temperamental. He's learnt largely by osmosis, lacks focus, isn't methodical and can be very erratic.

So, Bob is the sort of guy who'll be assigned a month-long critical and exciting project that matches both his skills and what he says he wants to do... yet you'll often find him over by the photocopiers having hour-long "discussions" over which backlit keyboards are best for hacking Powershell with. Or, one day he'll notice his line manager is out, notice the production server is nearly full... and spend the entire day "fixing it", including unscheduled maintenance of the website once everyone else had left the office, and going to bed at 3AM.

Which is indeed what happened this week. As far as I can tell, he decided to do this spontaneously, because it "obviously needed doing". No-one signed off on the unscheduled downtime. I don't know if the issue was important; it certainly wasn't urgent; and of course his critical project is pushed back by another couple of days. I understand this happens regularly; but usually someone has walked up to his desk and asked him to pitch in to some ad hoc thing. This is the first time he's done it "by himself".

I am not Bob's line manager (who is clearly exasperated with Bob's behaviour) but I am involved with trying to add structure and generally try to turn things around. Bob's line manager has tried​ to add process via JIRA and Scrum, but Bob openly ignores issues assigned to him, the sprint board, etc. He seems to like working in an ad hoc manner, even given the problems this causes; and seems to see adding structure to his workday, or have managers run interference for him, as a form of micromanagement, an annoyance to be "worked around".

So, I'd like to have a retrospective / post-mortem on this - but, the small team size, compared with the rather Bob-centric nature of the issue, makes it likely to become a massive blame session at Bob (who is already very touchy on the matter - "I get the blame for everything being crap").

I want this to be constructive. I'll give the standard "this is a space to learn, everyone did the best they could given the situation they had" etc. but I don't think that would work in this situation.

On top of that, I'm not happy in this new role: I'm not able to do the things I've been hired for, there's little structure and I'm bored and frustrated. Seeing if it improves by the three month mark, but already considering leaving. I don't want my issues to​ infect this.

So, how can I hold an effective learning retrospective under these frankly dysfunctional conditions?

EDIT: I don't think it's a co-incidence this happened the day his line manager was out of the office. He knew he could "get away with it". Perhaps he views this as a form of heroics. On reviewing this question, I'm starting to wonder if this is some form of irrational compulsive behaviour, to be honest...

Answer 1

I come in as a consultant on this stuff some times. I would approach Bob one on one and say

My role is to find a way to make sure you can meet all these competing and often opposing goals: taking care of things that come up without a whole pile of blaming afterwards around downtime and such, getting your long term projects finished on schedule, taking advantage of opportunities to make things better, and not burning out from grinding on the same stuff all the time.

You may not exactly have that role, but I suspect if you go ask someone for it they will give it to you since the line manager is mad right now.

Now you can do some management consulting with Bob. You know, "ask 5 why times", "root cause", that sort of thing. You can draw the quadrant chart with Urgent/Can Wait vs Important / Not Important and talk about different procedures for tasks in each quadrant. You can give him the support he needs in the form of process and procedure that he can use for reacting to things he notices or things people come and ask him about. You can even provide some project management tools and advice to help him deal with breaking his project up into manageable pieces and be able to see progress on it, for himself and those around him.

None of this has anything to do with blaming him for downtime. Done right, it will prevent that sort of thing happening again but in a really good way, with no hint of "you shouldn't have done that", more of a "together, Bob and regilejusl worked out a policy on that and from now on that's how Bob does things and we all feel protected and supported" way. You may also make a huge difference in his approach to development projects.

I think these actions count as "trying to add structure and generally try to turn things around" and they are what I would do if I was brought in with that brief. You tell Bob the structure you are building is a framework to make people leave him alone when it's not worth interrupting his development work, but also enable him to fix things that need fixing without a lot of fingerpointing afterwards. (For example if he's supposed to send an email warning about downtime in advance, you don't sell that as "you won't be wrecking things for sales" you sell it as "that way sales can't come back and complain the next day, because they were notified 30 minutes before you took it down."

If you care about Bob and want him to be a great solo developer, building him the support structure he needs is a gift you are giving him, not a leash you are putting on him. Holding a retrospective about what Bob did wrong is not going to get you to that structure. Let the lessons from the immediate past present themselves naturally as the two of you establish what structure will help him the most.

Answer 2

Why is the problem Bob-centric? Surely even though it is a small team, they should be helping Bob and preventing each other from making big mistakes. How can one guy pull down the production website without following any process? That sounds like a bigger problem than Bob's behavior.

I just recently called a postmortem with 5 people on a hellish project that had plenty of blame to go around if anyone cared to do that, but it was constructive. We focused on (notice the "we" in all of these even though I was the only developer on the project):

1. What worked and how do we keep doing that in the future?
2. Where did we fall down, and how can we prevent or mitigate that in the future?
3. What did we learn? (Here's an example: Never, ever believe a vendor's delivery date if it falls on the last business day of a fiscal quarter. It's totally made up.)

I sent out some food for thought before the meeting (basically a timeline of significant events) and I came prepared with ideas of things to talk about. We had a great meeting with some tangible process improvements we plan on implementing.

I feel for Bob, because I have about three decades of professional experience under my belt and I couldn't pull off being the sole person responsible for that project. It seems to me like he's being set up to fail. Maybe he's erratic and lacking focus because what's expected hasn't been clearly communicated to him, and he doesn't have someone that's showing him the ropes. Sometimes we think we've explained something well, but I've found that folks with less experience tend to be hesitant to admit they didn't really get it (or they think they got it, but they didn't really). Maybe his team could pitch in and help him in some ways even though they aren't developers. Maybe someone wants to learn how to do some small part of Bob's job?

So for your retro I would focus on how JIRA and the sprint board is/isn't working. Bob doesn't use it - why? What safeguards need to be put in place to prevent unscheduled downtime of the production servers? How does necessary maintenance get scheduled and prioritized? What is working well? (find some positive feedback - Bob did notice that the production servers were getting full. That's not nothing.)

Answer 3

Bob needs an intervention, either by you or by his manager.

At the moment he's running around like a chicken with it's head cut off. He's trying to solve every problem he sees, and causing issues because of his untrained 'skills'.

The approach I would take with Bob is twofold; firstly, I'd ask him to identify which of his skills are most important, and develop - with his input - a plan to get him some valid and solid industry qualifications in those skills. That will make him specialize more, and will show him areas where he needs to let go. In the future, if he leaves (or is nudged), those qualifications will help him get another position elsewhere.

The second approach is to explain that his actions are not scalable; you can't bring in other developers to work under him or at his side if his working pattern is so unstructured. Show him the carrot that you can only promote a professional who is totally in control, and not someone who is running around sticking his fingers into everything. JIRA etc is a good start, but someone needs to make Bob accountable to it; "You were assigned these tasks. How far did you get? Why?"

Answer 4

Answering my own question...

Asked Bob's line manager (if I'd not done this, IMHO I'd have been hypocritically acting like Bob) about supporting the team as in Kate's good answer. Was clearly told "Bob is not your problem, don't worry about him". There had already been a meeting about this of the "please try not to do this" variety. They seem to view Bob wandering around doing whatever he feels like as an acceptable cost for his other work that meets "the plan".

Got the impression that Bob is "roped off" from any improvement efforts, to not risk him walking and leaving them with no developers at all.

Obviously this is not ideal, but then change management never is - "start with what you have now" etc. For my part, will attempt leading by example and resetting the culture, hoping to pull Bob in rather than pushing him along.

Answer 5

Your retrospective should indeed be for issues and improvements that can be addressed by the entire team. If all issues that might come revolve around Bob, his manager should first seek a one-to-one discussion with him first. Maybe hold off a retrospective a little longer until the overwhelming employee-specific concerns are seen to.

Even if Bob's manager is not a developer, he should be reining Bob in a bit. Bob's projects and 'fixes' need to be better tracked and documented. It is possible that Bob, being the only developer, is overworked and is making rash decisions. Even so, someone should have a clear idea of what he is doing and why. From Bob's description, he needs better leadership. A good developer can still be a terrible colleague if they can't follow procedure. Even with your high turnover, I would strongly suggest your company find a senior developer that Bob can report to, someone who has had more experience in the field and will inevitably raise the same concerns you have. If the lack of fellow developers is the a problem, take steps to assure him that you and the company are trying to find more.

You are taking steps yourself to try and turn things around, and those above you should appreciate it. If after a couple more months, your voicing the same concerns, you shouldn't feel bad about going elsewhere.

Answer 6

A retrospective isn't going to fix this. Bob needs two things:

1. He needs to know that, for process and other change proposals from others, whoever made that proposal will step up and take responsibility for what didn't work well with it, rather than blame falling on him.
2. He needs to see other methods actually working and making both the projects and his life better.

The reasoning behind first should be fairly obvious: it's all too easy for someone not on the front lines to say "do things this other way instead" and then blame any problems on poor execution by the ones actually doing the work. But the problems occurred either because the idea wasn't actually as good as it looked from a distance or the front-line people didn't know how to execute it well. In either case, having the person who came up with the idea be responsible for its execution is the solution: they either learn what was wrong with the idea or they demonstrate proper execution of it.

The second serves essentially the same purposes: showing that the idea works, showing how the idea works, and ensuring that Bob can be comfortable about buying into the idea (or at least supporting the attempt at it) knowing that he's not going to suffer bad consequences from not doing things his way.

So what you need to do here is, for a little while at least, join the development team. Work side-by-side with Bob doing the job, shoulder any blame directed at the team so that Bob doesn't have to, demonstrate that your proposals can be effectively implemented, and demonstrate that your proposals do improve things.

This doesn't mean that you need to have all of Bob's technical skills. It's perfectly fine (good, even!) to work together with him, with him doing the "heavy lifting," to come up with specific technical solutions to move forward your ideas. (Pair-programming would be the way I'd normally do this, though if Bob's resistant you may have to get bits of solutions and help from him and do at least the initial parts of the impelementation yourself.) You will also need to take this slowly; where Bob's highly resistant to change leave that for later and focus on small areas where you can introduce low-risk (to him) improvements.

But if you don't have the ability to show how to implement your proposals, you should seriously consider whether they really can be implemented in this situation, or whether your theory is too distant from practice here.

---

As an aside for those who believe that doing at least some regular work at the coalface isn't absolutely necessary to manage software projects, we've known for fifty years that managers making technical decisions without sufficient understanding the technology is a problem. In the words of the first ACM Turing award winner Alan J. Perlis:

In a situation where code actually has to be produced, nobody should be allowed in the system who doesn’t write some given number of lines of code per month. I think that one of the major problems with the very large programming projects has been the lack of competence in programming which one observes as soon as one goes above the very bottom level. People begin to talk in vague general terms using words like ‘module’, and very rarely ever get down to the detail of what a module actually is. They use phrases like ‘communicate across modules by going up and then down’ — all of the vague administratese which in a sense must cover up a native and total incompetence.

Answer 7

A very interesting situation.

I think there are a few things here:

• Making an unauthorised change to a Production system
• Ignoring work assigned to him
• Having poor soft-skills (time management, priorities, social skills etc)

This might sound harsh but I believe Bob may be a product of the environment. If there is a lack of policy, process or structure then some people may tend to use that towards their advantage. Additionally, if they "misbehave" and there are no consequences then can you blame them for continuing to "get away with it".

The issues sound cultural in nature. If I was you, I've preface the retro by saying that this is an opportunity for the team to improve their operating behaviours and that it's about discussing the issues, not criticising individuals and start off by tabling some things you know you could've done better. I've done that before in retrospectives and PIRs and my project team members are sometimes surprised but that humility can help break down walls and encourage others to open up. It's easier for people to admit their own shortcomings rather than have them spelt out. That said, I would insist on mentioning all opportunities for improvement, even if it ruffles a few feathers. At least then it's not simmering under the surface. There should be "no sacred cows" but also an understanding that what's discussed stays in the room and is not for general consumption. The team needs to understand that the retrospective is a safe place for collaboative discussion on how to improve behaviours for the next project phase/sprint or whatever.

In my experience, sometimes "primadonna" type individuals behave that way because (a) they can get away with it with little to no consequences so "why not!" and (2) they see any criticism as a challenge to their ego so it's useful to figure out how to break down the walls.

Answer 8

I think the most immediate impact will be in limiting some of Bob's access to things. This will preclude his ability to add more gasoline to a fire that you're trying to put out, and give you the ability to do some planning without everyone being in reactive, "emergency" mode all the time.

Secondly, put Bob in a position where he has to pair with another staff member for anything that makes changes to your production environment, and this will put your team in a position to cover issues much better than you're in now because Bob will eventually stop being a bottleneck.

Third, the planning I discussed above entails changing processes once you become clear on what the current state is. Who starts projects? Who owns them? How is work funneled from management to subordinates? Are developers making business decisions? You might have to fend off new projects until you clarify, and it might cost you in the short term but the long term benefits are legion.