Are Code Reviews Waste?

I cross posted this post on Medium.

"Waste" is NOT a Dirty Word

My recent talk Agile is a Dirty Word generated a lot of interest at the conference at which it debuted and on social media since. More, in fact, than I ever thought I would get for any of my talks. One of the themes I examined in this talk was waste. This came quite early in the piece and one of the points I was making is that (unlike Agile, Kanban and various others) "Waste" is NOT a dirty word. What I mean by this is that whoever the client is (in my experience at least) and whatever stage of Agile maturity they are at, "Waste" is a concept that people understand and want to reduce.

An "Innocent" Value Stream Mapping Slide

I wanted a way at my client to convey how certain activities don't add value to the business and should therefore be considered to be waste. The slide I came up with for the client was designed to illustrate a very simple value stream map and start a conversation over which activities add value and which are waste. I reused the client slide with only a change to the title in Agile is a DirtyWord. Here is the slide as used in Belgium:

I use the word "innocent" in the title of this section because, as is usually the case, nothing on this slide was ever accidental or innocent. When I originally showed this slide to our client (it has transitions that make parts of it more obvious) I knew that "CODE REVIEW" down in the waste part would be controversial. I knew that several people at our client were obsessed with the idea that code review was an important part of their delivery process. So whilst "code review is waste" was not the title of this slide when I showed it at the client, I very definitely wanted somebody to notice it was flagged as waste and challenge it. This did indeed happen which "coincidentally" let me introduce the subject of why we think code review is waste in the course of talking about something completely different.

What is Waste?

In the rather simplistic model above, I have a notional timeline for a story moving across a wall. We have to assume that the thing that is moving across the wall is valuable. That is to say, I'm assuming that some sensible work by a product owner or similar has taken place and we are confident that when this thing gets released in to production that it will return some value to our company. Note the key point here is that when this thing gets released to production it will return some value to our company - NOT BEFORE. So the clock starts ticking from the point when the story's value statement is articulated and ends when it is live in production. During that time, anything that doesn't help the story move along the wall is waste.

What Outcome is Supported by a Code Review?

One question that we often ask our clients is "what outcome does this process support?" Sometimes you can ask this question of a particularly silly piece of risk management theatre and it can provoke anything from mystification to ultra defensive cat-bear-trap response to complete silence. All three responses, by the way, are a great sign that the process being questioned is unconnected to any real outcome and thus devoid of any value. When it comes to asking this question about code review, however, I've generally received a response along the lines of "code review ensures good code quality" or "we need to check that the code works". So assuming such a response is offered, we can't argue the thing away on the grounds that it can't be linked to a desirable outcome, since "working code" or "code quality" are both outcomes we should be looking for. So why do I argue code review is waste?

What REALLY Happens in a Code Review?

Disclaimer: I am writing this section based on my own personal experience. If anybody has worked in a situation where better things happen with respect to code review I'd love to hear how those better things can be made to happen.

I would also add that all of my comments refer to an organisation where the team is co-located or at most distributed over two sites. I am not considering an entirely distributed team.

The Process

Usually, a code review is requested by a developer when they want to merge some changes into a mainline. This results immediately in the request for code review waiting in a notional queue somewhere for somebody to act upon it. This is undeniably waste, all queuing time is waste, I don't think there is any argument on this one. When somebody "picks up" the code review all they can typically see is the changes made to the code. Depending on the diligence of the reviewer or, more likely, whatever time they perceive they can spare from their "real work", they might fire up their code editor and view the code changes in the wider context of whatever code base it lives. They then annotate the changes (using whatever tool they use) with any suggestions for improvement and update the status of the code review to something like "suggestions for changes made" or whatever the workflow tool in play dictates. At that point the review goes back on the queue of the person who requested the review (more undeniable waste), they react to the suggestions as they see fit and then the cycle repeats until the code reviewer "approves" the changes.

The Comments

Again, I repeat my disclaimer. There are two types of comments that I have seen. The first type are utterly unrelated to anything the code does at all. An example of such a comment would be "We should put opening braces on the same line as a function signature, NOT the line below", or one of my particular favourites "You have used a tab character of width 3, instead of 3 spaces, for your indent" (how did this person even spot that?) These type of comments are not only entirely devoid of value whatsoever, they are irritating, probably passive aggressive (I'm still never quite sure exactly what PA means but I think it applies here) and DEFINITELY should be caught with whatever linting tool is play.

The second type of comment I have seen would be along the lines of "you used a for loop to iterate when you could have used foreach" or "this slightly different way of doing it will be more efficient". Whilst I have slightly more sympathy with this type of comment I still don't think it is worthy of note unless there is specifically something about the implementation that is "wrong" or would be likely to cause some kind of real performance issue.

A Useful Comment

A useful comment could be something like "the tests don't cover all the edge cases" or "There should be an integration test of this thing". I have never seen this happen. Why? I think the answer is that the reviewer lacks the context of the story that was played and therefore lacks the knowledge to make any really useful comments about actual functionality.

Does Code Review Support the Suggested Outcomes?

If we assume that the types of comments that get passed around fall under the not useful categories mentioned above then I struggle to accept that code reviews do anything to support the outcomes of "good code" or "working code" and I would therefore argue that all such process is waste.

What If the Comments are Useful?

This is the tricky part of my argument. I have had some people argue that there are useful comments in the code reviews that happen at their company. As I say, I have never seen this in any review that I've been involved in but I'm prepared to accept that it can (and probably does) happen that some useful comments are sometimes added to code reviews and acted upon by the original developer. Is such a code review waste?

I believe it is still waste. Why? Firstly, the queuing time is there, whatever you do. Secondly, there are at least two context switches involved for different people to support this process. Context switches are expensive and add no value to any process. So they are waste. Thirdly, there is a better solution to the outcome of "good code" and "working code". Both of these outcomes are more easily achieved through pairing or mob programming and you get shared context and therefore better bus factor, into the bargain. Perhaps, if the outcomes actually are being legitimately supported by a code review process then I should downgrade my claim from "code review is waste" to "code review is an anti-pattern". I think that may be semantically more accurate in this case but "waste" is somehow more tangible a thing to eradicate than "anti-pattern".

Can Code Reviews be Value Adding?

I mentioned above that certain code reviews might be arguably an anti-pattern rather than straightforward waste. I'm prepared to accept that they add value if the following things are true:

• Instead of the workflow, with all the queues mentioned above, the developer requesting the review approaches other developers until she finds somebody available to help with the review.
• The code review is carried out together between the developer and the reviewer. All suggestions are therefore discussed and collaboratively acted upon.
• Assuming there isn't the need to do any major extra work (perhaps after sharing the context it becomes apparent that the suggested solution just doesn't do what it is meant to do) the pair will continue until they are satisfied with the result and they will then merge the changes as part of the workflow.

