Post #51

Post #51

It is a year since I started this blog. In my first post, I outlined why I was committing time to write a blog post once a week. I was aiming to improve the way I communicate. Whilst there is a long way to go, things are going in the right direction.

I find is easier to sit down to knock off 500+ words on a particular subject. I have discovered way to refine a post through a number of revisions and speed up the time it takes to review a post for mistakes. Setting myself a goal of writing one post per week acts as an excellent incentive and publishing a post on a Friday night gives me the motivation to find time during the week to do some writing.

The most insightful thing for me though has been the stats on which posts have been the most popularly. I don’t get huge amount of traffic but I’m surprised at the levels I do.  The posts that ended being widely read were unpredictable but they are helpful to understand what I should write about in 2017.

I hope you have enjoyed this blog during 2016 and I hope to produce some more useful posts in 2017.


Context Switching

Context Switching

I try to avoid Absolute Thinking but I’m going to make an exception.

Context Switching is never a good thing.

I guess I’m going to have to justify that statement

The Problem with Context Switching

Whenever you read about the problems with context switching in IT it isn’t long before you find this 2001 article written by Joel Spolsky, called Human Task Switches Considered Harmful. It describes the complexity of software development where the developer has to juggle many abstract concepts in their head. It takes time to build up this mental model. Building it has a cost so it makes sense to hold on to it for as long as possible. The inevitable context switch means that a mental bookmark has to be used to keep your place, do the task that caused the interruption and then direct focus back to the original task.

However, it is not a simple as flicking back to your bookmark and continuing where you left off. You have to pay a cost to switch back. The state of mind at the point of switching has to be retrieved from memory and then the mental model reconstructed. It is a bit like the process of deserializing an XML or JSON file into an object graph. For each context switch you have to pay the price twice so it follows that the more you context switch, the higher the cost. The expense of context switching should never be underestimated.

It is often that the people that have to context switch heavily are the people that you rely on the most. There is a tendency to want to spread these people across as many things as possible, adding their magic to multiple projects. Let’s not forget they will be aware of that expectation, they will have no choice but to except the context switching, but they’ll feel that they can’t get anything done.

Why people think they are good a context switching

The mind is a wonderful thing, it adapts to your situation, it finds short cuts and efficiencies. All this means is that you are reducing the cost of context switching to some degree, but it is not completely removed. This is what people mean when they say that they are good context switchers. They mean that the cost of switching is slightly reduced – but it is still being payed.

Generally, people get used to context switching and accept it. The feeling of not achieving anything becomes so constant it fades into the background. How many times have you failed to tick off your daily to do list because you have been doing something else that was unexpected? How often have you thought that the day has been a write off and you haven’t achieved anything? How many times have you detected that sigh, when asking that same subject matter expert yet another question?

Strategies: Avoidance

The most obvious way to avoid the cost and mental energy drain of context switching is to take steps to avoid it all together. Try to focus on one task and see it through to the end. The reality in most organisations is that avoidance is not possible. Being able to focus on one task may not even be in your control.

You have to communicate, we are bombarded with notifications, modern UI interfaces are designed to distract and then hold your attention and modern software development encourages more communication.

Knowing that you have a problem with the inefficiency of context switching is the first part of the solution. You now are aware of the drag that taking on that extra project will have. Turn email, phone and other notifications off when you need to focus. Often the universal “I’m busy” signal can be a wearing a pair of headphones. This is often enough to filter out the minor distractions but the important ones will still get through.  This needs to work both ways. As you set aside time to “get on with stuff” you also need to make time to deal with distractions.

What happens when the distractions are regular and constant?

Strategies: Acceptance

When people from a technical background find themselves in a position of leadership or authority they often feel like they are not achieving anything. They had been creating working software but now find themselves in meetings or helping other people in their team.

However, you are achieving something, but the goal posts have moved. When you lead that design workshop, you were helping your organisation meet its business objectives. When you were mentoring members of your team, you were helping them develop high quality software.

The point is that you may simply have to accept the context switching that comes from this role. You have to accept that you are helping your team be productive rather than yourself. It is just about setting expectations.

Again, you are able to manage it. If you are constantly getting asked the same question, create a FAQ. Get in early to give yourself some “me” time. And if you really can’t scratch that “need to achieve” itch you might be able to find side projects outside of your working time.

Why Agile Ways of Working help?

Frameworks such as SCRUM designate communication and working time. Ceremonies such as planning, stand-ups and retrospectives formalise communication and do so at a regular cadence. Doing this regularly sets an expectation that this is time to organise. It greats a habit. Outside of this is worktime. Worktime is intended to be calm and a time to minimise external distractions. The team still has to communicate but they can reduce distractions by focusing on a small number of things keeping context switching to the minimum.

  • You plan together as a team to a single goal.
  • Each day the team synchronises to ensure that everyone knows what they are doing but help can be apportioned when needed.
  • Work in progress is minimised to avoid having to switch focus.
  • A role such as a SCRUM master protects the team from anything that would cause them to lose focus.

Sounds like a good idea!

Chaos Driven Development – Agile Anti Patterns

Chaos Driven Development – Agile Anti Patterns

I guess if you are reading this you will have some understanding of Test Driven Development or TDD. Whether you buy into it or not, the basic concept is to incrementally build up a suite of tests that act as a framework in which to build your code. The test suite acts as an executable specification that determines whether the code fulfils its purpose. It can also be used to ensure that only the code that is needed is written. If code is written that is not causing a failing test to pass or improve the overall quality of the code base, then does this code have value?

I like to think of the test suite acting as pressure that drives a solution forwards in a given direction. A test suite is not the only type of pressure that can be applied to development, there are other types. The one I’d like to focus on here is chaos.


  • Complete disorder and confusion

