Monday, 15 October 2018

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.

Thursday, 6 September 2018

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.

Thursday, 30 August 2018

* 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:


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.



Monday, 16 July 2018

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.

Saturday, 2 June 2018

Architectology Update

Some time ago I wrote a post on this site about architectology. I have had a lot of time to think further about the subject since my original post, which I have just read again. I didn't really have a conclusion or a solution in that original post. It seems that I was saying that the notion of a person who spends their time navigating legacy code feels wrong but I had no better way of dealing with the silos and extracting value from them.

From talking to a lot of software professionals over the past year I have discovered that many large businesses (and public sector bodies) have their own word for architectologists, it seems that many of them widely refer to such people as "enterprise architects".

I've recently completed a 10 month engagement with a public sector client and although they didn't call them enterprise architects they had plenty of architectologists. I now believe I have seen enough to propose that architectology is an anti pattern. According to Wikipedia, an anti patter is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. To distinguish a genuine anti-pattern from a simple bad habit, the following 2 conditions must be met:

1. 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.

2. Another solution exists that is documented, repeatable, and proven to be effective.

Firstly, is architectology a common response to a recurring problem? I would argue that it is. The problem is how to extract value from silos of legacy systems. The response is to task some people (architectologists) with drawing pictures of the legacy with lots of arrows on it to show a software team how they might get stuff done.

Secondly, does it have more bad consequences than good ones? I think so. Among other things it prolongs the lifetime of the legacy, couples it more strongly to more processes and makes it successively harder to add new value to the enterprise.

Finally, what is the better solution? Last summer we had a good deal of success in the client we were working at in persuading them to create cross functional teams that own the entirety of a customer facing outcome. Having made that step, the logical next step was to repurpose their architectologists (IIRC they were called enterprise architects) as architects working more closely with software teams delivering those outcomes. As the teams that previously owned the legacy pieces were broken up, nobody was left illogically defending the existence of various pieces and the client was able to start sensibly decoupling the systems and strangling parts out of existence.

So it is therefore my conclusion that architecology (or enterprise architects if you prefer) fulfils the criteria to be regarded as an anti-pattern.

I recently gave a short talk postulating that architectology is an anti pattern at Devoxx UK in London.

Thursday, 3 May 2018

* Driven Development

With thanks to my colleagues - Andrew Jones Weiss, Velizar Genov, Gergo Takacs, EnterTheDragos, Robert Chow, Stuart Paton.

I had a conversation with a friend a couple of days ago about what work his team was doing. They were supposed to have done some work "in time for UAT" but they missed getting a couple of stories into the locked down UAT environment before the deadline. Thus, UAT wasn't going to cover those use cases. The next UAT wasn't due to happen for a couple of months so they changed their focus on to some different stuff.

I laughed at this and commented that this sounded like Politics Driven Development. I had never heard the term before but given the nature of the organisation my friend works in, I thought it was an apposite term for what they sometimes end up doing. That got us into discussions of what other *DDs exist.

We then set ourselves the challenge of coming up with a whole alphabet of *DDs. Some of them are serious, some of them are not, some of them we made up to get through the alphabet. Our criteria was that for something to stand it either has to be a real thing or the person suggesting it had to have experienced it at some point in their career.

Any more suggestions welcome!

A

AWS Driven Development - This is when your company migrates from the old server farm to AWS and all future development is constrained by the tools and services that AWS offers.

B

Behaviour Driven Development - this is a thing.

Bullshit Driven Development - when an influential developer blags that they understand a technology and the team goes too far down the road of relying on that technology before they realise that (a) that developer was lying and (b) the tool is not appropriate for the job. Extra points if the developer that influenced the decision leaves the company shortly after the decision was taken. Kafka is a repeat offender in this space.

Bleeding Edge Driven Development - this is when you must on NO ACCOUNT use any technology found closer to the middle of the ThoughtWorks Tech Radar than the Assess ring. If there has been a conference with this as its main subject you may still use it but only if that conference was an UnConference.

C

Career Driven Development - when a decision to use a language or technology is not driven by what is best for the problem at hand but by what the developer or developers want to learn to enhance their career within an organisation.

CV Driven Development - like Career Driven Development except the motivation is to enhance your CV with the intention of moving to a different job.

D

Domain Driven Development - this is a thing.

Developer Driven Development - This is when developers as a group decide that they want to do something interesting. So they decide that instead of using boring old Java for their Microservices that they are going to use shiny new and interesting Clojure. This could also morph into one or other of the types of CDD.

E

Ego Driven Development - It’s what Rockstar developers do.

F

Failure Driven Development - Your system has so many defects with new defects being constantly reported that you never have the bandwidth within your team to play any stories that add new value. You are sentenced to be forever jumping to the tune of the person in the business who is screaming the loudest to have their defect fixed.

Fowler Driven Development - When Martin Fowler posts a new blog post that could impact your work in progress you then make it your business to ensure that it WILL affect your work in progress. Extra points are awarded if you contact a friend you have within ThoughtWorks to ask for a clarification on the nuance of what Martin was referring to before you modify your stories.

