Month: December 2012

Agile people over agile process

In June 2012 I gave a talk at QCon New York titled ‘Agile people over Agile process’. The full talk is here, and below are some of my thoughts on this topic.

Summary

What’s below is pretty long so if you don’t want to read it all, here’s the essence of my opinion.

In the ‘agile world’ these days I see a decent amount of pre-defined, unarguable, process and dogma – the very things that the agile movement initially tried to do away with. I think it’s worth stepping away from this and focussing first on individuals, how they communicate, and how as a team they best choose their techniques and tools

There are no such things as ‘best practices’, at least when it comes to being part of a software team or software project. There are practices that teams find useful within their context, but each context is different. Teams would do well to continually re-judge what process and tooling works best for them.

Agile teams can use values and principles to help drive their choice of process and tools.

So let’s begin…

There’s too much focus on process

When I got started in the agile world 10+ years ago we used to talk a lot about extreme programming (XP), Scrum, and the like. Obviously part of that was figuring out test driven development, pair programming, continuous integration, iterations, etc. A lot of it was also about how we needed to change as individuals though. Gone were the times where we could just sit in our cubicle and complete our individual tasks on the almighty gantt chart. No longer could we assume that we didn’t need to test code because that was someone else’s responsibility. We needed to embrace how we worked as a collaborative team, and not just argue over Emacs vs Vi. This was a revolution in how we identified as humans on a software project.

People back then accused XP of being a developer-focused methodology, and they were right, but this was with good reason. For developers to be most effective they needed to stop just being pawns in a bigger process and start talking to people, work with feedback, and take responsibility for delivery. XP helped them do this.

People in the agile world still talk a lot about Scrum, lean, kanban, etc., just like we used to 10 years ago. However I feel the tone of a lot of conversations has changed – now a lot of times it’s just about the process. Agile seems to no longer be about people changing their attitude to projects, to delivery or most importantly to people. Now often it’s just about introducing a new team management methodology in the hope that Lean or XP or whatever will be a process magic bullet that will solve all their problems.

But with process, as with many other things, there is no magic bullet.

Process is very important. It’s where the rubber of any methodology hits the road, but there are problems with an overly-zealous focus on process:

  1. Processes can become kings. Processes are at the end of the day just tools – they have no intrinsic value by themselves. They can only be judged valuable in the context of their application. When processes become kings then our discussions descend to hypothetical judgments of a supposed intrinsic value that the processes don’t have. Such discussions are a waste of time and don’t help anyone.
  2. If processes are considered axiomatic then we can no longer adapt how we work. If we believe the best way to do something is X, yet we do not understand the motivation for X, how can we decide if Y would be better?
  3. It misses the the point of what Agile was supposed to be about…

What I think is important about Agile

The Agile Manifesto starts as follows:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools…

In other words the unique characteristics, personalities and abilities of members of a software development team, and the conversations that they have with each other and with their stakeholders (management, users, etc.) are worth considering more than the process and tools that they use.

This is not to say at all that processes and tools are unimportant, I am merely arguing that that they are not so important that they should drive discussion about the basic way we choose to deliver software.

Focussing on individuals sounds like a management technique. While that is important, I think it is more a call to individuals themselves to consider how they can most effectively be part of a software delivery effort.

There are many ways individuals can answer this call, but one way that may be useful is to look at the values and principles from ‘Extreme Programming Explained‘ – Kent Beck’s original book about XP. These values and principals are not specific descriptions of how to do something but guides to help people decide how they actually want to work. I’m not going to go into detail here since literature is already available for each point (and I also discuss further in my talk at around the 13 minute mark), but a list of ideas is as follows:

Values

  • Simplicity
  • Communication
  • Feedback
  • Courage

Principles

  • Assume the values are present
  • Incremental change
  • Deliver at the earliest responsible time (an addition / variant of mine that I think is worth considering separately)
  • Quality (the Jim Highsmith article I refer to in the talk is here)
  • Accepted responsibility – everyone on the team should assume they have responsibility
  • Local adaptation – change everything according to context

How this applies to practice

These values and principles are all somewhat theoretical – the application of them is the actual choice of what set of  practices and processes a team choose to use. Not one pre-defined overall process, but an active, continuing choice of what techniques to use.

This is necessary since in the case of software development teams and projects, there are no such things as best practices. There are practices that teams find useful within their own context, but this is not an absolute categorization.

How I’ve recently embraced this

In the video I describe how I applied these ideas on my most recent project. It starts at about the 28 minute mark. It made sense to include this in the talk but I’m going to leave detail out of this post.

It is worth mentioning here though that there are certain ‘typical practices’ of agile that we did use but others that we chose not to. For example we didn’t use ‘iterations’ to structure our week-to-week work. However we did often deploy new software, we frequently re-prioritized our next work, etc. Since we already did these things formal iterations in our world would have been unnecessary baggage. For many other teams formal iterations would be very valuable.

Is this really for everyone?

In discussing this subject some people have challenged me that this way of thinking is only useful for ‘experts’, such as people who already have previous agile experience. I disagree. While I think that picking an off-the-shelf methodology might make for a ‘decent first set’ of practices I think a team needs to know from the beginning some amount of why that may be so. I think for someone with experience to provide a pre-canned process set as ‘the way things should be’ is disingenuous.

