Thursday, 10 February 2011

Go with the flow

One of the major problems that Agile tries to solve is the big bang approach to software development. With Waterfall, you do big up front analysis, followed by big up front design, followed by a long period of development. Testing usually gets squeezed because of time pressure, and integration is done by the seat of the pants. There are several flaws with this approach - you don't get any return on investment or learn how valuable the software is until it goes live. There are lots of projects that never go live, or that when they do turn out to be worthless. I'd much rather learn this lesson after three months, than one year.

Scrum (and other Agile methods) attempt to dampen this graph, by delivering little and often, in what is called a sprint. The initial release may take a few months, but once live, the software should be updated regularly. I've worked on projects with one month, two week and one week sprints. Returning to our principles of fast feedback and acknowledging we would like rapid return on investment, it's clear that the shorter the better. But is a short sprint really the best we can do? Why constrain ourselves to the artificial notion of a sprint at all? Why not pull as much work through the system as our capacity can sustain and optimise the flow so that there aren't any bottlenecks?

One argument is it's necessary to plan and co-ordinate releases. If you only release once a year, it's likely that your release involves several manual steps - it's not worth the investment to automate it. When you release every week you learn to automate everything - the repeating opportunity for fuck-ups means it's just too dangerous not to. When you have a high test coverage and a fully automated deployment why work to iterations at all?

Abandoning iterations means rethinking the planning game. Instead plan on demand (as and when a development pair need a new story). This way you'll know the maximum amount possible and leave your decisions to the last responsible moment. Long planning games are a bad idea anyway. At the start of the meeting everyone's fresh, and will argue a card to death. As brain drain creeps in people lose interest. I don't value estimation either. What's really important is to keep stories as simple as possible and to prioritise them well. While we're on the subject let's cut drop retrospectives too. Sure they provide a forum for continuous improvement but why wait until the end of the iteration to raise a problem and fix it. Waiting isn't an Agile principle that I'm familiar with.

Showcasing individual stories to stakeholders would be pretty hard to pull off, but more importantly doesn't make sense. Demonstrating stories separately would result in loss of context, but just because you keep a regular showcase doesn't mean you have to work to iterations.

Release whenever makes sense for the business. If that's every day, once a week or with a batch of related functionality do it. If you're constrained by external dependencies such as specific marketing dates that's fine too, but don't organise your development cycle to those release dates, go with the flow.

Thursday, 3 February 2011

Non Violent Communication

Back in February 2010 Simon Baker of Energized Work blogged about accountability in agile teams. He's right when he states "Saying nothing rather than speaking up is the worst thing we could do", but this doesn't make it easier to say "I think your code is crap". Even if you wrap it between two slices of Hovis, you're still handing someone a shit sandwich. I've tried all sorts of techniques for working around this, but rarely leave the conversation feeling good. I don't like hurting people and it doesn't matter how gentle or indirect I try to be, this always seems to be the result. Recently I came across a technique called "Non Violent Communication" which may just help.

The first aspect of NVC teaches how solicit different behaviour from people without upsetting them. The trick is to make a specific, positive request, expressing your own needs and feelings while being careful to avoid blame or judgement. This will encourage empathy and therefore compassion. When people feel compassion they usually respond with a genuine desire to help. The result is a win-win situation. It's like helping an old lady across the street - the old lady gets what she needs and you feel great about yourself for doing it.

So how does this work? Well a non NVC approach to criticism might go something like this:

   "Your code is too complicated"

Let's take a second to break this statement down:
  1. "complicated" is a judgement.
  2. "too complicated" implies there is something wrong with being complicated, and therefore something wrong with my ability to code.
  3. "Your code" implies blame.

   "It's your fault that you code badly"

Not only is the recipient likely to respond defensively, but you haven't actually asked them to do anything differently in future. The formula for making requests using NVC is as follows:
  1. Make an observation
  2. State how you feel
  3. Say what you need
  4. Make a genuine, specific, positive request.
