Wednesday, 29 May 2019

Team Goal and Values

Why Bother?

I have joined many teams and many organisations in the 4 years I have been at ThoughtWorks and one of the biggest issues I see within teams, and sometimes in the teams they have to interact with, is that there is a lack of alignment in goals across teams that have to interact and sometimes within teams themselves. After my second or third engagement I realised that one of the major problems is that sometimes teams have never actually agreed their team purpose (goal, raison d'etre, mission, call it what you will) or their team values. 

My First Experience of Team Goal and Values

Two and half years ago I was staffed into a brand new team that was formed to answer a specific question in a short space of time, 12 weeks or so. We were tasked to demonstrate to the client that by forming a cross functional team, empowered to deliver on its outcome and not constrained to use the existing systems and frameworks to deliver this outcome (except where certain legacy systems encapsulated complex business logic), we could deliver on business outcomes quickly and therefore reduce the cycle time from around 12 months to a matter days.

As far as the client was concerned, this was a big ask and many within the client were sceptical of our ability to deliver. At the time I was staffed as an experienced member of the team but I wasn't leading the team. During the inception one of the exercises we went through was to agree the team goals and the team values. I wasn't really sure why we were doing this at the time (wasn't the goal obvious?) but I was curious to understand what the outcome would be and how it would pan out in the longer term.

A Goal Statement and Some Values

I can't remember the exact goal statement or values (and it would probably betray a client confidence if I did) but to the best of my recollection we ended up with something like:

Team Goal:

We are the Process Workflows team. We will demonstrate how to return value to the business quickly through using cross functional teams.

Team Values:

We value understanding complex interactions over creating beautiful user interfaces

We value returning business value to the customer quickly over crafting the perfect solution

We value delivering our own outcomes over requesting help from expert silos

How did this help?

As I said, I was a little sceptical at first. When the team started working though, I saw the value. Firstly, the goal statement enabled us to reason about what the most sensible items to put on the back were. We had a vague product imperative from the business but that wasn't the major part of what we were there to do. The goal statement freed us up to deliver working stuff to the business without having to care too much about the long term. Sure, we took on (knowingly) a lot of technical debt but actually we weren't yet building a product. Look at the mission statement of the team, it doesn't mention building a product.

As for the value statements, those three sentences helped us to reason out what the most important story was and helped us to understand how much care, relatively speaking, we should put into each. For example, when we had a story early on that was dragging on a bit to build our deployment pipeline we were able to say, "we have to get this done somehow" because it was key to returning value to the customer quickly. Similarly, when an assumption we had made over the ease of implementing some front end functionality using a particular library proved false, we just dropped the library and made a rubbish looking UI. We could do this because we valued complex interactions (back end stuff) over beautiful interfaces.


Since that project I have only worked as the lead on any given team that I've been involved in. The very first thing I've done on joining a new team has always been to ask the team, "what do you do?", "what is the goal of this team?", "do you understand your team values?" I am yet to come to a team that had a consensus on the team goal and team values had never been discussed in any team I've joined. So within the first few days of joining a new team I've done a workshop to discover the team goal and values and I've made sure they are on display from that point forward. This has always given me a great base to continue forward with the team.

Thursday, 25 April 2019

Tech @ Core - What Does it Really Mean?

The Fourth Industrial Revolution

We've been talking within ThoughtWorks, and to our clients, for a few years now about tech@core. I wanted to understand when we had started talking about tech@core and where it came from. From what I can tell from asking around internally, the phrase is derived from an article written by Sai Mandapaty and Dan McClure some time ago. I say "some time ago" because nobody was able to give me an accurate answer as to when it came about. The only thing I can say for certain is that it must predate 2nd November, 2018 because this Insights article, by Namrita Bhat-Rao and Sneha Prabhu references it.

A graphic I have seen a few times, with slight modifications, to explain what tech@core means can be found in both of the above mentioned articles. Here is the one I found in Namrita and Sneha's article:

It is quite clear to me that a modern business needs to stop regarding its technology organisation as a cost and needs to start regarding it as a value creator. This is part of the tech@core transformation. Equally, having worked in several ThoughtWorks clients who do not yet buy in to this type of thinking, it is clear to me what not being tech@core can mean in terms of internal dysfunction. What isn't clear to me, although I hope it is becoming clearer, is exactly how we can articulate the what and the why of tech@core to our clients to get them to buy in to it.

Dogma and Preaching to the Converted

One problem I have noted a few times in my 4 or or so years at ThoughtWorks is that we can be guilty of being dogmatic. This is a criticism that is sometimes levelled at us by our clients as well and is definitely something I've noticed internally. The problem is that we believe in some things so strongly that we sometimes forget that to other people this could be some kind of new fangled, even crazy, idea. I have met and worked with ThoughtWorkers who struggle to articulate to clients why pairing is a good thing because it is all they have done. To them, it is a dogma.

The trouble with dogma is that it doesn't help you to explain to an outsider what is good or bad about something. It is just true. I can give an example from UK politics. Some time ago a left leaning (and very intelligent) friend of mine declared that a policy of the Conservative Party was bad because "it is privatising the NHS". Why is privatising the NHS a bad thing? I asked. To this, she had no good response. She spluttered that it is obviously bad that the NHS should be privatised but couldn't drill into why it was bad. I am not saying I support the privatisation of the NHS but I'd like somebody who definitely opposes it to be able to articulate what is bad about it to help me make a call on whether I should support it or not.

So dogmas are very good for preaching to the converted. In the political arena they make great sound bites for a party conference and if you repeat them often enough they may even start to sound true to those people outside of your bubble. They don't do a good job when it comes to convincing people to modify their stance to somewhere nearer your point of view. So it is with tech@core. I started noticing that we are trotting it out as a dogma and people aren't necessarily doing a good job of drilling into why it will help your business.

What Does it Mean to our Clients?

I worked for a very interesting client last year. They described themselves as a "tech company" but their assertion is based on the fact that 95% of their business is now done through their website. In fact, they are far from being a tech company and that was very clear to us while we worked there. But what is a "tech company" and why is it good?

I'm not sure what it really means to be a tech company. I am pretty sure that the startup I worked for before ThoughtWorks was (and remains) a tech company. My contention to that effect is based on the fact that the tech organisation is highly integrated with the business organisation and takes a full part in ideating and realising the company's products. At every step the tech people are involved in conversations about what the products will look like and they are involved as much as other business people in the high level decisions of the company.

On the other hand it has become clear to me while working for ThoughtWorks what characterises a company that definitely isn't a tech company. Some examples of such behaviours would be treating tech as a cost, "throwing things over the wall" to business people for approval, insistence on detailed requirements before building new things (from tech to business) and insistence on set in stone, almost written in blood, delivery dates for everything to be built, no matter how big or uncertain (from business to tech). In fact, the very existence of a "them and us" attitude between business and tech is pretty easy to spot and probably the biggest indicator that the company is definitely not a tech company.

Sometimes a company is struggling so badly to get something, anything, done that any improvements we can help them make are welcomed. In that way we can start to improve things and play our messaging at the same time. The improvement will be seen and the messaging will reinforce that the better place that we are on a journey towards is called tech@core and everybody knows that we are getting there because they can see it. Thus the message becomes a bi-product of the necessary actions we are taking rather than a thing that helps us to start on the journey.

But why should a company aspire to be tech@core if it can't see a problem that needs fixing? My problem last year was that our client, dysfunctional though it very definitely is, is delivering on its growth targets in spite of everything. How can we convince them that they need to be tech@core when the only thing the CEO sees is the bottom line which seems to be a good bottom line? Our biggest problem is unlocking some of that growth to fund the investment that their platform and their internal organisation needs to avoid a looming disaster. And therein lies the problem. We gave a proposal involving a smallish team of our people spread across their business to help start them on the journey from where they are to tech@core. The first response was that the cost was "more than [the CTO's] capex budget for the whole year". This comment told me a few things but most importantly it told me that the company saw technology as a cost centre that supported its business.

So What IS Their Problem?

We worked at MyBigClient for 3 months with their technology teams. We saw a lot of dysfunctional behavoiur, including, but not limited to the following:
  • Mistrust between business and technology. Leading to:
    • Insistence on specifying delivery dates for features at the time of maximum uncertainty for the implementation (the start).
    • Reluctance on the part of technology teams to innovate because of perceived risk and the desire to not be blamed for failures.
    • Time consuming risk management theatre style meetings ostensibly to decide on actions but in reality to share blame collectively when things go wrong. 
  • 2 weeks "regression testing" before every release leading to longer cycle times and more risky releases
  • Misalignment of goals between business and technology.
  • Some teams driving technology led change without business sponsors or clear business value,
  • Poor understanding of Agile principles leading to poor engagement in Scrum rituals.
  • Ever increasing technical debt, the tech debt cycle that I have previously written about.
BUT despite all of this dysfunction the company is still (as far as I know) achieving the growth targets that have been set for it by the private equity fund that owns it.

The Cost of Doing Nothing

We were asked by the CTO to make a case for implementing the change that we believe is necessary for the business to continue to be successful. As I've said before, everybody understands waste and wants to eliminate it from their business so initially I focused on how much money MyBigClient wastes every week / month / year on the processes they have in place to make up for the fact that their culture and structure are dysfunctional. I did some calculations and it turned out that the amount of money being wasted in this way was surprisingly uninteresting. It was so uninteresting that it was dwarfed by the spend that we were proposing for the first 6 months of our engagement with them. This was a little surprising to me and not a little disappointing since it meant I had to try to make a convincing economic case first to myself and then to their CEO.

Building a Case - Understanding the Problem Myself

We were asked to attend a board meeting at MyBigClient at which we would summarise our findings from the earlier engagement and make a case to the wider board (the CTO and head of product were already convinced) that they needed to engage a company like us to solve their problem. We got together a small team to work out how to make this pitch. This team consisted of myself, the CP (Client Principal, ThoughtWorks speak for a client relationship manager) and two product specialists. At various times we had some of our retail domain specialists in the room to help understand the wider context of MyBigClient.

I had already prepared the "cost of doing nothing" slide for an earlier meeting with MyBigClient and passed on to this bid team the disappointing findings of it. Very quickly, one of our product people told me that he wasn't at all surprised. He went on to tell me that we shouldn't even be talking about technology staff, or indeed any staff, as a cost. Thus it was wrong headed to talk of cost saving as this is very limited in its impact (as I'd already discovered) and its story telling power (as I was starting to learn).

Burning Platform - NO

As a quick aside, I was asked if MyBigClient was a case for the Burning Platform metaphor. I actually think it was (and remains) a very solid candidate for this metaphor. I didn't, however, want to use this argument for two reasons. Firstly, I wanted to paint a more positive picture to the client than "if you don't do anything you'll die" message that goes with the burning platform. Secondly, I hate this metaphor with a passion. My cousin works in the Scottish oil industry and I know several others who work in that industry. I think it should be beneath us to use such a grisly metaphor and we should be capable of coming up with something better to illustrate this point.

Opportunity Cost

While we were at MyBigClient there were at least two major production incidents that caused a prolonged inability to sell things. It was possible to estimate the cost of lost sales incurred by these outages but again it wasn't that interesting. It was even less interesting when some people made the argument (not proven as far as I'm concerned) that those sales weren't lost, they were just postponed.

Our product person was very quick to home in on cycle times and how long it took to release new features. She was asking such great questions that I realised that the original engagement may have had slightly better outcomes if we had had a product specialist instead of one of the two technologists for the duration of the gig. In any case the question became "how much did it cost to not have these features"? We had always had this question in the back of our mind but it is a hard one to answer because it involves understanding the value of a feature before you've tested it live.

The "Killer" Feature

When she asked me to give some examples of stuff we'd seen it became pretty obvious pretty quickly what we should be concentrating on. MyBigClient had been delaying its launch into the US market for months pending the release of a feature that they were calling "US Tax". I don't remember the precise details but apparently you can trade up to a certain turnover in the US (which they were doing) without calculating local, state and federal tax on your sales. Rather, you can leave it to the buyer to pay the relevant taxes. In order to for MyBigClient start marketing campaigns or open a bricks and mortar presence in the US, it was necessary for them to have the US Tax feature in production. This feature was at least 6 months late despite it seeming relatively simple to implement.

So if we made some simple assumptions about the opportunity size of selling into the US market and multiplied that by the delay, assuming some reasonable time for the implementation of the feature for a high performing business, it was possible to paint a much more convincing picture of why change was necessary. More importantly (at least for my sensitivities) we could do this without painting a bleak picture.

Why did it take so long and what is the Solution?

It is hard to say exactly why the feature took so long to deliver except by saying they aren't doing anything much right. All the dysfunctions are there. Engineering practices are weak, there is lack of trust inside the company, lack of engagement at all levels and a huge fear of taking decisions or any kind of risk. Our problem was to summarise all of this in a couple of slides. The solution, sadly for them, is not a silver bullet but a long program of change. But how could we convey it? Eventually, after much discussion, we came up with some wordy slides around opportunity cost, focusing on US Tax, coupled with the slide reproduced below which drilled into what tech@core means for them.

Drilling in to Tech@Core

My concept slide that I gave to the demand person in our team:


My idea was that I wanted to home in on their (mistaken) belief that they are a tech company ("we do 95% of our sales through the website, of course we are a tech company") by splitting it into some sliders that they wouldn't dispute. The argument being, move yourself to the right of this picture and you will fix some of your problems and you will become a tech company and everything will be great.

Fortunately, the client principal I was working with is much better than I am at playing with graphics in Google Slides. He loved my concept, played around with it a bit and came up with this:

So we had found a way to link their dysfunction with the solutions to their dysfunction in a way that we could link back to our own marketing of tech@core.

The Outcome

We had the meeting in which the CEO accepted all of our points. They were impressed with the knowledge that we had built up of their organisation and the "amazingly accurate" descriptions of what had happened in the past that we hadn't seen or asked about. They agreed that they needed to put in place a plan to fix all of the dysfunction that we had highlighted. A few weeks later they came back to us to tell us that they wanted to implement the suggestions we had given them in the outputs from our original short engagement but they felt that they can do it all without us. Ah well, you win some, you lose some. I really enjoyed working there and I would have loved (would still love it if the opportunity arises) to go back there to drive their transformation. Good luck to them, I hope they succeed and I'll be very interested to cycle back to them in a couple of years, if they haven't engaged us in the meantime, to see if it is possible to drive an effective and lasting transformation without introducing an external change agent.

Tuesday, 18 December 2018

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.

Saturday, 8 December 2018

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.


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.


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.


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.

Thursday, 6 December 2018

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!


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

Saturday, 17 November 2018

Devoxx Belgium and Two Talks


I was at Devoxx Belgium last week. Great conference.

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.

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.