According to the authors of Design Patterns, an anti-pattern has the following characteristics:

• A commonly used process, structure, or pattern of action that despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones.
• Another solution exists that is documented, repeatable, and proven to be effective.

I think I have argued that in general code review fails in its goals and thus fulfills the first part of the definition. I strongly believe that there exists at least two better solutions - pair programming and mob programming. So it is therefore my contention that code review is at best an anti-pattern and at worst (and this is the more likely scenario in my experience) waste.

What are Memes and why Should I Care?

What are Memes?

The Modern Social Media Version

In recent years, certainly since the explosion of the Internet, and more particularly of social media, the definition of "meme" seems to have changed somewhat. Now, a meme seems to be understood as being something, usually trivial or somehow amusing, that spreads virally across the Internet and refers to some aspect of popular culture. Usually these memes are picked up and altered slightly by each user to fit a new context or to slightly modify the joke. Eventually, if the meme proves popular or durable enough, it can end up having a version of itself on a site like  Meme Generator which allows anybody to quickly and easily propagate the meme within their own social network.

Examples

I myself am not averse to jumping on any memetic bandwagon. I can think of at least two memes that I have been guilty of propagating at one time or another.

Disaster Girl

This one has to be my all time favourite. Probably because the original picture reminds me of one of my daughters. Oh, but for the grace of god, fire-department-safety-demonstrations and the fact that this happened before Felicity was born, she could have been disaster girl...

I suppose 305,000,000 hits on Google shows the reproductive power of this one.

XZibit