For a request to be genuine, it cannot involve coercion (e.g. threat of punishment or offer of reward), or be replaced with a demand if the request is denied. A positive request is one which suggests action. A negative request is one which suggests the other party stops doing something.

So the equivalent NVC request might go something like this...

    "When you write methods that do several things or operate at different levels of abstraction I feel despondent because I have a need to work with a coherent code base. Would you be willing for me to show you how I would refactor this code so that I will find it easier to work with in future."

This time you haven't judged their code, you have simply made an observation about it. You have told them how you feel, but haven't blamed them for making you feel this way. You have expressed a need to work with a coherent code base and even if you disagree on what makes software coherent, they are likely to relate to this and feel empathy. As a result they will probably also feel compassion and want to help you. Rather than make them guess how to help, you make a specific, positive request. The request is genuine if it has no strings attached and if it does not turn into a demand should they refuse.

The NVC approach is far less confrontational and reading the above I think it would be quite difficult for someone to refuse, but supposing they did:

   "I don't have time to sit with you and help you understand my code. I think it's perfectly readable and if you can't understand it that's your problem"

Using NVC you can't demand the other person does what you want. Demands limit us to two responses - compliance or rebellion. Compliance against our will leaves us feeling abused and resentful. Furthermore when we do something as a result of coercion we rarely do it to the best of our ability. Rebellion risks escalating the situation and also leaves us feeling unhappy. When dealing with a refusal, the NVC approach is to empathise with the other person, then to make another request.

   "I understand that you feel under pressure, and are probably frustrated when I ask you to do something you think is unnecessary, however when you refuse to let me show you how I would refactor these methods, I feel concerned for the quality of our code base. If other members of the team agree that it is worthwhile would you be willing to work with me then?"

and so on.

The second part to NVC teaches that aggressive or violent language is typically an expression of a deeply felt, unmet need. Instead of responding to what was actually said, you should focus on exposing the unmet need and empathising with the other person. Once the need has been exposed and sufficient empathy has been given you will find the tension vanishes and a constructive conversation can be begin. Taking our example from the opposite angle, what if someone were to aggressively criticise you for writing overly complicated code?

Tim: "Your code is too complicated!"

Me: "Are you feeling frustrated because you are finding it difficult to follow or update code that I have written?"

Tim: "Yeah, it's totally minging. The methods operate at different levels of abstraction and do multiple things"

Me: "I can see how irritating it must be to work with code you find unpleasant, however when you say that my code is too complicated I feel defensive and I have a need to work in an environment where people are spoken to with respect. Would you be willing to sit down with me and show me what it is about my code that you dislike so that we can resolve this agreeably?"

Instead of responding to Tim's statement the NVC approach is to guess what he is feeling. Don't worry if you guess wrong, he's likely to give you more clues. If you guess right, empathise by reiterating what he has said. It may be that Tim has several unmet needs, or that he needs more empathy than a single response, but repeat the process until you feel the tension lift. Then start with your NVC request.

When I started practicing NVC I was concerned that my language would be formulaic and trigger an adverse reaction, however once you are experienced with the process it's possible to short circuit it a bit. Another criticism is that it takes a lot of patience and time. I find the opposite - it takes less time and effort deal with a situation pleasantly when it first arrises, than to foster resentment by bottling up emotions or demanding compliance.

One frequent question is what do you do if repeated attempts at NVC do not work? For this I refer back to the NVC bible. It would not be practical to attempt to stop a mugging by tapping the aggressor on the shoulder and telling him you feel concerned for the safety of the victim when he attempts to rob them. As such NVC does not discourage the necessary use of protective force. I think in business the same applies, but the timescales are different. If after genuinely trying NVC the quality of someone's work is still lacking then express your concern that they are not producing adequate results, and ask if there is something else that they would rather be doing. Your other option is to fire them, it may be best for all concerned (see section 2)