Personal Responsibility

Last week I was able to attend Agile Africa 2015. The most inspiring talk, amongst the many great talks and conversations, was Kent Beck’s closing keynote. He talked about the engineering culture at Facebook and its key overriding value of taking personal responsibility.

At Facebook as Kent Beck described it
The task you pick up is your responsibility to get right. All parts of it. Even when it is the first task you do when joining. There is no one else other than the developer who is responsible for the decisions required to get it done. If you deploy a bug, someone else may see it and will fix it. And they will give you feedback. Everyone is responsible.

When joining Facebook, developers join Facebook Engineering. Developers are not hired into a specific team at Facebook. In the first weeks the new hire chooses which team they will join. They are personally responsible for the choice to ensure that they join the right team and make the most impact in the organisation.

This is a culture that trusts you to know what you should be doing. If you get it wrong, you will receive feedback.

A culture
A culture of high focus on impact guides developers to prioritise their time effectively.

A culture of clear, direct and immediate feedback makes sure that there is a feedback loop on responsibility.

A culture of P50 goals drives improvement and striving for new thinking. P50 goals are goals that you aim to hit with 50% probability. Spread them around so that all the 50% probability isn’t in one area – otherwise no goals may be achieved at all! [1]

This is a culture of high responsibility, but associated with that must be very high trust. And it has scaled to thousands of developers.

Not Agile
Facebook does not claim to be Agile. There are pockets where there are lots of tests. There are even larger pockets where there are none.

What? The inventor of XP works at a non-Agile organisation? What does that mean? Is Agile dead?

Very agile
However Kent Beck has seen FB turn on a dime. FB is highly successful. Engineers enjoy working there – at least Kent seems to enjoy it immensely. It sounds like a very agile organisation.

Personal Responsibility
The key is leveraging personal responsibility. It is what Kent says he was getting at when he wrote the XP book.

High personal responsibility leads to developers needing coping mechanisms so that they don’t mess up. If you mess up, you own the mess – 100%. If you mess up too much, you won’t last long. If someone sees your mess, they will fix it – because they too are responsible – and you will get clear, direct and immediate feedback to act on for the future.

Personal Responsibility drives behaviours. It may lead you to TDD. It may lead you to lots of acceptance testing. It may lead you to implementing lots of metrics or monitoring a lot and responding as soon as errors are detected. All of these help a developer keep a handle on their work and hence help them to be responsible. There are no ‘the system is the fault’ types of answers to failure.

Personal responsibility leads to developers having to take control of the code base they are working on. It leads to developers being more confident of their work. If they are not, they fail. They will receive clear, direct and immediate feedback. And they must take responsibility for the problem.

XP has been pointing at personal responsibility. It also seems that personal responsibility can point straight back at XP as one of the possible outcomes of dialling personal responsibility to the extreme.

Personally responsible
Personal responsibility touches at the heart of much of great software development. It feels like it should be a core value to optimise around. I certainly am going to be thinking harder on what it means in everything I do.

If you weren’t there – watch out for the videos when they are out. It was a really inspiring (and funny) talk.

If you have seen the talk, let me know what you’re thinking as it would be interesting to hear what others will do around this.


[1] More on P50 goals in Growing Agile’s latest newsletter at


Retrospective talk

Last TEK day I did a presentation on retrospectives in order to generate discussion and deeper understanding in my company and team around what this thing is supposed to be about.

I’ve had some good feedback since then from people who were initially resistant to retrospectives.  However there is still lots of work to be done – as always in this space 🙂

Attached is the presentation that I talked from.  Though mostly this is bullet points that fire ideas.  Perhaps someone else will find this useful.

Retrospectives: A focus on getting better

Lightning Talk retro – Fixed Price Scrum

I did a 10 minute lightning talk at the Cape Town 2011 Scrum Gathering on Fixed Price Scrum.  It went down reasonably well – but if I did it again, I’d do it a bit differently.

The point of the presentation was to point out it was possible and effective to use Scrum to manage a project that traditionally is waterfall and would generally be a rather fast march to and past the end date of the project while blindly hoping you’d still make it.  Scrum allowed us to know early that the date wasn’t possible – which let us manage the client early and hence to come to a compromise and tweak the iron triange of fixed date, time and scope so that we could actually tweak the scope and deliver to the date – and then complete the rest of the scope.  I believe it has been the most successful fixed price project that we have embarked on by far.  So it was successful.  The client did get what they wanted.  (Luckily they did sort of know what they wanted as it was replacing an existing system.)

After the talk I realised that I had given some hope to some people that you could succeed in doing Scrum in their environment.  That was the point.

However I did start to feel guilty afterwards.  I did a talk on waterfall with Scrum helping out.  Yes, the Scrum was pull (mostly) and we inspected and adapted, we tested continously and we did reviews.  These were awesome and effective.  But we took a BRS, chopped it up and turned it on its side and called it a backlog and off we went.  It wasn’t agile.  I did a very non-agile talk at what was in theory an Agile conference…

The project wasn’t Agile in the sense of removing waste or in delivering value at all times.

The BRS generation wasn’t agile.  It was waste.  But the client needed it as a proxy for trust – and a requirement for public tendering.

The review process wasn’t agile.  It was prescriptive – did we meet the BRS.  Value was limited to the BRS and the scope management around that.

But the project was successful.  The delivery was of good quality.  The client is now a long term fixed team client.  We built up trust and a working relationship.

So does it really matter that it wasn’t agile?

If I did it again – I’d point out that we were doing Wagile.  And that there are still perks to using Scrum – even in waterfall.  And doing Scrum in any environment allows you to start learning and growing your understanding so when the opportunity comes to not being in the prescriptive contracting relationship, then you are already primed to embrace more agility as you may have started to figure out what that actually means.  And maybe while they are there – they can work out how to be as agile as they can – around the fixed constraint of the contract – and eliminate waste where they responsibly can.

Will fixed price projects go away in the future?  Unlikely.  Should any company contract in a fixed price arrangment?  Not if they can afford to do otherwise.  But would it be better to go bust and be agile or better to make a profit and be wagile?

Hopefully the next time I present it will be on something more relevantly agile and I’ll feel less exposed to agile frowns.  Or at least remember to point out that I know it is waterfall in agile clothing as I go along.