I like this one too. I came across this one while I was working on a project for ThoughtWorks. I, of course, had never heard of XZibit (he's a rapper) but apparently this derives from a TV program called (I think) "Pimp my Ride", hosted by XZibit, in which the car of a member of the public is customised or "pimped". I think I have seen a British version of this program.

Only 6,330,000 hits for XZibit, nowhere near the league of Disaster Girl but still a healthy reach. Interestingly, the meme is more popular than the person it seems beause when I Googled for XZibit I got 5,120,000 hits. The above search was for XZibit Meme.

What appealed to me about this one is that it is supposed to be somehow recursive. When I had that expained to me I was all over it, even without the popular culture knowledge to support any understanding of how it originated. I think this may speak to the intrinsic "value" of the meme and its ability to reproduce itself. I'll come back to this idea later. I used this meme when I found out that defmacro in Clojure was itself a macro.

The Original Definition

I have recently finished reading The Beginning of Infinity by David Deutsch. I thoroughly recommend it if you haven't read it. The central theme to the book is knowledge, what it is, why we acquire it and how we acquire it. One of the things that is returned to more and more as the book goes on is memes. What they are, why they are important, how they are sometimes useful and how they can be damaging.

The word "meme" was coined by Richard Dawkins in his 1976 book, The Selfish Gene. He uses it to refer to an idea that replicates. I haven't read this book at the time of writing and I'm therefore using the definition of meme that I got from Deutsch. The interesting argument is that there are ideas that can replicate through people and culture sometimes without showing any obvious benefit or advantage to the host for the idea. So a meme is an idea that self replicates. That is it. Apparently Dawkins was surprised that his idea of "meme" became something that lasted so long and (I assume due to semantic diffusion) took on so many different forms.

Examples

According to the Dawkins definition memes can take many forms. Some are useful and certainly convey value to the thing that propagates them. Some are most definitely sub-optimal in many respects and seem to somehow persist despite their lack of obvious value.

In the animal kingdom an example of a useful meme could be the way that apes can translate the knowledge of how to use tools, such as stones, for a specific task, such as breaking nuts, in a way that is useful to the recipient of the meme.

There is a much richer set of examples to choose from in the human species. The distinction that I want to examine further is that of rational memes v anti-rational memes. There isn't a great deal of time given to why anti-rational memes evolve originally in Deutsch's book, instead it concentrates on how these memes persist and replicate. An example of an anti-rational meme given is that of racist behaviour within sub-cultures inside a largely rational culture. There seems to be little value to the host in holding such views, or of propagating the racist meme to another host. But it certainly persists as do several other memes that present as irrational prejudice.

Memes in Business

So if we assume that the definition of a meme is an idea that somehow has the ability to replicate then why am I writing about it? Well... As I read The Beginning of Infinity there were a few places in the book that made me think about some of the clients I've worked for. To summarise what I read, Deutsch postulates that anti rational memes can exist in society and can be a reason why societies are static societies as opposed to dynamic, learning societies. A static society is characterised by an aversion to new ideas, suppression and possibly fear of new ideas. A dynamic society that encourages criticism of ideas and assumed knowledge is much more willing to abandon its memes or take on new memes as reasonable criticism may demand.

The Corporate Immune System

The corporate immune system is a real thing. I've seen it in many different places and I've seen its destructive power. In a modern (aspirationally) agile business, the corporate immune system is the very antithesis of agile values and mindset. I have previously speculated as to how it evolves and have read several theories. I think memetic, self replicating knowledge and behaviours could be part of this reason. Risk aversion and the corporate blame / hero culture are very much responsible too but perhaps those things are themselves memes?

Risk Management Theatre

I have previously written about Risk Management Theatre and in particular how it can comprise many behaviours and processes that just don't make sense now (even if they may have done originally). Something makes these behaviours and processes persist. Is this some kind of memetic groupthink?

Perhaps this is exactly why risk management theatre has a power to persist beyond which any rational thought (at least that I have previously considered) should allow. But when I think about this new understanding, for me, of what a meme is and what memetic knowledge is it begins to make a bit of sense. I mentioned earlier that I propagated the XZibit meme without ever having an understanding of its origin. Is this similar behaviour to what I see within an enterprise where new staff carry on the by now irrational behaviours just because that is the way it is done?

If we go right back to the dark ages or earlier, when most societies were tribal, it probably made sense to be suspicious of people who did not come from your tribe. It could have been a sensible precaution for there to exist a cultural meme which caused distrust of people that were not from your tribe. It clearly doesn't make sense any more. So perhaps this meme that was once rational is now anti-rational. But does it still exist in the 21st century in otherwise rational societies as the remnants of this earlier meme?

So my question is, is risk management theatre as powerful and hard to destroy as it clearly is because we, human beings, have an inbuilt mechanism to recognise, (rationally or irrationally) value and propagate memes? Is a risk management theatre process a meme that was rational at its inception, has become anti-rational, but still maintains its power to reproduce itself and live on in the enterprise? Does it not even matter to people hosting the meme that they have no idea of its origin or its original value? I don't know the answers yet but I'm going to continue to ask the question.

More Devoxx, More Talks

Three Conferences in November

I already blogged about Devoxx Belgium. That was a few weeks ago now. The week after that, on Thursday November 22nd, I flew out to Kiev for Devoxx Ukraine. The conference was on Friday 23rd and Saturday 24th, I flew back on the evening of Sunday 25th. 

After a couple of days recovery at home, I flew to Marrakech for Devoxx Morocco early in the morning of Wednesday 28th November. I was out of bed at 4:30AM for a 5:00AM taxi. It was (almost literally) a flying visit. I got to the hotel in the early afternoon, had lunch, walked to the conference venue, had a look around, met a friend, walked back to the city, had a look around, had dinner, found what seemed like the only place in Marrakech that served beer, had a couple, went to bed, got up, went to the conference, did my talk, saw my ThoughtWorks colleagues talk, had a quick beer with them, got a taxi to the airport and flew home. I got back home around 1:00AM on Friday November 30th meaning I had been out of my house for only 44 hours. Not surprisingly I was somewhat tired.

So in three weeks in November I presented 6 talks at 3 conferences in 3 very different locations. At the time of writing Devoxx has published the videos from Belgium and the photos from Belgium and Ukraine. I thought I would commit some of the highlights to this blog.

Belgium and 900+ People

I already wrote about Devoxx Belgium and posted a selfie from my talk Agile is a Dirty Word. While I was in Ukraine I had a chat with Stephan Janssen, the founder and owner of the Devoxx conferences, amongst other things about how the new Devoxx websites and apps work. In Belgium, Alasdair Collinson had postulated to me that the Devoxx app was reassigning talks to rooms based on the number of likes that people had given the talk synopsis. He therefore speculated that my talk had been moved from one of the smaller rooms to the largest room in Antwerp. Stephan confirmed that this speculation was indeed correct. As my talk had in excess of 3x the next highest talk scheduled at that time, it was indeed moved to the biggest of the 8 theatres. He further went on to tell me that there were 850 seats in that theatre (I had it at around 300 - 400) and that he estimated that there were in excess of 900 people watching given the number of people that were sitting in the aisles.

Here is a picture of me with part of that audience and the MASSIVE screen behind me...

Just to keep my feet on the ground, here is a picture that they smuggled of me when I was finding the only quiet place in Antwerp to have a remote meeting with some of my ThoughtWorks colleagues on the Wednesday afternoon:

Some Kind of Weird Dance

I never script my talks. I use the slides, which have been occasionally (and quite fairly I think) been criticised for being too wordy, as the basis of starting the conversation that I'm going to have with the audience about the subject that I'm raising. One side effect of this is that each time I present a talk it is different and I can't guarantee that I'm going to say the same things or emphasise the same points. Sometimes it goes off on weird tangents. I haven't watched the whole of the video from this talk yet but when I do, one thing I'll be curious about is what, exactly, I was doing when these photos were taken:

The mind boggles...

Devoxx Ukraine and 3 Talks

From the outset I was set to present two talks at Devoxx Ukraine. They were What Drives Your Development and Are Quantum Computers Really a Thing? (quick disclaimer, these videos are not from Ukraine because at the time of writing the Ukraine videos weren't available). After the success of Agile is a Dirty Word in Antwerp, I noticed that there were a handful of sessions in Ukraine that were TBC so I sent an email to the organisers directing them to the video from Antwerp and suggesting that I would he happy to present this talk again. They duly scheduled me as an added bonus. So three talks it was in Ukraine!

Diversity

One thing that was noticeable about Devoxx Ukraine was a distinct lack of diversity. Of course the IT industry is notoriously male-centric but unfortunately Devoxx Ukraine was almost a female free zone. There were almost more female speakers than attendees. Not the fault of Devoxx of course, it just goes to show that some parts of the world haven't moved on as much as others.

The Trip to Chernobyl (nearly)

The conference kindly organised a trip to visit the Chernobyl reactor on the Sunday morning. Prior to the trip we had to submit our passport details to satisfy some kind of security protocol with the Ukrainian authorities. Whatever the security checks are (and I assumed them to be some kind of security theatre) one, or perhaps more than one, member of the party was declared persona non grata by "the authorities". So on Saturday morning we were told that the trip was cancelled. Apparently if one person in the group is considered unacceptable then none of the group is allowed to visit. At least that left us free to enjoy Saturday evening as it meant we no longer had to meet in the hotel lobby at 6:30AM to get a coach to the site of a nuclear disaster.

Some Memories from Kiev

I cropped this one and used it as my new profile photo in various places.

I didn't realise there was a telly with the slides on it. I could only see the thing behind me.

There was a laser lattice thing on the way in to the conference.

There are lots of yellow buildings in Kiev including this rather wonderful cathedral.

And some rather less impressive looking architecture. I was particularly perplexed by the way this 1980s-(presumably Soviet)looking-grey-building thing appears to be sort of glued on to the rather pleasant yellow building next to it.

Here is my ThoughtWorks colleague Aiko with me as we were on the main stage with the other speakers during the closing ceremony of the conference.

And finally here is the picture of all the speakers on the stage at the end.

Summary of Devoxx Ukraine

Another great conference from Devoxx. Very well organised but Ukraine must try harder on diversity.

The Last Leg - Devoxx Morocco

I was truly exhausted even before I flew to Morocco. Given the swift in and out nature I didn't get to see much of the conference. It was a lot smaller than both Belgium and Ukraine but, somewhat surprisingly, extremely diverse by comparison. There was apparently around 30% female attendees where both Belgium and Ukraine were under 5%. Probably this is up there with the most diverse of conferences I've been to. My guess is Agile on the Beach or Lead Dev in London have the highest proportion of female attendees that I've known but I have no data to back that up. 

My only talk in Morocco was What Drives your Development which was being wheeled out for the third consecutive week. It went down pretty well again, this time without the time honoured Martin Fowler from Eastenders joke. I decided that since that joke falls flat in Western Europe and Eastern Europe, in fact anywhere other than the UK, it would almost certainly fail in Africa!

I didn't realise that the snow capped Atlas Mountains would be visible from Marrakech.

I saw this cat in the city centre. A cat with markings that look like a heart! My daughters love this cat and I will surely work it into some presentation somewhere. I have to, Woody Zuill told me that you should always put at least one cat slide in every presentation...

The square in the old part of Marrakech is quite spectacular at night.

My colleagues Oli and Monira presented this talk in both Belgium and Morocco. I missed them in Belgium as they were talking on the Friday and I was gone by Thursday evening.

And thus ended my November World Tour of conference speaking. I have nothing more planned until January, which is Snowcamp in Grenoble. For now, back to the harsh realities of working for a client, if only I can get staffed somewhere...

Devoxx Belgium and Two Talks

TL; DR;

I was at Devoxx Belgium last week. Great conference.

The best talks I saw were Rethinking Software Systems: A friendly introduction to Behavioral Programming by Michael Bar Sinai and Untangling the mysteries of qubits by Roy van Rijn.

I was lucky enough to do 2 talks:

What Drives Your Development? - a lightning talk not intended to be taken 100% seriously.

Agile is a Dirty Word - a much more serious, full length, offering about tackling the problem of Agile having become toxified through misapplication and misunderstanding.

The conference

I've been to a few Devoxx conferences now and they are always fantastic. The organisation of the conference itself is typically superb, the audiences are knowledgable and polite and I've always been looked after really well as a speaker.

Devoxx Belgium was bigger than I expected it to be. The venue was Kinepolis to the north of the centre of Antwerp. As with many conferences, the venue is a multiplex cinema. This particular multiplex cinema had 8 theatres of varying sizes (from big to absolutely massive). For most of the sessions all 8 were in use simultaneously which should give an idea of the scale of the conference. There was also a very large exhibition space on a lower floor containing more than the usual number of corporate sponsors including some very big names (AWS, Google Cloud, Oracle were all there).

The Youtube Channel

Devoxx has its own Youtube channel and it is very good at posting the very professional looking videos to it soon after the talks are done. In the case of Devoxx Belgium it excelled itself. Many of the theatres were live streamed, including my Agile is a Dirty Word.

The Talks

As usual at Devoxx, the quality of the speakers is good. I've now spoken at a few Devoxx conferences this year so I am seeing some of the same people delivering the same, or similar, talks to those they have delivered at other Devoxx events. I think I am in danger of fitting into this repeat offender space! I also had very limited time at the conference itself. The first day I was there I spent most of my time finding the venue (I couldn't find a taxi and had to walk for an hour to get there), then talking to the organisers, then doing my final preparation for my two talks for Thursday.

On Thursday I saw two great talks. I saw other talks which were also good and I didn't see anything that I thought was poor in any way. It is well worth trawling through the Devoxx channel to see some of these talks.

Rethinking Software Systems: A friendly introduction to Behavioral Programming by Michael Bar Sinai

This was something completely different from what I expected. I didn't really read the title properly and I didn't read the blurb. I really went along to it because all the other talks were somehow JVM specific (Devoxx was originally a Java specific conference) or were being given by sponsors. I tend to think twice before attending a talk from a sponsor, I like new information, not a sales pitch. I have been to some excellent vendor / sponsor talks in the past, notably from Google about Kubernetes, but the good ones are rare in my experience.

This introduction to behavioural programming was extremely informative and had a great demo of a virtual robot. I tried to imagine as I was watching the demo how I could have written the same program using techniques that I'm most familiar with. Which probably means some kind of C#, OOP based, implementation. Whichever way I thought about it, I couldn't imagine a more succinct, elegant version than that which was demonstrated. As ever with succinct code I do wonder how easy it would be to read by others without the (excellent) explanation of what was going on. My doubts in this area, of course, could just be down to my total lack of familiarity with this type of programming.

Overall a brilliant talk, very well delivered, and I definitely learned something new.

Untangling the mysteries of qubits by Roy van Rijn

I will always attend a talk about quantum computing at any conference. I was inspired to start learning about quantum in the first place by watching a talk by Alasdair Collinson at Devoxx Vienna back in the spring. I have since then attempted my own version of "Quantum for Beginners" at a couple of conferences. It went OK at Devoxx Poland and a couple of small UK conferences but not so well at DevConf Poland in Krakow in September (too basic apparently). I am talking about quantum again next week in the Ukraine.

The room was packed for Roy and I had to climb all the way to the back, and over a few people in the back row, to get to an empty seat. There were people sitting and standing in the aisles as well.

This talk by Roy van Rijn started with the basics, had an interesting way of explaining the Bloch sphere and went as far as describing Shor's algorithm with an explanation of how the Quantum Fourier Transform works. I felt that there was just enough information for the beginner to get a feel for how quantum computers can be powerful and I applaud that Roy talked in some detail about Shor's algorithm.

Roy's delivery was excellent. The quality of his slides was great and the information passed over was very good (although I am no longer a beginner in this space so I'm not sure how it landed with the real novices). I gave it 5 stars in the app. I would have loved to have talked to Roy afterwards but unfortunately I was on next, I wanted to get some fresh air before my talk and there was a gaggle of people surrounding him. I guess that last point, together with the attendance, give a good indication of how well it was received.

