Gantt Charts are a popular tool for visualising dependencies for complex activities. In this episode I discuss why the use of Gantt Charts are bad for ROI in Software Development.
Or listen at:
Published: Wed, 11 Nov 2020 16:54:40 GMT
Transcript
[00:00:37] Hello and welcome.
[00:00:39] I want to start a new mini-series, Bad for ROI, where I look at a number of factors which may commonly be felt are actually good for ROI, for project delivery, and for software development. I want to challenge some perceived thinking. And over the course of a number of episodes, I'll look at one individual aspect that I think is questionable; and I'll go through why I think there's better ways of achieving our ROI.
[00:01:09] In this episode, I'll look at Gantt Charts.
[00:01:12] Gantt Charts are commonly believed to be good for planning and managing software development.
[00:01:20] So what is a Gantt Chart? A Gantt Chart is a visual representation of related tasks over time. The chart is an easy way to see how long a specific task is expected to take and inter-dependencies with other tasks that also need to happen to accomplish the end goal.
[00:01:43] Traditionally, a task will be shown as a block against a timeline. Then inter-dependencies with that task will then be shown to other tasks, so you get an idea visually what activities need to occur, in what order and which way they need to interact to achieve a given aim. Generally, they're mainly used for up front planning to give an idea of how a potential project could be worked on. Sometimes they're also used for tracking progress to enable reporting as to whether we're on track to deliver.
[00:02:26] So why do people like them? It simplification of complexity from visualisation. A picture says a thousand words, and in this case they're easy to understand. They're quite recognisable, they're easy to see what blocks are doing and how they interact with each other. Often management like them because they can see responsibilities and commitments, they're highlighting them and it becomes quite obvious what downstream effects are visible from something not being delivered as expected.
[00:03:06] So what's wrong with them?
[00:03:09] For me, a gunshot is specifically solving the wrong problem, especially for software development or anything else that's of a complex nature.
[00:03:20] The Gantt Chart is hiding other problems. Gantt Charts are good for showing complex situations where you have a variety of different activities and different interactions. But you have to question, why have you got those multiple interactions, why have you got those multiple pieces of work? You also have to think about the size and scope in terms of what it is you're trying to achieve.
[00:03:47] If it is that large that you need to have a visual representation of all the activities that need to occur and all the inter-dependencies between teams or between individuals to produce it is the actual task of trying to achieve too large.
[00:04:07] And of course, you're also talking about risk, we're trying to make something which is ultimately complex and unknown, known through visualisation. Visualisation on its own will not solve the problem that we do not know how long something can actually ever take to deliver. And yet we're building a complex series of interactions on a Gantt Chart and expecting those to be true.
[00:04:38] Ultimately, the Gantt chart produces an artificial level of certainty. Its artificially making us think we have control over what we're trying to achieve. Software development, by its very nature, is complex, it is almost impossible to produce accurate estimations upfront. It's almost impossible to produce any level of accuracy for any size of software development project. That is in nature, unfortunately, of software development. And because of its complexity, you have to question what value do you get by building a chart that is based on the upfront work?
[00:05:26] Unfortunately, because it is all based on estimate, which are guesses, we've created a document which effectively creates the artificial certainty where it shouldn't do. And because we have that certainty, it causes problems later on down the line. It gives us that false expectation.
[00:05:47] Even though what we're only doing is we're actually working from well-meaning guesses, we're guessing at what it is we're actually building, let alone how long it will actually take for it to be built. And we're guessing all of the interactions that need to occur.
[00:06:02] And, of course, the more complex this system you're trying to build and the more interactions that have to happen across teams, the more difficult that will be. And of course, that then leads to a feeling of failure and frustration when those targets, as they become, are not met.
[00:06:23] Building that Gantt Chart will set a level of expected commitment within an organisation. Now building commitment based on guesses is always going to be dangerous and almost certainly will always fail.
[00:06:36] So you have to understand then what happens when that is going to fail. Not only are you getting the word failure being used in a very negative sense, you're getting a level of frustration from management in terms of "Well, is this project going to work?", "Do we have the right people in it?", "Is it being done correctly?". Whereas in fact it is being judged based on well-meaning guesses.
[00:07:03] And because there's this negativity around the failure, many dysfunction start to appear. We suddenly find people playing a game normally around blame. We lose honesty because the team aren't prepared to be honest as to where they are - for fear that they will be blamed for it. At which point we then waste a lot of effort actually blaming each other, which is in no way ever going to be productive.
[00:07:34] So let's talk about how we actually fix some of those underlying problems so we don't even need the Gantt Chart.
[00:07:44] Let's reduce the number of interactions rather than managing them. So much of a Gantt Chart will be various activities by different teams and then trying to map the interactions between them - the dependencies. You can solve this by creating cross-functional teams, teams having the ability to get all of the work done rather than having siloed approaches to teams and having to go to individual groups to get individual actions done. Make sure that the team is capable of doing as much of the work as possible.
[00:08:26] What we don't want, is the team to have to rely on anyone outside the team. Ideally they should be able to have all the skills or the authority or the capabilities to be able to answer their own questions, to be able to approve their own work, to be able to do all the things they need to do to deliver the activity you've asked of them.
[00:08:50] If you find it's common that the team is reaching outside of itself to get work done, then you need to visit the teams authority. Or you need to visit the team skills, what's missing, what's stopping them from being able to actually do the activity that you asked them to do?
[00:09:11] And I've talked about the agile retrospective previously, an agile retrospective is a great way of trying to surface these things. Agile retrospective allows you too, as a team, look at what you're missing, looking at what is actually stopping you from being the most productive and the most capable that you can be. And again, this might be that you're missing a level of authority. Maybe you're missing a specific skill. These are the things you want your teams to highlight back up the management chain so they can be resolved.
[00:09:48] The other thing, of course, is we want to reduce the risk, which is certainly something Gantt Charts seemed to try and help us with. By visualising it, we can get an idea of what's going to happen. And we believe, unfortunately incorrectly, that we have a level of certainty as to what's happening and that we are greatly reducing the risk.
[00:10:10] What we should be doing to reduce the risk is keeping to the experimental mindset. Looking to make small iterative changes based on a hypothesis, working in an experimental manner of trying to prove whether our belief is correct. We produce a hypothesis, we find the quickest, easiest way of trying to test and validate that hypothesis, we run the test. We then take the results and decide whether our hypothesis was correct or not, and we act on it accordingly, then we iterate and we keep iterating.
[00:10:52] So if you think about that in terms of the Gantt Chart, we're trying to use the Gantt Chart to provide a level of certainty over something that is exceptionally complex. If, however, we're reducing the interactions, keeping them within a single team and we reducing the scope and the size suddenly, what value does Gantt give us?
[00:11:15] There's an argument to say your ideal Gantt Chart is a single block, which just says two, three days with no interactions. That's what you want to get to, at which point you have much more certainty. You have much less risk. As such, you've removed the need for the Gantt Chart in the first place.
[00:11:37] So while Gantt Charts can seem a really great tool and I can understand why people use them, they provide a very visual representation of a complex issue, I do fundamentally believe that it addresses the wrong problems. The problems of the interactions between teams and the scale of the work being undertaken. Thus, if you can remove those problems, the Gantt Chart no longer seems a useful tool.
[00:12:07] Thank you for listening and I look forward to speaking to you again next week.