It is not really chaos itself that is the pressure, it is the emotional effects that result from it. Okay, some people thrive in chaos but for the rest of us, it generates worry and concern. Some people switch on the heroics but others become stressed or are unable to act through the fear of doing something wrong. Fear Driven Development is a related concept.

With TDD the developer is motivated to write code that turns the light green. This often (although not always) generates code that is simple, logical and easy to maintain. On the other hand, when people are under pressure due to chaos, the motivation is to remove the pressure at all costs. This leads to short term thinking, designs and good intentions go out of the window and “good enough” and “that will do” become the norms. Unfortunately, the short term thinking creeps out to other stakeholders and suddenly the developers who are hacking at code to alleviate the pressure get the kudos by being rewarded for their heroics.

With TDD people often forget the refactoring bit. In Chaos Driven Development you don’t have the chance to improve things. You are already a hero and you’ll be needed to go into battle fighting the next fire which is even more likely because there is never enough time to fix things properly.

Test Driven Development Chaos Driven Development
Can simplify the code through Red – Green – Refactor. Can generate spaghetti code by patching the symptom rather than understanding the root cause.
Testing is built in and automated. “It worked on my machine!”
Regression Safety Praying a fix hasn’t introduced another problem and “that was working last week!”
Code Ownership through collaboration “I’ve got this” and “X is leaving, what do we do now!”

Chaos Driven Development is unsustainable. It leads to stress and low morale which leads to people leaving. When someone leaves, particularly if they are considered a hero, it is just another fire to put out which adds pressure to a team that might already be at breaking point. The problem is only going to get worst – the fire will start to burn out of control. And when that happens often the only option is to build some fire breaks around it and let it burn out.

No planning fallacy – Agile Anti Patterns

No planning fallacy – Agile Anti Patterns

Traditionally, the planning fallacy states that when an individual is estimating a task, which is similar to another task they did in the past, they tend to be optimistic and underestimate the effort required. It also states that whilst the effort is often understated the potential benefits are overstated.  Scale this up and the results are project over runs and benefits short falls.

Let’s set out to overcome the planning fallacy – lets simply not plan and that will make us Agile in the process!

Joking aside, some attempts at Agile delivery start out like this and tend to end badly for all involved. There is no stability, no predictably and ultimately no happy customer. After all, we are doing this to make a customer somewhere happy. We are not doing this to be a zealot.

Agile software development emerged from more structured approaches because many projects delivered this way failed, many because the plans were too big, too detailed and importantly, they lacked flexibility. Our customers want predictability in one form or another so what do we do? How do we overcome the Agile No Planning Fallacy?

In “Why Plans Fail: Cognitive Bias, Decision Making, and Your Business”, Jim Benson covers the following areas that can lead to the Planning Fallacy

  • Precision Bias
  • Discounting Variation
  • Best Case Scenarios and the Mythical Man Month
  • Overwork leads to Under-memorisation
  • Context Switching
  • Alleged Anomalies
  • Good Will / Rosy Retrospective Syndrome
  • Politics

I wanted to touch on a few of these

Precision bias, Discounting variation & Best case scenarios

This means assuming that estimates are precise and accurate and only considering the best-case scenario. As stated in the first paragraph an individual estimate is more likely to be too optimistic and it is personal so it doesn’t scale to another person let alone to members of other teams. We are often asked to estimate for best case scenarios. When have we ever had a situation where nothing goes wrong?

Context Switching

I’m unlikely to be convinced by someone that says that they are a good context switcher. In fact, I need to write that down because that is a blog post in itself…

20 mins has passed between that last sentence and this one. I started making a note for another post, then a notification went off on my phone, which I started to read and now I’m back here. What was I saying again?

Stop telling me you are good at context switching. You are just better at coping than others. That doesn’t mean context switching is good. Even if you are the best I don’t want you doing it. I want you to focus and get on with the task in hand. Just stop it.

Addressing the Planning Fallacy

There are a couple of other things that help to reduce the planning fallacy. The first is sizing relatively, but what does that mean? An absolute estimate might be 2 hrs or 3 days. Often when people hear these estimates they immediately starting thinking about the end of the effort rather than the effort itself. They might get into mythical month territory if they don’t like the sound of the end date. “3 days you say, so it will be done by the end of tomorrow if 3 of you work on it!”.

Relative sizing approaches this differently. Firstly, there is no time connotation. This aims to terminate the behaviour of trying to map the work to a calendar. The size of the work is only measured relative to each other. T-Shirt sizing is good for this and so is using a clear, none time related unit such as “baguettes”. “This piece of work is 2 baguettes but that one is 10 baguettes”. (Baguettes was really the unit we used on my first Agile project.) Time is not the only dimension removed from a relative effort. Relative estimates do not imply how the team will organise itself to deliver the work. A “large” is still a “large” if one or five people are doing the work.

The second is group estimating. This is eliminating some of the bias by depersonalising the process. In my experience, it often spurs debate means the work is sized for the more realised scenario rather than the best case. Not only is about discussing how to approach the work as a team and discussing alternatives – it demonstrates the wisdom of the crowds.

Planning works best when it is done little and often. It is a continuous process and not something you do at the start. Remember why you a planning. You are trying to understand what is the next most important thing and understand what your team can do in the next increment. Relative sizing and evidence of the rate at which the team works is enough to do that. Using Ideal days gives the team the flexibility to deal with variations and anomalies and the capacity to do value added activities when things are going well.

Planning is not about precision nor it is able create something that can be executed without thinking. It is not about “no planning” – instead it is about “smart planning”.