My Talks

The CFP, to which I applied back in the summer, allowed the submission of up to 5 talks. I proposed 3 talks that I have previously presented a couple of times each this year, including at Devoxx events. So maybe I shouldn't have been surprised that they accepted the two talks that were new. I didn't realise it was a thing to get more than one talk accepted at the same conference but I put that down to one of them being a lightning talk, so I was only doing one full length talk.

What Drives Your Development?

This was my lightning talk and is a talk based on my blog post from back in May called * Driven Development. This was intended to be quite light hearted, as the original blog post had been, but with a serious message at the end. As far as preparing for this one went, it was pretty easy to do. I had the blog post to work off and it was a case of just working out the timings to get it all done in 15 minutes. 

The Message

I have got increasingly frustrated in my later years with the amount of time and effort that people think it is necessary to put into prioritisation and estimation. I'm still not convinced that the ability to accurately predict how long stuff will take is all that useful. This is derived from my twin observations that deadlines are generally set artificially and imposed on the people that actually do the work and when these deadlines are (usually) missed, nothing particularly bad happens. So how would the situation be drastically worse if instead of all the pseudo science and wrangling we just trusted a product owner to call out, at the necessary point, what the most important thing is to do next and then do that?

So when I analysed the A to Z we had made back in May, I decided to split them all up according to a few binary metrics. I used real things v made up stuff, good ideas v bad ideas and stuff that tells us how to build things v stuff that tells us what to build. Lo and behold, these three things were strongly correlated. That is to say, real things, good ideas, and ways of building stuff overlapped massively as did made up things, bad ideas and methods of deciding what to build.

The Talk

The theatre I had for this talk was one of the smaller ones and it wasn't very full. Devoxx does its lightning talks during the lunch break and there was a bit of a trek from the lunch distribution to the theatres. So I'm not surprised that not many bothered! I had a reasonable turn out though under the circumstances. I took this selfie toward the end of the talk while I was still talking.

It seemed to go pretty well. I got the timing of the 15 minutes pretty much spot on and they laughed at most of the bits that were supposed to be funny. I should probably stop making the Martin Fowler (Eastenders) joke outside of the UK however. I averaged 4.47 out of 5 stars with 17 voters for this talk. So I was pretty happy with that feedback. A frankly baffling comment, "Not enough demos / samples" from one reviewer made me (and Alasdair Collinson) laugh given that there was absolutely nothing to suggest that would be forthcoming (or even possible) in a light hearted 15 minute summary of a full A to Z. Oh well, no pleasing some people! :)

Agile is a Dirty Word