G

Google Driven Development - Like AWS Driven Development except you use Kubernetes and the Google Cloud tools.

H

Hypothesis Driven Development - This is a thing.

HiPPO Driven Development - This is based on the HiPPO decision making process that many organisations rigidly stick to. To implement HiPPO decision making you gather a large group of people in a room to discuss the decision. The larger the better. You then discuss the thing for a long time listening to everybody's opinions, including those that will live the consequences of the decision. Then, the Highest Paid Person's Opinion (HiPPO) is aired and that is the decision taken. HDD is when the priority of features is decided purely on the seniority of the person that requested it. Actual business value is irrelevant and pointless to argue about. If the CEO requested it, it's the first thing you do.

Hype Driven Development - This is strategic decisions based on what the current "big thing" is (see also ThoughtWorks Driven Development). So if the buzz in the industry is Microservices, then the CTO will be demanding that we "should be doing Microservices" irrespective of cost of value.

I

IntelliJ Driven Development - when you join a new codebase the IDE tells you all the bad things about the code. AKA Alt + Enter Driven Development.

J

JetBrains Driven Development (see IntelliJ Driven Development)

K

KISS Driven Development - Let’s keep this one simple.

Kangaroo Driven Development - I’m struggling here, you may have noticed. This is when you have a weak or no product owner who has a bad time articulating upwards what is important and what isn’t. You therefore end up jumping from one priority to another never quite knowing from one week to the next what your purpose as a team really is.

L

Lifestyle Driven Development - As a tech lead I always think there are two kinds of decisions. Those that I care about and those that I really don’t. Some people get really exercised about the second type of decision. I’ve seen conversations over whether we should use a 2 or 3 space indent in our C# code rumble on for 3 months. Seriously. And it involved edit wars in FXCop lint rules. Any such decision, that really doesn’t matter in my view, is a lifestyle choice. Lifestyle Driven Development is when this type of Bikeshedding dominates team stand ups, team planning meetings and all team conversations. Even in the pub.

M

Marketing Driven Development - when a marketing campaign proves that a market exists for a new product that you haven't built yet, forcing you to build it.

MoSCoW Driven Development - this is a thing.

N

Negativity Driven Development - This is when your developers are so negative about the prospects of the code not falling apart that you write dozens of tests that test the edges of the edge cases that can only ever be hit when all 8 planets (and Pluto) align in such a way that frogs fall from the sky and turn into baby poodles before they hit the ground. This causes such immense scope creep that your project funding expires playing the first story and nothing ever goes live.

O

Optimism Driven Development - This is when you design for the happy paths only because obviously those are the only bits of your system that will ever get exercised. This is very true, until your project goes live at which point you have to run for the hills.

P

Politics Driven Development - Many large organisations are riven by internal politics. When you work in such an organisation you know about it. Politics can lead to some pretty illogical decision making around prioritisation of your backlog. Conversations could be something like "We think this is the most important thing but we need to keep this group happy because we need them onside to help with next year's budget approvals".

Patterns Driven Development - When one developer has recently read Design Patterns by the Gang of Four and goes through the codebase insisting that everything be refactored to closely follow some of the patterns in the book. It doesn't matter if it is an appropriate pattern for solving the problem at hand and it doesn't matter if the code being refactored is covered by solid tests that can verify the refactoring. In fact it is better if there are no tests at all so that you really have no idea if the code still behaves as expected. Patterns Driven Development is an Anti-Pattern.

Q

QA Driven Development - This is a thing but every reference I found to it calls it Tester Driven Development but we already had stuff in T.

R

Resharper Driven Development (the Visual Studio version of IntelliJ Driven Development).

Retro Driven Development - This is actually a good thing. This is when you do something for two weeks, discuss how it can be improved then realise that you were doing it wrong so now you do it right. Wash and repeat.

S

Sales Driven Development - This is when your sales team makes a bespoke deal with a new partner assuring them that we have systems in place to support these weird business rules that they just invented on the fly. They then come and talk to the tech team and say things like "we can do this, right?" It obviously doesn't matter if we can or not because we're now committed to hastily implementing the features that we have already sold. This happens a lot in start up companies.

Stack Overflow Driven Development - It’s a thing, no really! It is! This is often characterised by code comments saying “I don’t really know what this does but here’s a link to the Stack Overflow page”.

T

Test Driven Development is a thing that I hope we are all familiar with.

U

Underwear Driven Development - This is when a team works as a distributed team and most people’s default setting is working at home. During stand up everybody is on a video link and you can tell which developers aren’t dressed yet because their video feed will be a black screen with “John’s iPhone” written on it.

V

Value Driven Development is a thing.

W

Waterfall Driven Development - We’ve all been there. Hopefully not recently. Oh dear, does last year count?

Wagile Driven Development - When you are actually doing Waterfall but the project management like to claim you are doing Agile.

X

XD Driven Development - I thought this was a real thing but when I Googled it I couldn’t find it. At a place I worked recently the client had a really strong UX department and their product design was heavily influenced by what the UX people did with user research and workshopping. It seemed to work pretty well, the product was really cool that we built and had good take up from the target market.

