In this week's episode I talk about meetings as they relate to Software Development - I introduce you to the good, the bad and the ugly.
Or listen at:
Published: Wed, 27 Jan 2021 16:44:22 GMT
Transcript
[00:00:35] Hello and welcome back.
[00:00:39] In the last episode, I touched briefly on meetings and asked the question whether or not we attended too many meetings and not taking enough time to focus.
[00:00:49] You could have come away from the last episode thinking I believe that all meetings are bad.
[00:00:54] That's certainly not the case.
[00:00:57] As with many things, nothing is universally bad. And in this episode, I'm going to talk about meeting - the good, the bad and the ugly.
[00:01:10] And specifically, I'm going to talk about it in relation to software development.
[00:01:16] So let's start with the good.
[00:01:18] The good for me is where it helps the team or it helps a team individual.
[00:01:24] The first one I want to talk about is one-to-one meetings. That is if you've got a direct report, you're having with your direct report on a regular meeting to build a rapport, to build understanding, to help build a relationship between you and your employee.
[00:01:41] One-to-ones are a great way of building a relationship where if your employer has a problem, finds something new they need to discuss, or just wants to feel that they can be open and honest one to one, one's a great way of building that.
[00:02:01] Unfortunately, many managers have forgotten the value of one-to-ones - having that regular sit down, maybe weekly, fortnightly at worst monthly - sitting down with your direct report, allowing them the opportunity to raise things back to you.
[00:02:18] To raise things. To get things off their chest. To have that forum. To be able to raise anything that is on their mind. To be able to create that relationship where both you can have an open dialogue.
[00:02:33] The next series of meetings I really like are anything to do with the team - the team working together.
[00:02:41] So take, for example, regular planning meetings within the team, regular catch up within the team, the team sitting together trying to find and solve problems, the team working together to achieve an aim.
[00:02:57] You'll notice I'm overemphasising the use of the word team.
[00:03:00] This is not about you as a line manager or an executive or a stakeholder sitting down with the team and getting them to plan, getting them to give you a status update. We get onto that in a bit. This is about the team itself working together, finding the best way of working to do their job well.
[00:03:20] Which feeds into the team retrospective.
[00:03:23] A team retrospective is a meeting dedicated to the team sitting down and review how they work, the processes, the tools, all the problems, that affects their day to day work.
[00:03:36] It's a meeting designed to enable the team to look at what they need to do to get better at what they do.
[00:03:43] Not looking at a status update of a particular piece of work, but at the team itself - making it into a well oiled and efficient machine.
[00:03:53] I also really like demo meetings where the team can sit and provide demos to stakeholders, customers, of the work they've done. Allowing them to get feedback, ideally rapidly.
[00:04:04] They should be providing demos to customers or sponsors, stakeholders, whoever is the important person to actually provide that feedback and guidance as to whether the team has built something that is correct.
[00:04:22] So often a team can go away and start developing, start building, start making software, but without actually coming back and reviewing it with the actual users of it, mainly the customers. You're not sure just how right the work is.
[00:04:38] Often you can find just by doing a small piece of work, maybe two weeks worth work, providing a demo, you get feedback from that as to whether or not you are heading in the right direction. And if not, it's a great opportunity to make course corrections.
[00:04:53] So the ability to have that demo and get that feedback is so vital as a meeting because it does elicit that feedback and allow a course correction as opposed to waiting six, 12 months, maybe even two years down the line to get a piece of software out, only to find it's the wrong thing.
[00:05:13] Another couple of meetings that I really like; game days and blameless postmortems.
[00:05:19] Game days were introduced in episode 47. A game days is where, as a team, you sit down and you try and work out where a system could fail.
[00:05:28] You make up scenarios, you role play, and then you work as a team to understand: "well, how would we cope with that?"
[00:05:34] So rather than it being an exercise where you wait until something breaks; you're actually drilling into the team how to handle problems - which not only highlights gaps and issues that need to be resolved, but also means a team are much more prepared if there ever is a real problem.
[00:05:55] And blameless postmortems. Things will break. Unfortunately, that's the nature. But how you deal with them really depends on how the team moves forward. In a blameless postmortem, you're accepting the fact that things break, you're accepting the fact that something went wrong in the systems and the processes around it. And what you're doing as a team is learning what you need to do to address that. You're learning what you need to do to make sure that that problem is removed and doesn't happen again.
[00:06:32] OK, let's move on to I consider bad meetings.
[00:06:37] And I probably categorised most of these as being aimed at helping the leader, helping the executive maybe or the line manager.
[00:06:47] So having meetings with the team to get status updates. Having everybody in a room, just going round one by one.
[00:06:55] "What have you done?", "How are you getting on?", "What's happening?"
[00:06:57] Most of the time, these meetings take too long. They're only interested in the executive understanding or pressurising the team into getting work done.
[00:07:07] And most people in that room don't care about what everyone else is doing because you're treating them as individuals. You're being asked to provide updates.
[00:07:18] The same often becomes true during an emergency situation where a system is down.
[00:07:24] If you've got a team of developers trying to fix a problem, trying to investigate why something is wrong, the last thing they need is somebody standing over them going:.
[00:07:32] "What's happening?", "How long is it going to be?", "Do you realise how much this is costing the company?", "Do you know how important this is?"
[00:07:39] Yes, of course they do. That's why they're trying to fix it.
[00:07:42] How are they going to concentrate and get the best fix in as quickly as possible with someone stood over their shoulder making them nervous? All that does is actually make them fearful, make them lose concentration and most likely make mistakes.
[00:08:05] Another bad set of meetings are anything that involved sitting down and doing a lot of detailed work.
[00:08:11] So detailed requirements; I've sat in meetings before when I've sat in four hour meetings working over the requirements for a piece of work, and it was a series of meetings going over that piece of work.
[00:08:24] That's such a poor investment of time sitting down and building requirements just to put them into a document. A document is a by-product. It's not what we're trying to do.
[00:08:34] What we're trying to do is find a way of delivering value. And to deliver that value, putting all the requirements into a document, doesn't do that. We need to actually produce working software that can provide value to the customer or the organisation.
[00:08:49] So rather than sitting and doing pages upon pages upon pages and pages of detail requirements, let's do a bit, let's build a bit, use the demos, use the feedback to then see if we're heading in the right direction and we can then course correct.
[00:09:08] And the same is true of detailed planning. Often we want to have some sense of how long the work is going to take. We almost want to get to a confirmed cost. And I've talked previously about how that's very desirable.
[00:09:25] Estimation in software development is not an easy thing.
[00:09:29] So much so that for me, estimation will always be wrong.
[00:09:33] It's more a question about how far wrong - thus if you are trying to do a lot of detail planning on something that is inherently going to be wrong, what's the value in that.
[00:09:43] Especially if you work in a much smaller iterative cycles where the risk of something taking longer or that the actual thing you're asking for is the wrong thing is greatly reduced because you're working in such small steps?
[00:10:00] Another bad meeting for me is the Change Advisory Board, often referred to as the CAB.
[00:10:06] These are meetings that are acting as a gatekeeper for delivering software into production.
[00:10:13] The intention is good, it's trying to protect production systems by making sure that what's been done is correct, that it's all approved, everyone signed off on it. And depending on your own organisation, if you've got a CAB, there may be other things they want to check to make sure I correct to go in.
[00:10:33] My problem with this is that most of these things should be automated.
[00:10:38] You should have automated tests to make sure that it's valid. You should have demos, you should have automatic approvals, UAT acceptance to make sure that what it does is correct. You shouldn't have to wait from developing the system, making sure it's valid to then go and have a meeting to decide whether you're going to put it live and to schedule it.
[00:11:03] By having that break in the timeline between when it is ready to go and when it potentially is approved to be released, many things can change.
[00:11:14] Teams can start working on other work and forget what they've done.
[00:11:18] And I've seen CAB processes take weeks, maybe months in some cases, to actually approve work to go in.
[00:11:26] So for me, the CAB, while I understand it's trying to do the right thing, it is the wrong approach. There are better ways of automating and making sure that those same standards, those same controls, those same safety nets are in place without everybody having to gather in a room and try and justify to a group of people that had no idea what the work was.
[00:11:54] Speculative or future work can also be a great drain on the team's time.
[00:12:00] It might make sense to try and grab the team and go;
[00:12:02] "Look, we're thinking about doing this", "We're thinking about heading this direction."
[00:12:08] That's great, let's get the team's feedback, but is it something we're thinking about doing now?
[00:12:12] Is it something we're thinking about effectively doing in the next week, two, three, four weeks? If not, why are we talking about it?
[00:12:23] I've been in positions before where so much of the team's time was taken up in speculative work and future work, that they actually only had about half the available time in their calendar to actually focus on the work they were meant to be doing now.
[00:12:39] So you have to be careful of what we're trying to do.
[00:12:43] Yes, sometimes it makes sense and you do need to bring the team in to talk about speculative work, but is it going to be the thing that we expect to do next?
[00:12:54] If it's something we're expecting to do, maybe in six months, 12 months time maybe, and we're trying to get an idea of how much it's going to cost the size of it, should we really be spending time and investing the effort now to understand it?
[00:13:09] The danger with that is we're going to invest so much time and effort similar to with the detailed requirements and the detailed planning on doing stuff that we may never do.
[00:13:19] We may change our priorities. It may be something we no longer need.
[00:13:25] And finally, in the bad category, just any meeting that has no clear aim.
[00:13:30] So many meetings have no agenda. We're not really sure why we're attending them. We're told we have to.
[00:13:40] But that's not an efficient way to run a meeting. It's not an efficient use of time.
[00:13:46] If you're in a meeting and you're looking at the people around you and you're adding up the lost benefit to the business by people sitting in that room sitting, confused as to why they're even there, then you have to be confident that they're for a good reason. You have to be confident there was a clear aim why that what they need to be there for and you're going to get some value from it.
[00:14:11] Ok, onto the ugly.
[00:14:16] The main ugly ones for me are ones where basically the meeting is about venting frustrations - normally from the executive level, unfortunately, or maybe middle management.
[00:14:28] We've all been in meetings where there's a venting of frustration - that the team needs to work harder or maybe it's following a failure and we're trying to find blame.
[00:14:40] Neither of these are good reasons to vent at the team.
[00:14:46] Any time that a team is on the receiving end of a unstructured and unhelpful dressing down or an attempt to elicit blame - to find blame within an individual, find blame when a team - you switch them off, they become defensive, they're not going to work together to help you and your organisation grow.
[00:15:11] Being in a meeting where an executive is effectively throwing a four year old tantrum isn't good for anyone.
[00:15:19] The team loses respect for the executive.
[00:15:22] The executive fails to get across, in most cases, why the frustration is there.
[00:15:27] There's probably a very good reason there's a frustration there, but because of the way it comes across, because they're either telling the team they need to work harder because they're failing, or that they're on a witch hunt to try and blame someone, the team is going to find it very difficult to provide valuable input.
[00:15:49] And, of course, the demotivation factor of being at the receiving end of those sort of meetings.
[00:15:55] I've been through so many myself. In my early career, I unfortunately came from the environment, in which it was normal to be shouted out to be - almost bullied in terms of your work.
[00:16:13] I'd hate to think I'm carrying that through to any work I do now - because it's just not an appropriate way to get the best from your team in any way, shape or form.
[00:16:24] The other ugly that I wanted to add in to here is performance reviews.
[00:16:29] I was in two minds whether to add this into ugly or into bad.
[00:16:32] And it may surprise people that I would even consider putting it in either of them.
[00:16:38] But performance reviews - and I'm thinking mainly about ones that affect a employee's career prospects or bonus or pay or structure like that - they have such a risk of producing dysfunctional results.
[00:16:57] I often think of the sales teams that are traditionally been bonused on sales.
[00:17:03] And their very specifically bonused on one type of thing, they're really based on how many sales they get for the door. They don't care about the quality of the sale. They don't care about whether it's a right fit for the company if they're focussed specifically on just getting sales through the door.
[00:17:17] That's what they're going to do - because that's what they're being motivated to by a bonus.
[00:17:26] But in doing so, they drive dysfunctional events. We saw this with the 2008 financial crisis.
[00:17:34] By driving dysfunctional behaviour, by overfocusing an individual or a team on performance, we make really, really bad decisions for our organisations. We encourage bad behaviours, we encourage bad work, we encourage bad efficacy.
[00:18:03] And if we're talking about this in terms of software development, I've seen it before where individuals where in a team are being reviewed and bonused and performance reviewed on characteristics that actually put them at loggerheads with each other and make them almost compete against each other in an effort to shine.
[00:18:25] Now, that might sound great to you, but are you really wanting your entire team to effective fighting against each other in a Hunger Games kind of situation?
[00:18:37] So in this episode, I've talked about the good, the bad and the ugly.
[00:18:43] The good for me is about any meeting that is helping the team or the team members to get better at what they do or to make them feel more comfortable in the case of one to one. Predominately this is about delivering value - its making the team better at what they do, make them more comfortable, more confident, more motivated. Thus that creates itself as better outcomes, better work, more value.
[00:19:13] The bad I see is being there more to help the leader. The leader wants that command and control structure - its about delivering updates, it's about being able to tick boxes, its about being able to update PowerPoint slides, it's about being able to set up the Excel spreadsheets, it's about updating documents. It's not about delivering value. It's about delivering the perception of work. The perception of progress.
[00:19:43] And the ugly are those venting frustrations. Is those things that caused active motivation or even dysfunctional motivation - in terms of either turning teams off, making them feel aggrieved, upset, feeling as if they're being blamed unfairly or that they're actually being pitted against each other, which is driving so much dysfunction within a team to the point where they can be fighting amongst themselves to actually try and achieve what they're being asked to do. Whereas, in fact, the side effect is the team just disintegrates and becomes toxic.
[00:20:25] Thank you for listening. I look forward to speaking to you again next week.