Where "What Drives Your Development" was a good fun evening at home playing with pictures and stuff, "Agile is a Dirty Word" was a whole different beast. I got the idea for the title through noticing how much skepticism there is about Agile. There is, however, in my experience, a strong correlation between skepticism for Agile and organisations who aren't generally doing a great job of things. 

All of the things that work against organisational agility (and there are many) work against technology teams, or any kind of teams, implementing any kind of Agile process effectively or getting anything out of that process. Inevitably under those circumstances, Agile projects or Agile initiatives fail. But it isn't Agile that is failing, it is the organisation that is failing. However, "doing Agile" was the thing that that changed in the last few years, so Agile doesn't work, right? Agile is toxified in the eyes of many at these organisations. Hence, Agile is a Dirty Word.

Constructing the Talk

So I set about making a presentation for this talk. I had no problem pulling together slides to illustrate the title of the talk. I had material from all of my engagements for ThoughtWorks as well as my first ever conference talk, Agile in a StraightJacket, to give inspiration. The trouble with all of this material is that all it gave me was a massive rant about how bad things are. No solutions. As my colleague Mark Coster taught me a while ago, "Birnie, if all you do is point out the problem and don't offer any solutions, then you are part of the problem." So if I start with "Agile is a Dirty Word" then I have to give some kind of story and some kind of solution about cleaning it up.

Some Prior Help

