I prefer interviews that are a conversation as opposed to me asking questions and listening to answers. I want the candidate to engage with me like they would a colleague – it shows they’re taking the process seriously and are interviewing me just as much as I am interviewing them. I love it when I leave an interview thinking “I really want them to work here, I hope we impressed them enough!”.

What I want to know about a candidate is what experiences have they had before and how they dealt with them. I want to hear about real world examples. Questions will usually take the form of “Tell me about a time that X, what did you do?”

“X” could be:

  • you had a difficult team member.
  • you had a ridiculous deadline.
  • you had some tough politics.
  • you worked with remote stakeholders.
  • things really went bad.
  • thing went really well for you and the team.
  • Etc…

Usually these will be a conversation rather than a question/answer session, but still based on the candidates actual experience as opposed to “What would you do if?”. However, it’s OK to say “Actually, I’ve never had to deal with that, but if I did, I would …”

I also want to know about actual projects themselves as I’ll be trying to get a feel for team/project size, the position of influence the candidate felt they had within the team. The language people use is important – are they talking about they/them or we/us?

I’m looking for PM style – are they command and control, or servant leader? Or somewhere in between? The language they use is as important here as the actions they took. Do they use people’s names from previous projects, or just “the developer” this is telling, although not conclusive.

Finally, I’m looking for evidence of autonomy and mastery. I want the successful candidate to be someone I can point at a problem and they’ll get on and deal with with little interaction from me.

Should you have a set number of acceptance criteria?

Should you have a set number of acceptance criteria?

A conversation came up today in which a statement was made about having a set number (three, in this case) of acceptance criteria per user story. My gut reaction was that I didn’t agree, how can you define that? But then I got to thinking that maybe it wasn’t such a bad idea.

I turned to the internet and asked twitter, the replies were heartening.

I agree with these replies, however, I’m not convinced on having a fixed arbitrary limit. I think it’s a case of being vigilant and for someone to say “Hey, that’s a lot of A/C, maybe we should split this?”

It’s also relatively simple to avoid the limit by loopholes. For example, your A/C could be described as Given, When, Then. In this, you could add “and then … and then… and then…”. It’s still one A/C, but has multiple steps.

As with everything in the world of building software, it’s about balance and discipline.

A great retrospective!

A great retrospective!

I’ve blogged before about remote teams where I am now and how well we manage to make it work, even with people in another timezone. Because we’ve got people remote, our retrospectives are, naturally, done over video chat (hangouts in our case) and we use webwhiteboard (by none other than Henrik Kniberg!) to make it as interactive as possible.

Today, we had just such a meeting and I really wanted to show you the output. Nothing much to learn from this post (except how we retro), but I thought the webwhiteboard worth sharing – just for fun.


Sunday Link Dump!

Sunday Link Dump!

First up, is this most excellent post from Joshua Arnold over at Black Swan Farming. Called “Standing Up Doesn’t Scale” it’s a comment on “false friends and local maxima”, that is having standups and kanban boards, without actually knowing why you’re doing it and what problem you’re trying to solve. Too many organisations are like this and it’s frustrating for everyone involved -especially those hired to help with the transition in the first place.

#noEstimates is a torrid love affair of biblical proportions and, by biblical, I mean magic pregnancies! Anyway, I liked this post from Glen B. Alleman over at Herding Cats because he’s, again, poking a stick at fanatic dogmatism. I don’t agree with everything he says, but it’s a good speech from the prosecution. The Problem With #Noestimates

One for the people people here. Hiring is one of the most important things you have to do in a business – no, seriously, it is. Hiring the wrong people (or, the right people for the wrong role) is hugely damaging to your company. This post talks about what it takes to hire hire an engineering manager. From Calille Fournier at Elided Branches, Hiring Engineering Managers: Screening for Potential

Nothing is immutable

Nothing is immutable

“But they’re the project goals!”
“So what? They’re not appropriate any more.”
“But they’re the project goals, you can’t change them!”
“Watch me.”

Challenge everything and remember, nothing is immutable. If you make your project goals redundant (and you should always try and prove the negative hypothesis), you’ve made a huge discovery.

Nothing is above the laws of science – hypothesise, test, learn.

Dancing to the wrong beat

Dancing to the wrong beat

It’s something we’re not going to get away from: mashing traditional projects and project management with agile. You know it as many names – waterfall, scrumerfall, scrumbut – each as bad as the last. It comes in many guises: time lines, gantt charts, milestones and my favourite, governance.

You can have timelines and milestones, they’re not too far removed from Release Planning, as coined by (and then retired by) Mike Cohn. Gantt charts are OK, if you turn them on the side and use them as a product backlog, but something I cannot really get behind is governance.

Now, there are a truckload of different types of governance, but what I’m talking about is “agile governance”. Brian Wernham talks about it an an APM blog post here and it’s an interesting read. Essentially, it’s a sponsored, empowered set of controls. You could argue that the blog post is over 18 months old and not relevant anymore, but my experience says otherwise.

Sounds crappy, huh?

The idea of governance is that it allows a group of key project people (think stakeholders and team members) to get together regularly in a room and talk about the project. Not altogether too dissimilar to sprint demo, except the governance meeting is future looking and the demo is a view of the last itertion.

The trouble with the governance meeting is that it tries to tie you into a plan, “What are we going to do next?”, “When can we have X thing?”, “What are our biggest risks and how do we avoid them?”

