Arguably, the most universally applicable of the principles behind the Agile Manifesto is the one about keeping things simple:
Simplicity – the art of maximizing the amount of work not done – is essential.
The first time I saw it, I had to read that statement twice. “Maximising the amount of work not done”? Surely, we’re in the business of trying to get as much done as quickly as possible?
But no, thinking more about it, it does make a lot of sense. Our goal is not to maximise the amount of work we do; it is to maximise the outcomes of the work we do. That is, we’re looking for the biggest possible impact, not doing a lot of stuff for the sake of it.
In this article, I will look at some ways the mind-set of simplicity affects pretty much every area in our work.
Simple product development
The hard thing when we create a product isn’t to come up with ideas. We can easily come up with more ideas than we can implement. The important thing is deciding which of these ideas are worth our time implementing.
Focus on what matters
To be able to judge what to build, we first need to decide what it is we’re trying to achieve and understand why that goal is important. Once we’ve done that, we need to identify how we will know whether we are successful, so that we can make informed decisions along the way.
This is where metrics come in. However, to get the most out of them, we need to narrow down the set of metrics we are trying to affect to as few as possible. In their book Lean Analytics, Alistair Croll and Benjamin Yoskovitz even talk about “The One Metric That Matters”. Depending on in which phase of our product lifecycle we are, this metric might well be different. However, at any point, let’s focus on that one specific metric.
Experiment to see if our ideas have the desired effect
The risk of features not making the difference we hope is surprisingly big. Some will even have a negative effect on what we’re trying to achieve. For example, Microsoft found that of the things they thought were genuinely good ideas, only one third improved the metric they were trying to affect.
That’s why it is so important to continually validate what we’re building. What is the smallest thing we can build to prove whether our idea is worth our effort? Let’s build that, then decide what the next small step is.
Kill features that don’t perform
If we have built a feature and it didn’t have – or no longer has – the impact we were hoping for, we need to be brave and kill that feature. It may at the time feel like a waste of all the effort we put into it. However, keeping that unnecessary complexity in our application will just slow us down when we’re trying to do the things that will make a difference.
Simple software development
Complex and unreadable code will slow us down. We must do everything we can from sneaking in in the first place and root it out when it does.
Don’t build anything until we have to
One of the many useful things coming out of Extreme Programming (XP) is the mantra YAGNI, You Aren’t Gonna Need It.
This is the idea that if we’re building something and we think we spot an opportunity to save effort by adding some other capability we anticipate we will be needing later, while we’re at it, we shouldn’t.
Far too often, we won’t end up using those additional capabilities. We will end up having spent time implementing something and testing something,which from then on also needs to be maintained, with no benefit.
Limit Work in Progress
Research has shown that multi-tasking is a myth. We can’t actually do more than one thing at a time, only switch between tasks.
When we switch tasks, it takes us a while to get up to speed on the new task. That means task switching takes us longer in total and will be more prone to mistakes than completing one task and then the other.
In our specific area of software development, task switching leads to having more code in progress or – more correctly – started but put on hold. Code not actively worked on will go stale unless we spend extra effort maintaining it.
Refactor and avoid duplication
Iterative and incremental development means adding code and complexity over time. If we don’t take the time to go back and refactor what is already there, we will end up with a code base that’s hard to read and hard to understand. What’s worse is that once this has started, it will only get worse. If we weren’t able to refactor the code while it was reasonably readable, it will be even harder later!
To be able to refactor our code with reasonable effort, we need to be able to be confident we don’t break anything. This requires automated testing or the test burden will end up being too big.
Simple processes & tools
Simple tools are surprisingly effective. Complex tools not necessarily so. For example, the audit trail in our complicated issue tracking may be useful in a “He said, she said” scenario. However, is that really the most important thing? Wouldn’t it be much more worth to avoid that situation in the first place?
Don’t add anything to our process if we can avoid it
We should start with the simplest process we possibly can and only add anything to it if we really have to. But only then!
Settle for simple tools
If we write our user stories on index cards, that makes it easy to talk about them, point at them, move them around and rip them up for dramatic effect. This way, we can focus on getting a shared understanding. If we need to store something electronically, a photo might be all we need. If we need something more flexible, maybe a Google Spreadsheet will be sufficient?
Find better ways to spread a shared understanding than written documentation
If we have a problem with information not getting handed over effectively enough, the solution should not be to try to capture the information more effectively. As Jeff Patton points out in his book User Story Mapping:
“Shared documents aren’t shared understanding.”
Instead, we should try to get rid of the mentality of throwing things over the wall, by reducing the number of hand-overs.
Challenge our own processes
Just because something used to make sense doesn’t mean it still does. We should always challenge our processes. Does it still make sense to do this?
Don’t get carried away with gathering process metrics
Metrics can be of great help when troubleshooting something but gathering and reporting lots of stats for how our team is performing is unlikely to be time well spent. In many cases, velocity or flow is likely to be enough. When we spot a problem or make a change, we can always add further metrics based on what we need right then.
Alistair Croll and Benjamin Yoskovitz in Lean Analytics again:
“Whenever you look at a metric, ask yourself, ‘What will I do differently based on this information?’ If you can’t answer that question, you probably shouldn’t worry about the metric too much”
Simple stakeholder management
In agile, the way we manage our stakeholders is through collaboration, visibility and transparency. We don’t hide information from each other. This is incredibly powerful because of what it allows us to do: we can allow our developers talk directly to customers and users without worrying about them revealing information about the project we for some reason are hiding.
We should always seek the simplest solution to the problem we are trying to solve.
Ask the team!
Don’t try to come up with the perfect solution to the team’s problem. Ask them! As Scrum Masters, we don’t need to have all the answers. In fact, it’s much better when we don’t. When we are observing a problem, it’s not our job to try to fix it. Instead, let’s take it to the team. Do they agree there is a problem? If so, how do they think it’s best solved? They are more likely to be able to come up with a solution than we are as they understand the problem better and they are the ones affected.
Change one thing at a time
Just like any other work in progress, we need to limit the amount of change in progress. If we’ve got too much going on, we won’t be able to judge reliably what has a positive effect and what doesn’t. It will also be harder for people to know what’s expected of them.
Improve every iteration, a little bit at a time
Small changes are quicker and easier to implement and more likely to stick. And they will all add up! If we manage to deliver 5% more value each 2-week sprint than the one before, that’s a 200% increase by the end of the year.
Craig Larman is the co-inventor of the LeSS scaling framework and makes his living from implementing Scrum in large organisations. The first point he always makes is that we should never scale unless we absolutely have to.
Paradoxically, a small group of people may be able to achieve more than a large one.
When we scale, we will create additional overhead through the need for coordination and the introduction of dependencies. Often, this can lead to local optimisation, where each team work hard to deliver their bit as effectively as possible at the cost of delaying the product delivering value.
The simplest doesn’t necessarily mean the easiest.
Unfortunately, simple doesn’t always mean easy. Sometimes, picking the route of the least resistance is what creates all that unnecessary complexity in the first place.
- It’s easy to ignore a problem. For example, it can be scary to try to resolve a conflict in the team. It will be much easier to ignore it but that will make working together a lot more complicated.
- Not writing automated tests is easy. However, over time, even what seems like a trivial change will become prohibitively complicated.
- Adding code without going back and refactor the existing code is easy. However, this will add more and more complexity to our codebase. The code will become harder and harder to read and understand.
- Adding features is easy. Avoiding adding features that will do little to improve our metrics is what will give us room to do what matters.
- Simply guessing what to build is easy. Getting it right is much harder.
- Adding lots of steps to our process is easy. The complexity we add by doing so will limit our agility.
- Dropping quality is easy. Having to maintain a low-quality code base is complicated.
Finally, it’s easy quoting Steve Jobs but he did put it quite well (BusinessWeek, May 25, 1998):
“That’s been one of my mantras – focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”
What are your best ideas for keeping things simple? Please share them in the comments below!
And if you’ve got a few minutes to spare, it would mean a lot to me if you would complete my short survey about Scrum.