On one of my previous engagements, I gave a talk (thanks Taheera Atchia) called "Kanban, Flow Control and the Theory of Constraints". The intention was to teach Agile values and principles to a group of people who already thought they were "doing Agile" (they weren't).

More recently I gave an updated version of that talk, "TPS, Value Stream Mapping and the Theory of Constraints" to a company who thought they were "doing Agile" and where "Kanban doesn't work".

In both cases my goal was to teach Agile values and principles without using the word "Agile".

Preparing the Talk

So these two experiences gave me the beginnings of my message. In both cases I avoided the dirty word. So I had the first two sections of my talk and a load of other slides illustrating how we managed to get various clients to a better place.

So a couple of weeks before the talk, I shared all my material with my colleague, Julian Holmes, who definitely knows a bit about Agile transformations. As well as some invaluable feedback about some of the material he suggested a flow for the presentation which helped me to arrive at some sensible section headings that gave the whole thing a coherent story. Without Julian's help I have no doubt the talk would have been far less successful.

The Talk

I was in the largest of the 8 theatres. The conference app allowed people to Like talks before they saw them. I had over 500 Likes in the early afternoon (I was due on at 4:30PM) and the next most for talks on at the same time was around 160. It was suggested to me that my talk may have been moved to the largest room because the conference organisers apparently were changing the location of talks based on Likes. I'm not sure if this is true or not, I didn't get the chance to check.

Whatever the reason, the theatre was HUGE and it was full. I was pretty nervous.

It seemed to be going pretty well when I was doing it. The audience laughed at the bits that were intended to be funny and I saw a lot of nodding of heads at the bits where I was describing the things that are the signs of Agile being a dirty word. The applause at the end was warm.

The Feedback

When I finished there was a crowd of 20 or so people wanting to talk to me and I was happy to talk to them and would really have liked to continue the conversations for much longer but unfortunately had to rush to Antwerp Central Station to get a train back to Brussels to get a train to London. When I was on the train to Brussels I managed to log on to the Devoxx app to look at the audience feedback. I was amazed by the score (4.57 out of 5, 209 votes) and by some of the comments. 

As with most feedback, I'd really love to get feedback from the two people who only gave me 2 stars. There was one negative looking comment lower down the list which was "bit much text on the slides". I think that's fair. As ever, with a bit more time and on another showing, I hope it will be better next time. I really hope there is a next time for this one, I'm waiting to hear from a couple of conferences and I've updated those applications with a link to this talk (and shared the feedback!)

And that was Devoxx Belgium! A great conference, I'd love to be lucky enough to come again.

Agile Dictionary

I've seen a couple of talks recently where people have given some interesting alternative definitions of various Agile / Scrum concepts, roles, foibles etc. One that springs to mind is Scrumdamentalist which my colleague Julian Holmes mentioned in his excellent talk Agile Methods are Dangerous. I also saw a great lightning talk in our regular Friday lunchtime slot at ThoughtWorks from Tarang Baxi, entitled The Agile Contradictionary. All of this inspired me to throw in my tuppence worth of some Agile (anti) definitions. My intention is to add more as they come along...

Scope Creep

A person who sweet talks the development team into constantly adding new things into their backlog because the original MVP that was carefully specified after consultations and an inception isn't cool enough, doesn't include their pet feature or simply because they can. Because it makes them feel important and valuable probably.

Product Moaner

A person who has the job title of "product owner" and whose job involves shouting at the development team, constantly changing their priorities and generally moaning about that they never get what they ask for. Not surprising when you change your mind about what you want so often that you can't remember what it was that you asked for.

Backlog Groaning

A common ritual amongst teams who are "doing Agile". Every two weeks the the team gets together in a room. None of them knows the purpose of this meeting or the outcome that it is meant to drive because nobody has bothered telling them. They certainly have no understanding of how this meeting is intended to make their life easier. Surprisingly, therefore, nobody in the room is interested in the meeting and spends the whole time moaning things like "why are we doing this? Why can't I use this time to do some real work?"

Handover (the wall)

When the development work on a story is done and there is no QA person in the development team (the definition of cross functional not yet having stretched beyond "UI developer", "Back end developer" and "Scrum master") to hand the story over to. Of course, it is well known in these circles that QA is best carried out by a person who is far removed from the developers that created the code. This is to make sure that the developer can't help the tester to do the testing and the tester can't let slip to the developer beforehand exactly how they might do the testing. So the handover involves moving the story on a Jira board into "ready for QA", waiting for a tester to pick it up, having a 3 days long conversation via Slack, emails and comments in Jira to clarify the context then having several more conversations over a 4 day period, most of which end with the phrase "well it works on my machine".

Irritation Manager

In the days of (widespread and openly admitted) Waterfall deliveries, there were project managers and program managers. Lots of them. Sometimes they occupied a hierarchy so deep that there existed project managers who managed nothing but project managers. When Agile came along and Scrum became a thing many of these PMs realised that their Prince 2 certification wouldn't even get them a job managing managers anymore so they got Scrum certified and reapplied for a job as a Scrum Master. Eventually many people realised that there was no common understanding of what scrum masters do and no solid evidence that they add value to any project or product. So somebody invented the job title of iteration manager. Somebody who exists to solve all the irritating things that nobody sees as their job. And to moan about the burn up not being done. And generally ask people to do irritating stuff that nobody wants to do. But at least by irritating people over those things they might get done. Which is interesting because nobody cares about or reads those irritating reports.

Tech Debt Causes, Cycles and Workshop

The Tech Debt Cycle

With grateful thanks to my colleague, Vanessa Formicola, who paired with me to design this workshop and shared the facilitation.

Our current client has a lot of tech debt. And by a lot of tech debt, I mean a LOT of tech debt. 

This is a picture I knocked up for a client showcase to try to illustrate the cycle that they are perpetuating by not listening to devs and tech leads who are constantly asking to be allowed to pay down tech debt and constantly not being allowed to do it by their product people. The story of why we made this slide, and a technique that we are likely to use again, is the remainder of this post.

Technical Debt Workshop

One of the delivery teams that we work with told us that they needed to do refactor a large part of the codebase to make future development easier. So they had a debt item on their backlog "refactor this thing" which was unplayable because that part of the codebase had no tests to either assure them that it was working (before or after any refactor) or to tell them what it should do. After a discussion we agreed that there was another debt item "add tests to this thing so that we know what it does and we know that it works" that had to be played first. Thus, they were able to find a path to unlock what they wanted to unlock.

After that discussion we felt that we needed to review what people were regarding as debt, how they had it recorded, what kind of granularity was in play, whether they had a plan on how to fix things and whether they had a clear idea of what was important or valuable to fix.

We were also extremely suspicious that the product group do not understand why they should care about technical debt. We were further suspicious that the process of allocating a certain amount of time in each sprint for technical debt was being subverted unknown to the CTO and the head of product, both of whom were under the impression that this was a reasonable solution to paying down the technical debt that was in flight and working. So we wanted to illustrate why and how technical debt hurts and therefore why we should care about repaying it and not making more.

So our goals for the tech debt workshop were fourfold:

1. Gain a common understanding of what technical debt means
2. Try to reason out why technical debt is created and how to prevent more technical debt being created in future
3. Raise awareness around what ill effects technical debt causes
4. Start to capture technical debt in a sensible fashion and create a sensible process to manage it
5. Gain alignment between developers and product managers over the importance of tech debt

The Workshop Design

We had a 2 hour session set aside for the workshop. We had a good cross section of developers in the room (a similar exercise to follow with product owners / BAs later) from junior devs up to a lead architect.

Gaining a Common Understanding

We first wanted people to think about what technical debt means to them. So we started by distributing index cards and sharpies, some of the usual tools of the ThougtWorks trade, and asked them to write down, in one or two sentences, what they think technical debt means. Pleasingly, the answers were very similar. We then discussed briefly some formal definitions of technical debt and some places (Wikipedia, Martin Fowler, Ward Cunningham etc) where further detail and ideas could be found. This part took around 10 minutes.

How Does Technical Debt get Created?

We handed out some stickies and asked the group to consider things that they, during their day to day job as developers, might do (or not do) that may lead to the creation of some new tech debt. When we framed the question we were expecting to get things like "I don't write an integration test", "I choose cut and paste re-use over generalisation" or any number of short sighted short cutting things that developers may do. We did get this type of thing in the output but we also got something else.

Why Does Tech Debt get Created?

Whether they were misunderstanding the question as we framed it, whether they were extending the scope of "you" in the "things you might do" part of the question, from just developers to everybody or whether they were simply trying to justify why they themselves, individually and collectively, had been guilty of creating new technical debt probably quite frequently, the fact was that we also got responses citing reasons why they might cut corners. We started to see some stickies citing pressure being placed on them by product, lack of resources and unrealistic deadlines. We pulled some of these out and called them "precursors" and it sparked an interesting discussion on the relationship between the product people and the developer group. This discussion surfaced a disturbing disconnect between developers and product within each scrum team. This is something that we need to look at later.

What are the Downstream Effects of Technical Debt?

We wanted the developers to think about what problems they could be causing for themselves, other developers, QAs, anybody else within the company OR end users by allowing more technical debt to be created. Our goal was to get them to think more responsibly about it. Given the revelations about the relationship with product it began to feel like we were preaching to the converted. We were already thinking at this stage that this exercise needs to be repeated with a different group.

Is There a Cycle Going on?

As we added more and more pink stickies denoting downstream ill effects we started to talk about some cause and effect relationships. We started by placing pink effects under, or near, blue causes but it was apparent that there were multiple parents and children in many cases so we started to draw arrows on the board to denote more relationships. This was an unexpected and highly valuable diversion because ultimately, amid much discussion, we realised that we were looking at a vicious cycle. In was inescapable that there was a feedback loop going on with just the awareness of debt of a small subset of the developers. This started to feel like a message we could take to the stake holders.

Managing the Technical Debt

We took a scheduled break after the pink and blue stickies. This was always the plan and my colleague, Vanessa, facilitated the next part of the workshop. The idea with the next part was to surface, understand and perhaps start to prioritise, actual debt items that could be worked on. We gave some time to them to write examples of tech debt that they know exists and that they would like the opportunity to fix. This was a lively session as well. Discussions went on about how big we were talking about (as big or as small as you like, just something you'd like to fix!), whether it was restricted to stuff they'd done or stuff that had been around forever (everything you know of please!) We coined a phrase "founders' debt" referring to the tech debt that was knowingly incurred in the early days of the company when the startup mentality meant that they didn't feel like they should care about such things. On a side note, I wish it were possible to identify the exact point where it becomes hugely important to start caring! I guess if ThoughtWorks is there helping, you've probably missed that moment.

Groupings

It turned out that the debt items that got surfaced fell into 3 fairly obvious categories. Stuff to do with writing missing tests, stuff to do with large refactorings (which probably would need some missing test debt paid down as a prerequisite) and stuff to do with suggested changes to architecture.

Recording Debt

So the logical outputs from this workshop are the items of debt that need to be tackled. I have already written about a tech debt quadrant a couple of months ago (that was an earlier conversation at this same client). As far as we can see, there isn't a better way to do this. This gives us a low friction, low-fi way of recording and publicising the debt.

Culture of Adding Debt

We talked about a process whereby developers and product people discuss whether stories should go into the release process without, say, full test coverage. This is all too regular an occurrence in an environment with large piles of existing tech debt. What we managed to get to was an accord that "it would be a good idea to" have discussions about proceeding at risk, immediately capturing the debt items thus created and adding them to the debt wall. A long term aspiration would be to get to a culture where adding debt items in this way becomes some kind of shameful act to be avoided. We are very far from that place at the moment.

Conclusions

Discuss Things at My Level

There is still loads of confusion around technical debt. What it is, why it is important, why it should matter TO ME. It really helps with this, and most things, to get people to discuss how it will affect them. The compound interest representation of tech debt effects is useful on a high level to explain to managers why the concept should be respected but it really isn't helpful to persuade people who feel daily pain on a number of fronts. They are the ones that need to be persuaded to buy into a process, however lightweight, of doing stuff that isn't obviously directly related to their day to day work.

Make Things Visible

A lot of the conversations I had before I came to this client related to visibility of stuff. When we got here there were very few things on boards. We have changed that. We have noticed that this automatically triggers discussions and it automatically makes people talk about solutions and causes. It is a great way to get people together for a common goal. It is a great way to share success. This applies to technical debt and, frankly, any work you are doing. I can't recommend this enough. One of the constraints our client put in front of us was that the lease on this building forbids them from sticking stuff on the windows. Only internal walls can be used. We told them to buy whiteboards on wheels, at least one per team.

Alignment is always Key

Get buy in from individuals, get alignment on goals, high level and lower level. Things will only change when this happens first.

* Driven Development Reprise

Thanks to the following colleagues (and in some case ex-colleagues) from ThoughtWorks for their contributions:

Giamir Buoncristiani, Rufus Raghunath, Joey Guerra, Jonny Leroy, Jean Robert D'Amore, Job Rwebembera, Andy Marks, Tobias Saltzmann, Srinivas Murty, Javier Sánchez Rois, Raimund Klein, Jim Gumbley, James Barritt, Emma Grasmeder, Gurpreet Luthra, Sowmya Krishnan, Pranathi Birudugadda, Gabriel Machado, Yasser Rachid, Kornelis Sietsma, Srikanth Venugopalan, Luciano Ramalho.

The Original Post

Back in May of this year, I posted about * Driven Development. That post started with a light hearted conversation over coffee with one of my colleagues and ended with 7 of us slaving through the alphabet to get it all finished before I would let the team sit down and order dinner. I didn't do any editing or refinement except during the discussion and I published the post that evening, without waiting for the cold (and sober) light of day.

The Post Post Discussion

As the seven of us really thoroughly enjoyed making the post and as because I wanted to publicise my blog internally to ThoughtWorks, I immediately shared the post to an internal ThoughtWorks list. This had two main effects. Firstly, it drove loads of traffic to my blog, loads more than I'd ever seen before, which was nice. Secondly, it prompted loads of our colleagues, ThoughtWorkers never being short of opinions, to propose other additions to the A to Z that I had constructed.

The Post Post Post Discussion Talk Proposal

I talk at quite a lot of conferences. At least I have talked at a few since summer 2017 - hopefully they will keep inviting me :) Most conferences allow you to submit a few different talks for consideration. I usually submit a couple of talks that I've done at previous conferences together with a couple of new ideas. If the rules allow it, i.e. if the maximum number of submissions is high enough, I like to propose something a bit more out of left field. Sometimes these left field submissions get accepted. This was how my Architectology talk was accepted originally (although it since morphed, I think, into a very serious message).

Unfulfilled Desire to Perform

I suspect that my enjoyment of presentations satisfies my unfulfilled (through lack of any real talent and material) desire to be a stand up comedian. I like to try to make the odd joke when I talk on stage (not always successfully) and I thought that the blog post, if presented as a lightning talk could play a bit like a stand up gig. The only problem was that I felt that in order for it to be accepted it would need to have a serious message. A straightforward recital of a mildly amusing blog post would never get into the conferences and, frankly, would be a rubbish talk.

A Serious Message

When we created the original post we had a single rule for acceptance. The person proposing the entry needed to have experienced the thing at some point in their career. This is fine for all the serious stuff (TDD, BDD etc) but probably less so for some of the amusing or dysfunctional things. So I started to think about what should REALLY drive your development. I can't answer that question fully during the last few minutes of a lightning talk, but my proposals promised to give at least one sensible answer. So I submitted the proposal, with a link to the blog post and a teaser about what SHOULD drive your development. Now I just have to make the slides (and work out the best answer to the question) as I've had the talk accepted at two conferences so far...

The Additional Candidates

I won't be using any of these in the conference talks (as they weren't in the original and a lightning talk has limited time) but here are the extra suggestions from my ThoughtWorks colleagues. The indented text is my annotations, everything not indented is directly quoted.