I wouldn’t expect everyone on a team new to agile to be able to immediately make their own choices about the entire implementation of principle to practice, but I would expect them to know that the introspection of their process (based on values and principles), and their subsequent refinement of the same, is a more important aspect of agile development than any of the individual techniques they may be using.

Concluding thoughts

None of this is new at all, and a lot of the good agile literature from the last decade describes these ideas. As a more recent example Ross Pettit does a good job talking about them here.

I think it’s worthwhile repeating it though for 2 reasons:

  • I see some amount of the agile community as a whole moving to a ‘process first’ mindset and I disagree with it.
  • I’ve seen myself at times throughout my career treating process, practice or technique as dogmatic. Invariably when I do this it’s because I’ve missed something important. Stepping back and thinking ‘why’ always leads to improvement. I think this is a valuable reminder to myself and hopefully others.

5 months banking with Simple

Five months ago I opened a bank account with Simple. Here are some thoughts of how things are going so far.

tl;dr . I like Simple and will keep using them for most of my banking, but they can’t (yet) fully replace all of my banking needs.

Updated – The friendly people at Simple got back to me about a few things I mention here and I’ve put a few notes at the end, with in-line markers.

Simple (originally named ‘Bank Simple’) is a new ‘bank’ that aims to bring the usability of modern web-commerce to retail banking. I quote ‘bank’ since they are not legally a bank themselves, they are effectively a customer proxy on top of a separate underlying partner bank (currently Bancorp.)

I’ve been living in the US nearly 7 years and the customer experience of using banks here is pretty poor, most notably their websites. I used to bank with Citi and I currently bank with Chase, and for each I’ve routinely cursed their online capabilities. Things are getting better, but very slowly. When I heard about Simple I decided to give them a go.

The main benefit of using Simple over a regular bank is that they aim to provide a much better online experience, both through the website and their mobile app. With this they absolutely succeed. Both apps are fast, have a decent amount of useful features, are clean and well thought through. As an example once you’ve signed in on your mobile phone once with your full passphrase you can subsequently just use a short PIN. Try to sign on somewhere else and you’ll still need the full passphrase.

The apps also offer a lot of features to help you keep track of where and how you’re spending your money. This is less useful for me since I tend to do most of my spending through my credit cards, but I could see this being interesting for some.

Simple are also pretty good on the support front. There’s been a couple of times where I’ve needed to communicate with a human being and they’ve been efficient and friendly. They are still a relatively small company though and I’m sure that helps.

I’ve moved most of my checking account (current account in UK parlance) activity to Simple – which is mostly my regular bill payments (credit cards, rent, etc.)

There are, however, a few things I haven’t moved to Simple and for this reason I still keep a checking account with Chase. The main reason is ATM (cash machine) usage. Simple do offer free access to a large network (Allpoint) of ATMs but there are a couple of problems for me:

  • In New York City at least there are far fewer Allpoint ATMs than Chase ATMs. I did once try to find the nearest Allpoint ATM to my apartment, which is about twice as far away as my nearest Chase branch, and I wasn’t even able to find it once I got to its supposed location.
  • Allpoint ATMs tend to only allow taking out $200 at a time [1] (they are the kind of ATM you find in small stores, Walgreens, etc.) While this is sufficient most of the time for me there are occasions when I want to take out more than that. Chase will let me take out up to $500 at a time should I need it.

Simple could fix this by offering to pay fees on any domestic ATM you may want to use. Other banks do this, often up to a limited amount (e.g. the first $15 of ATM fees per month). Of course my friends in the UK are probably laughing at this point since in the UK anyone can use any ATM for free – I do miss that.

Another reason to keep a bricks-and-mortar bank account is for the very occasional times you need something from a branch. For example when I first moved into my current apartment my landlord needed a cashier’s check [2]. Recently I also needed a special kind of financial notarization when changing my brokerage accounts and my local Chase account would do that – I’m not sure if they would have if I didn’t bank there. Simple also don’t (I believe) currently offer outgoing international wire transfers which could be a deal breaker for some people.

I could likely survive without these services, especially if my wife were to keep her ‘regular’ account.

Another area where Simple don’t quite do what I’d hoped is that I wanted to move my money from one of the ‘mega banks’ to a much smaller company. While Simple are still small their partner, Bancorp, is part of US Bank – still pretty huge [3]. I doubt I’ll ever have the situation I did in the UK where I was able to have a good banking experience with an ethical bank (the Co-operative bank) but I still hold out some hope.

So, in summary, my first 5 months with Simple have been encouraging and enjoyable. If they can fix up the ATM situation I may even close my regular bank account.

[1] Simple will allow you to take out up to $500 / day from an ATM, but if the ATM you’re at will only let you take $200 / time you’ll need to perform multiple transactions.

[2] Simple will mail you a cashier’s check if you request one. The once or twice I’ve ever needed one though I’ve needed it the same day to secure the apartment I’ve been looking to rent.

[3] Apparently ‘The Bancorp Bank” (who Simple partner with) is not part of “US Bancorp” (yes, I’m confused too.) “The Bancorp Bank” is its own entity and a small – medium size bank.