But the biggest and most troublesome problem with the governance meeting is compounded during an “agile transition/adoption”, you can bet your ass that before a company started being agile, they had governance meetings and so, after the adoption, continuing with the governance just helps to reinforce bad habits and out of date ideas on how “projects” should work.

The meetings cause anxiety – instead of going into it (as in a demo) with a list of things to show for your effort, you’re going in with a list of problems that, if you could solve them, you already would have, so they’re unsolvable right now and not worth talking about, they just make you more anxious. You’re going to talk about the future of a project with some of the wrong people and not all of the right people – afterall, it’s a team sport – why leave some of your A players on the bench? Many of the people in that room will not be in your team and not be accountable for the work that get’s done, the planning or the outcome.

Push to get rid of governance and provide everything anyone needs at your demo. It’s the only way we’ll make any real progress on a project. I think that the GDS has got it mostly right. It’s the government, so they’re going to have governance, but they couch it in these terms

GDS has defined 6 principles for governing service delivery. Following them should help you create the right culture within your service. They are:

  1. Don’t slow down delivery
  2. Decisions when they’re needed, at the right level
  3. Do it with the right people
  4. Go see for yourself
  5. Only do it if it adds value
  6. Trust and verify

See what it doesn’t say there? It doesn’t say weekly (or regular) meetings with the same people just to see what the status of a project is and complain when it’s not “on schedule”. Head through to the Governance Principles page, it’s an excellent and enlightening read.

It’s not often anyone can say “let’s be more like the government”.

Link dump! Agile is the new waterfall, from chaos to managed chaos, best practice and more!

Link dump! Agile is the new waterfall, from chaos to managed chaos, best practice and more!

Agile Is The New Waterfall
“Agile promised us engineer driven development.” is the first of many fallacious claims that the CTO of makes in this rant that woefully misunderstands what agile is. He makes the odd good point, but then messes up the punch line (I especially like the bit about estimating). I suggest you read it with an open mind, otherwise you risk a hernia.

From chaos to managed chaos
Vasco Duarte tweeted this during the Coding Serbia conference. It’s one teams journey from estimates to #noEstimates. An interesting read.

Four Ways to Kill Best Practice
I’ve blogged about best practice before, but Megan Louw from ThoughtWorks offers some practical advice on getting rid of the idea from your business entirely.

Some cheeky self-promotion on the new agile slack channel I recently created. We’ve got a massive 23 people online now – come and join the conversation

How Google Thinks About Hiring, Management And Culture
I really enjoyed Work Rules! By Laslo Bock, who used to be Googles SVP of operations – there are some excellent ideas and stories in there and plenty of SCIENCE! This has an interview with the man and some key points from what he was saying – worth a listen.

#agile slack channel –

#agile slack channel –

I’ve started a new Slack channel called #agile. You can find out more and signup at

A while ago I started a #people Slack channel, for discussion around HR, management and people ops. At the moment there are ~260 people on that channel. It’s not always busy, but there’s usually someone to ask about things, or just have a conversation with. I looked for a similar channel for agile discussion, but came up short – so, I thought I’d make my own.

There is no shortage of forums and websites, communities and clubs with which to talk about agile, ask questions and get answers. What there isn’t, though, is somewhere to get live chat, instant replies and all the other good stuff that you get from something like Slack. #agile is a chat community for talking about all things agile: from software engineering to scrum mastering, methodologies, culture, process and anything else.

So, if you’re interested in chatting with other folk about all things agile, then head to, sign up and join in the conversation. It’s a bit quiet at the moment, as it’s only just started, but all it needs is your voice as one of the founders to make it useful.

The secret of #noEstimates

The secret of #noEstimates

I’ve not really understood the no estimates movement. I’ve read a bunch of blog posts and followed the twitter hashtag and discussed with friends and peers, but it just seems like a different kind of estimating, albeit using empirical evidence (not that story points don’t).

Anyway, the secret is this: INVEST.

If your stories adhere to this acronym, then you’ll be able to do #noEstimates and, by “adhere” I really mean, be “Independent”. I believe this is the one most important things about the movement – being able to make decisions about what to build and deploy, how to prioritise and project comes down to the quality and size of your stories.

The trouble is, that is really, really difficult.

How to have better remote team meetings

How to have better remote team meetings

Where I work now, half the team is based in Romania. Yes, they’re an offshore team, but you wouldn’t think it the way they integrate so well with our teams, tools and general day-to-day. One of the things I was way of when I started, was how they would get involved with team meetings, like planning, stand-ups, retrospectives, etc.

I’ve experienced people joining team meetings remotely before: there’s a room with most of the team in, sitting around a table and then one giant talking head on the screen (it’s even bigger on a projector screen). It takes real discipline and frequent repetitions to make sure the remote worker is included in the conversation and gets the value they need and the common understanding the team needs.

However, at my current job, we do it slightly differently. Instead of booking a room and having one or two talking heads, everyones does the hangout from their desk instead. The key thing to experience here is that everyone is “remote’ in that they’re dialling in.

It levels the playing field for the whole team.

Yes, it levels it lower than in-person meetings and you have work hard to make sure it works, but I’ve been surprised and impressed at how well these meetings have worked. Especially complex meetings that involve more interaction like a retrospective.

It’s not perfect – it’ll be a long time before remote team meetings are on par with IRL ones – but it certainly helps keep remote members feeling included.