B

Blog Driven Development - where a developer doesn't know how to solve a problem but finds a really cool looking blog on hackernews that says they need microservices and just follows the steps listed there because it is easier and quicker and has 26 microservices supporting a simple authenticate, validate and map requirement.

Beer Driven Development 

and its corollary

Hangover Driven Development

Interestingly I think that beer driven development involves over enthusiasm for an idea / design - and hangover driven development is a harsher environment for ideas and therefor can produce better work.

I think maybe it needs a disclaimer that not actually promoting the use of alcohol to improve team performance:)

Buzz word Driven Development - Similar to resume driven development.

• Hacker-news driven development 
• Twitter driven development 
• Industry Leader driven development ( where google/fb/netflix release libraries and people just follow)

These bullets came with the above indicating, I think, that they are variants of Buzz word driven development.

Bundle driven development - I remember working for an IBM partner who would sell bundles of things to clients - so, if you bought IBM product X you'd also get the IBM http server, and the IBM directory server, and a bunch of other crap. I remember using IBM MQSeries in a software tool as an in-memory queue - because they'd already paid for it...

I hear someone say Atlassian is similar? Probably unfair to put IBM and Atlassian in the same sentence, but I have cried enough over a Bamboo setup, just because the client wanted to use Confluence.

The Atlassian comment was added by somebody as a response to the original poster who mentioned IBM products.

C

Conference Driven Development - When you look up something you want to learn, you submit a talk proposal about it, you get accepted, you panic first but eventually you learn it and give the talk.

I have done this myself. I was told by a colleague when I first started at ThoughtWorks never to prepare any slides until a talk gets accepted for a conference. I took it further by not really doing any research about Quantum Computing until the talk got accepted (although I did cheat a bit because the subject really interested me) and when it did get accepted I properly panicked! Hopefully when I give this talk again it will be much improved.

Case Study / Press Release Driven Development - Focusing on what an ideal success story would look like for your endeavor and working backwards from there. Good to keep this focus throughout the project, not just during a one-hour session during inception ;-)

This one is closely related to README Driven Development

Console Driven Development (Mainly in JS) - When instead of writing readable tests that will clearly show the output of your code against expected values...you put console logs everywhere, nail the bug and commit the code with the logs.

Commit Driven Development - Under the right circumstances, I find it helpful to prevent scope creep and yak shaving, which I'm susceptible sometimes.

I had never heard of this before the discussion. When I reread the discussion thread to make this post, I had forgotten what it meant. I looked it up here. I like the idea and I think I might try to do it the next time I'm writing code.

D

DEFECT DRIVEN DEVELOPMENT

This was posted like this, no elaboration, block capitals, exactly as I've reproduced here, by a ThoughtWorks QA. I'm not sure if he was trying to tell me something.

Delete the Tests Driven Development - first you write the failing test, refactor, realize the refactoring didn't work, delete the test, deliver the feature.

I sincerely hope that none of my colleagues have been involved in this type of development!

Data Driven Development