Y

YAGNI DD

Z

Zealot Driven Development - When somebody in your team is so vehement in their beliefs that they drive the team forward to complete the work according to their standards. This was, in fact, the method used to construct this blog post. My colleagues are now desperate to order some food having been forced to finalise our definitions before I allowed us to sit down for dinner.











Tuesday, 5 December 2017

Inventory Management


On my first real engagement as a ThoughtWorker, before we started doing any delivery work, my colleague Chris and I were in a meeting with some architects and business stakeholders looking at their backlog. It was large. Very large. Chris started pointing at some items near the top and asking when they might get done. "Soon", "In the next few weeks", "in this or the next sprint" were typical answers.

Next Chris pointed at some stuff just under the fold and asked the same question. "Maybe in the new year" (this was late October), "Depends if anything else comes up", "Probably in the plan for Q1" were typical of the slightly more vague answers we got at this stage.

Then Chris started asking about some stuff that was a few pages of scrolling further on, nearer the bottom of the overall backlog. Now the answers were more like "That may never get done", "Can't see that ever being a priority", "I have no idea what that even means" were the type of answers we got at this stage.

At this point Chris made what I thought at the time was a rather controversial suggestion. He asked if they had considered deleting everything. The whole backlog (he may have suggested reprieving the stuff in progress and a little bit more, I can't remember, but it sounds more dramatic if he proposed torching the whole lot). This was met with howls of protest from our clients. "We need this stuff!", "Everything on this list is business critical!", "We've promised this stuff to the business!". One of us asked how long something had been on the backlog. The tool was able to tell us it was in the order of 2 years. "How has the business managed without this business critical functionality for 2 years?" was a rather ironically posed question at this stage.

I do remember asking Chris afterwards why he was advising them to do this. The answer I got was "it's inventory". Unfortunately, I either didn't have the time or I didn't press to get a fuller explanation of why inventory was a bad thing. I hadn't read much, if anything, about lean manufacturing or the TPS at the time, and I certainly hadn't read the Goal, so I was probably associating inventory in my mind as something that was an asset (stock in hand), not a liability.

I'm not sure how that one ended up. I wasn't close to the further discussions when we started delivering and I left that client a few months later. As I was working on completely new functionality I never had to go near their backlog so I guess I just stopped immediately caring about why we should care so much.

Two years later I saw exactly what I didn't seen then. I was moved to a new project and told that there was a problem. This team that I was being asked to work with was having a problem moving stuff across their board. We are responsible for live system defects and in the months prior to me landing here the number of outstanding defects had risen slightly despite the number of new defects raised to the team being in successive months, 45 then 30 then 20 then 10. Clearly something was wrong with the flow of items across the team's board.

When I arrived I thought it might take me a few weeks to discover what problems existed. In the first week I noticed that several people in the team were spending an extraordinary amount of time looking at the card management system, updating cards with various numbers, extracting data from it and preparing reports for consumption by various people. I don't know when it started but clearly at some point somebody in the business asked this team for information about when stuff might be fixed without considering the consequences of how those answers might get produced.

I went to a meeting with 8 people in it that lasted an hour. In this meeting we reported to these people various things that they could have found out by looking on the card management system (they all had access, I checked). After that meeting I asked a few people in the team how much time they spent on what I was now recognising as inventory management. I was shocked by the answer. Some of the team were spending half their time on this type of inventory management activity!

So what did we do? In the next meeting I suggested to the business stakeholders that they were asking for all of these updates because at some point in the past they lost confidence in our ability to deal with defects in a timely fashion. This was agreed. I then postulated that they wouldn't care about these reports if we were dealing with defects in days or hours instead of weeks or months. Again, they agreed. Then I pointed out, which they probably weren't previously aware of, that we were spending so much time on servicing their reporting "requirements" that it was seriously compromising our ability to do the work that they were asking us to report on. So I asked if they minded trusting us for a little while. Could we drop all the reporting stuff as of now and then talk again in a few weeks when hopefully we'll be able to demonstrate an improvement. All of this was agreed by all of the teams we deal with.

Three weeks later and the signs are good. We've decreased the count of outstanding defects from about 70 to about 45. We have no live category 1 or 2 defects. Morale in the team is considerably improved. Nobody in the business has asked where their reports are. I am hugely simplifying of course. We also put in place a number of other things to help our team. This felt like the biggest thing though.

So for the first time I could see through direct experience why Chris was so keen to remove (or at least reduce) the backlog. The backlog is inventory. Inventory needs inventory management. Inventory management does not return value to the business. So a big backlog is bad.

I guess in conclusion I'd say if you are part of a delivery team and you find that you are spending lots of time managing inventory then ask yourself why. My advice would be not to bother jumping to these reporting "requirements". The data is probably there in your card management system or your wall. Explain to the business how inventory management stops you doing work that returns value to the business and respectfully ask if you can concentrate on valuable work. It certainly helped for us!