t’s a quiet Friday afternoon in the kitchen area at Code. Several of the Code team are sat around a long table listening to Ken — our Lead Agile Tester.
He’s got some dice, cards and sheets of paper in front of him as he calmly explains the rules of the game everyone’s about to play.
As suggested by his title, Ken leads the test discipline at Code. This is a discipline that used to sit quite far downstream in the website development process — testing what had been built before it went live — but is now involved from the very start. This makes sense for all kinds of reasons but mainly, if your job is to test things and find problems, then you’re going to have a really good idea of where things are likely to go wrong and how to avoid it. The further upstream you have this expertise, the better.
One thing that’s a major cause of websites going awry in development is technical debt, or more precisely, not dealing with technical debt properly. The game that Ken is teaching others to play aims to instil an understanding of how technical debt should and shouldn’t be dealt with and gives people the confidence to push back when they can see it being ignored.
Technical debt can be a lot of things but essentially, it’s the problems that mount up when you don’t do things properly in the first place. For example, not documenting your work properly will lead to quicker work in the short term, but in the future will cause a lot of extra work and stress for anyone who needs to figure out what you’ve done and why. It could also be outdated technology that should be replaced but has just been patched up over the years.
Ken likens it to building a tower out of playing cards. If you have a kink in one of the cards, then it doesn’t really matter when you’re at the point of building the bottom row. In fact, you’ll get that row done much more quickly than if you were to try and iron out the kink or find a replacement card. The dodgy card is technical debt. The higher you build, the more difficult it becomes to ignore the kinks and the more likely that the whole deck is going to collapse.
The game simulates building a website, with the rolls of the dice representing the amount of ‘stuff’ or points that you deliver. Cards are introduced throughout the game which increases the technical debt.
Essentially, the aim of the game is to build the website as quickly as possible.
The game consists of three rounds, which equate to different strategies for dealing with the technical debt build up.
– In the first round, you ignore technical debt
– In the second round, you deal with it as you go along
– In the third round, you plan time in to deal with the technical debt.
So, what happened in the game?
From the image above, you can see that we added value for the first three sprints and then when we hit the fourth sprint, a technical debt issue was introduced. This had a massive impact on new value — as time went on, technical debt started to build up more and more issues. By the 6th sprint, no value was being delivered.
During this round, technical debt was introduced on the fourth, sixth, eighth and tenth week. There was an impact on the following weeks, however, once the technical debt was handled, we saw an increase of new value.
We delivered a cumulative value of 212 points (stuff being delivered) against 57 in the first round.
This time, the team were aware of what was coming in terms of technical debt and they could handle it at any point.
The team took on the larger impact technical debts earlier on to wipe out that debt and to get more new value delivered later on.
The total points delivered came out at a massive 408 compared to the 212 in round two and 57 in round one.
It’s obviously way more gratifying to point to a new feature on a website than to point to some documentation or an ‘invisible’ behind-the-scenes upgrade. The pressure is always going to be on to go faster and deliver more.
In an ideal world, you wouldn’t need a game to explain the importance of doing things properly. However, the lessons and culture that the game helps to generate and maintain within Code means that we’re all less likely to bow to pressure or cut corners with clients.
Or, as Ken says, “Don’t create tech debt and put it in the backlog to resolve later on, — it will come back to bite you on the arse at a later date.”