There was no elaboration on this one and nobody followed up. I think it is like the (good) version of Metrics Driven Development where you release a small change, check to see whether you moved some needle in some direction and then take a decision as to whethe the change was "good", "bad" or "needs more data". 

G

Golf Driven Development - In reference to how OTC packages procurement decisions are made.

This was proposed without any elaboration but when an elaboration was asked for we discovered that this is a reference to the corporate habit, which I believe is still a thing, of inviting business acquaintances out for a round of golf (and presumably wining and dining them afterwards) to discuss products and services.

H

Hotfix Driven Development - Where projects just wait for failures in production, fix them, push them and call it done never to touch and refactor that demon again ;) 

M

Metrics Driven Development - For example, I’ve seen a (non-TW) project been run in the past where the head of support had dictated that each developer had to fix 4 defects a week on the project. 

Meeting driven development - Where a big meeting is needed to drive every decision.

P

Pain Driven Development - When you focus on incrementally reducing the pain that a group of customers / users are feeling. A good example is gradually reducing the most painful areas of customer support in a call center, or the highest volume of support requests a group are receiving. It's really a prioritization technique, but can be a good way to structure moving from a fully manual to a sensibly automated solution.

Press Release Driven Development - See Case Study Driven Development.

Production Issues driven development - Similar to Defect Driven Development, but more focussed towards Urgent bugs -- since there isn't any other option. Likely same as Failure driven development.

R

Resume Driven Development - When every technical decision is based on whether or not it’ll look good on your resume.

This was suggested by one of our North American colleagues. I had to refer him to the "C" section of the original post.

REPL-driven development - A perfectly valid choice when your language and it's toolset support it.

Responsibility-Driven Design - On a more serious note, I think the first time the *DD acronym was ever used was by Rebecca Wirfs-Brock (Responsibility-Driven Design).

README Driven Development. -This is a thing.

T

Type / Type First Driven Development - This is a thing.

U

You need a few more first letter options:

https://medium.com/square-corner-blog/new-class-naming-rules-in-ruby-bb3b45150c37

Maybe "Ųnicode Driven Development" - where you need to somehow make changes to prove that ascii isn't sufficient for your problem?

I've reproduced this as it was written originally. When I followed the link I made the (perhaps bold) assumption that the two were related.

V

Voucher Driven Development - Build the entire infrastructure of your hundreds of pet projects using vouchers, student packs and free usage quotas given by the cloud computing providers.

Another Technical Debt Quandrant and Debt Days

Martin Fowler's Technical Debt Quandrant

Ages ago I blogged about The Technical Debt Quadrant as explained by Martin Fowler in his blog from some years earlier. When I re-read that article (Martin's, not mine) it looks a lot like a discussion that was of its time. The reason why I raise this again is because recently I came across a completely different kind of debt quadrant, not for helping us understand how it came to be but for helping us to understand when to pay it back. In the course of some discussions with my current client I combined it with a thing that I learned from my previous client to come up with a plan to address technical debt.

Bug Squash

At my last client I was tech lead of a team that was mainly responsible for fixing production defects in the platform that we were implementing. Leaving aside whether this is an anti-pattern (it is) we were managing a large backlog of defects whilst simultaneously adding "BAU" enhancements to the platform itself. One of the side effects of this dual focus was that annoying little defects rarely got fixed. A knock on effect of that was that our backlog was growing, we were spending money managing it but we didn't really know if the backlog was real or not.

A Bug Bash is an exercise to be done occasionally, the object of which is to find previously undiscovered, or unrecorded, issues and get them on somebody's backlog. This could be semi regular, just before a major release or upgrade or just a fun afternoon. In my experience of these occasions, anybody can take part, there is probably some kind of refreshments offered and there may be some kind of gamification and prizes on offer.

Somebody in the team proposed something that came to be known as "Bug Squash". It wasn't me, for sure, but I remember thinking it was a great idea and that we should try it. The idea is kind of the opposite of a Bug Bash. We decided that every Wednesday afternoon we would all drop everything that we were working on and we'd look at the backlog from the least important stuff upwards (instead of the usual top down way of picking stuff to fix) and we would either fix the issue straight into the code base or we would record in the ticket why it was no longer an issue and close the ticket. We left it up to everybody to decide exactly how they wanted to work. If they wanted to pair fine, if they didn't that was also fine. This had some great benefits. First, it was fun. Second, our backlog got smaller so we could all share in the success of that, third it spread context of the whole codebase amongst more people.

Another Tech Debt Quandrant

My current client thinks it has a lot of tech debt and this is one of the reasons why myself and a colleague are here for about 3 months to try and advise on some thing they can do to help themselves. As you might expect, tech debt is a symptom of some wider problems with the organisation. Unlike many symptoms though, it is always worth treating tech debt because it has a nasty habit of multiplying and making your future life more difficult.

One of the big problems is that the tech debt makes it hard to do stuff. So they know they need to be paying this debt down but they find it hard to find the time to pay it down. And one thing that makes it hard to find time to pay down tech debt is tech debt. I think everybody can see where that one ends. We've tried a few different things to help with the situation. Currently each team is asked to assign 20% (it might be 10%) of their capacity in their sprint plan to debt items. The trouble is that these are the very items that feel the axe if the teams realise that they won't make their sprint commitment. Moreover, somebody spent some time analysing the debt, creating a card, putting on the board, bringing it into the sprint cycle etc etc. So the management of the problem becomes part of the problem itself (see my earlier post on inventory management).

So in advising on a way to get to the outcome (reduced technical debt) what we needed was a method that was easy to manage and track that encouraged people to pay down the debt. The first stage was a debt quadrant (an idea that was introduced to me by a ThoughtWorks colleague last year). Instead of just having a debt wall onto which everybody pins things they'd like to fix, you split your debt wall into 4 quadrants, as per the picture below.

For those that can't read my handwriting (probably everybody) the vertical axis is labelled "Ease of Solution" and the horizontal axis is labelled "Impact". So I hope it is therefore obvious that stuff in the top right (high impact, easy to fix) should be fixed as soon as possible. The stuff in the top left should be looked at and maybe fixed, the stuff in the bottom right should be looked at, analysed and prioritised into the normal process (whatever that is). Hopefully then, this simple visualisation gives each team a good way to record, manage and pay down their tech debt.

Debt Days

But what if people still don't feel like they have the time to do any of this? Our simple suggestion was that one afternoon a week (that would be about 10% so one whole day or two half days would be 20%) the team should drop everything they are doing on the sprint. Instead, they should pick up one of the cards in the top right of the debt quadrant and do something about it. No time used on planning or estimation or arguing what is the most important thing. Just pay back some tech debt.

It is early days yet but by combining the ideas of a simple quadrant and setting aside REAL time to do something (not time in a sprint plan that might not happen) we will hopefully get some significant payback of our debt pile whilst having some fun along the way.