Minimising Work Done vs Building A Quality Product

I can hear you now, screaming “These two things are totally opposite to each other, how can I build a quality product if I don’t do loads of work?”, don’t worry, I’ll give you some information, and you can decide whether or not its possible.

Let’s start with minimising work done, and what that doesn’t mean.

It doesn’t mean:

  • Not doing any work
  • Not providing any functionality
  • Not writing code

It does mean:

  • Writing the least amount of code required to fulfil a piece of functionality
  • Not spending all of your time designing before you start writing code

These are both controversial items and even they are at odds with each other.

Sometimes we get great ideas, and feel that we must implement them immediately, otherwise it’ll never be done. If you feel this is happening to you, I’d ask you to ask yourself “Why won’t it get done?”. The answer here is probably because it is not important to your users. Have you asked them if they want your idea? If they say yes have you asked them if it is more important than the current priorities?

On the flip side, you might decide to spend all of your time designing your solution, so you know exactly how it will achieve the desired outcome before you have implemented it. You might even spend up to two or three days designing a solution. Inevitably, during the implementation phase of your design, you will come up against something you had not thought about. You may go back to the drawing board, and start your design again, taking into consideration what you have just learnt. This is time consuming, and is of little benefit to the overall design, as what you thought you knew is not relevant. How about, you take a rough, initial, 15 minute diagram, and give it a go. And adapt the design on-the-fly whilst implementing it. You will probably stay roughly akin to your initial 15 minute diagram, because you can adapt to what you have learnt as you implement the design. I also think it is important to go back and refactor, and remove anything that is dubious, or is not needed. Deleting code is satisfying, because it is another headache you will not have in a few months time!

The things I want you to take away from Minimising Work Done are:

  1. Take risks and try a solution, Learn from it, and adapt as you go.
  2. Start the solution with a minimal design only. Learn from it, and adapt as you go
  3. Use TDD/BDD to write just the code you need to fulfil the desired behaviour

You will still feel like you are contributing, but it will feel even better, because you will be delivering exactly what your users are after, and there will be no wasted effort.

Now, building a quality product. Quality is hard, it can take all forms of subjectivity to define quality with regards to the product you’re working on.

So start with asking: “What does quality mean to me?”

If the answer is “A product that does just about everything under the sun, or all these wonderful things I can think of.”, then we need words!

A common understanding is that a quality product is not just what you think is a good idea, it is also what your users or customers think is a good idea. It also means the things they think are a priority to them. For example, they may be able to work without actually ever logging into a system, so by forcing them to do so, you may be detracting from the usability of a product. If your application requires them to set up lots of settings in advance, but every user has the same settings, they may not even use your product at all.

Instead, turn quality into objective measures. Measuring quality is difficult, but here are some examples:

  1. Number of days the build is green
  2. Percentage up time
  3. Code coverage & testing status
  4. How many features do we deploy in a day?
  5. What is the turn around time from inception to production?
  6. How long does my automated pipeline take to deploy to production?
  7. Is there an accessibility rating for my product?
  8. How many errors do I log in a day?
  9. How many known vulnerabilities are there in my product?
  10. How many have I fixed?

The above are objective, quantifiable measures of quality, associated with a product, so that you know you are building quality in from the start. There are other measures for quality, but they really are subjective. It is still important to gain feedback from your users as to whether or not they like the product, it does what they need, and what they want next, but that forms Customer Satisfaction, rather than quality.

So, back to my original question – “How can I minimise work done, and build a quality product?”.

By creating an initial high level design, learning and adapting, and thinking about quality as a series of objective measures, you really can minimise work done and build quality right from the word go.

Functional Slice Of Cake

So often lately I’ve seen a lot of posts focussing on how to split stories, how they should be structured, and techniques for getting them into a certain state. What I haven’t seen are posts explaining the benefits, and the reasons why stories that are planned as a total slice through a system are a good idea for our development teams.

Firstly, I’d like to ask you a question: How often do your teams miss a sprint goal because of a front to back end dependency? Front to back here can be UI to API, or API to DB. Do you hear the excuse: Well the API changed and we didn’t have time to implement those changes? It’s an excuse that I have used, and that I’ve heard my teams use in the past.

The idea of slices through a system, is not a new idea, but it is one that is difficult to achieve without good planning and patience from your Scrum Master and development team, which, I was lucky enough to have in my last lead role.

I want you to think of your system like a piece of extravagant Victoria sponge with three or four layers of cake. Next I’d like you to think about how it can be cut in different ways to be manageable. You could cut it layer by layer into small bite size pieces and that would certainly be consumable, if you think you could fit six small pieces of sponge in one sprint, then it probably also fits the goal of small enough stories. But what if the aim is not to consume the sponge, but to reconstitute it, so that it all fits neatly together again? If you took it in small sections layer by layer, you would find it very hard to put it all back together, so that it was neat and presentable. Imagine what this would look like if you deconstructed the entire sponge!

Now take a new sponge of the same extravagance. Take a very thin slice all the way through the sponge. You don’t need to try to fit it all together, as it came as a connected piece. This is how we need to get our teams thinking when it comes to our stories. A great question to ask our teams is: If this is the only story you complete this sprint, does it deliver something to our users?

This something, may be just one button that they can click, that doesn’t necessarily do a lot for them on its own, but it fulfils the following criteria:

  1. It works
  2. It is useable
  3. It is displayed from the UI, and goes all the way to the bottom of your system (typically a database)

The aim of the sprint is to deliver working software, and this you have achieved. You still may not always achieve your sprint goal, but you start to reduce the dependencies and risk between different layers of your system.

The one thing that really motivates a development team is delivering working software. Nothing feels better than deploying something, and watching it work. I can tell you now, it’s a great feeling when you can deploy every story, and watch every deployment start up successfully, and for people to use the software you have just created.

One great way to ensure that your system entirely works, for every deployment is to pair your developers across disciplines. If your front end developer pairs with your back end developer to create an API, and your back end developer pairs with your front end developer to create the UI, you can almost guarantee that the solution will work. Although they may not be familiar with each others tech stacks, the underlying principles are generally the same. It’s also a great opportunity to cross pollinate a little knowledge about both sides of the same coin. If you can get your infrastructure engineers to pair with all of your developers, then each person knows how to deploy the system.

All of the above starts to de-risk the teams reliance on a single point of failure, which in turn de-risks each and every delivery the team will make.

Of course the biggest benefit here, is that if there is a weak point in the architecture or design, then it’s picked up at the earliest point, and can be rectified at very little cost.

As An Aside
I think it’s important here to mention “cross functional teams”. A discussion I recently had, is that I have no problem with cross functional teams, but that does not mean that every person in the team is cross functional. Generally, in the world of development, each person in the team has a specialism, whether they are UI, Backend, DB, Infrastructure etc. Whilst it is useful that each member of the team can fill in if a person is away, it needs to be understood, that not everyone will have the same level of expertise as the expert in the team. T-shaped people, in concept, is a great idea, but we have to be careful not to push our team members too wide, or stretch their capabilities, and remember what we hired them to do in the first place.