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.

Friday Link Dump

Fridays, so close to the weekend you can almost taste the lay-in and the breakfast burrito. So, to hurry it along, here are some of my favourite links this week:


The Unmyths of Estimating

The war between estimates vs #noEstimates still rages on and this is an interesting piece that evokes the dark, magelike forces of statistics and probability.

The Science Of When You Need In-Person Communication

It’s a little bit one-sided in it’s presentation, but this article does bring together some good evidence on in-person meetings. In a world where remote workers, Google Hangouts and Skyping are more and more frequent, we shouldn’t underestimate the power of touching someone (not like that, weirdo). Still, it does raise the question whether the details (like touch) of in-person meetings have an opposite or equal behaviour in remote meetings?

Going To A Conference? Don’t Waste Your Time

Careful with this title, it’s not “Don’t waste time by going to conferences” (which I thought it was – damn linkbait) instead, it’s “Going to a conference? Use your time wisely there.”. Interesting take on how to view conferences as a source for asking more questions.

Doctor Who Spin Off: Class

Doctor Who (and its spinoffs) are one of my favourite ways to pass the time, so, news of a new spin off, called “Class” by young adult author Patrick Ness is pretty exciting. No news on what it’s about yet, other than the school, but I’m looking forward to it anyway.

Meeting etiquette (or, how to be mindful when it comes to meetings)

Meeting etiquette (or, how to be mindful when it comes to meetings)

There’s nothing worse than a badly run meeting, except a badly booked meeting, or a badly behaved meeting attendee. Read this page, internalise its meanderings and never again be responsible for a bad meeting.


There are few things that annoy like a badly run meeting. They’re to blame for many of the world’s ills, not least of all, being the sole reason why many people feel like they never get anything done. Because they’re always stuck in meetings, or feel like meetings aren’t a valuable use of their time. This document will help. You’ll look at meetings in a different way and, hopefully, encourage others to as well. We’ll look at how to book meetings first, as this is the most important step. After that, we’ll look at your responsibilities as an attendee. Finally, we’ll close with some tips and tricks on how to get the most out of meetings.

Booking a meeting

It seems like this would be an easy thing to do, right? But take a look at your calendar now, go on, I’ll wait. I bet there are at least two or three meetings with obscure, ambiguous titles, that you’ve agreed to attend. Perhaps one or two that you’ve agreed to, but aren’t quite sure what they’re about right? There are also probably a couple that are back-to-back (one ends and another starts immediately).

Maybe you’ve booked meetings that look like these too? It’s OK, without proper training, you’ll just book meetings the same way your boss or peers do, but let’s change this now. Let’s look at how to book a proper meeting.

The key thing to remember when booking a meeting, is that it is your meeting. It is your responsibility for all attendees to get the most out of the allotted time to reduce the need to follow it up with another meeting about the first meeting later.


What are you booking the meeting for? There are a few reasons that you might want to take time out of your colleagues day to go sit in a room with them, some of them are worth it, some, not so much. If, for example, this is just a status meeting, then do you really need to meet at all? Is there a better way of transferring this information to you? Perhaps you can do it in an email? Perhaps you could bookend another meeting with this kind of stuff? There are plenty of online tools that allow you to gather status information from your team without having to sit together. Is it a discussion? A brainstorm? A workshop? The type of meeting will dictate just how you book it and who should be there.

A proper title

First things first, what do we call the meeting? Give it a decent description, something that gives the invitees a good understanding of what the meeting is about. “Meeting about stuff” is no good, “Quick catchup” is no better. You want to get the purpose of the meeting across succinctly. Try “Quick catchup about marketing goals” or “Meeting about the service agreement”. Instantly, the recipients of your request will understand what it is the meeting is about.

You don’t have to be overly verbose – there’s a description field for more information, but you want the attendees to be able to glance at their calendar and mentally prepare for what’s next.

Outcome, agenda, requirements and follow-up

Most of the failure of good meeting booking comes from not paying any attention to the agenda or outcome.


When booking a meeting, think to yourself “What do I want to have, or know, by the end of this meeting?” is it a decision? A document? An agreement? Put this in the meeting description so that the attendees know exactly why the meeting is necessary, eg:

Outcome: A decision on where we spend this month’s advertising budget.
Outcome: A rough draft of a document, detailing the next steps for building the service.
Outcome: Rough designs for the new mobile app.
Outcome: A plan for this week’s work for each team member.
Outcome: Agreement on: a) What to do with Bobs cat, b) When to apply for the licence and c) What to have for lunch on Friday.
With a clear outcome, attendees will understand the purpose of the meeting that much better.


Put down, in writing, how you expect the meeting to go. It doesn’t matter so much if your agenda isn’t adhered to, the most important thing is you achieve the outcome you set out to achieve. If the agenda goes awry, that’s fine. That said, it’s useful to HAVE an agenda, so attendees know what to expect. It’s also useful if your meeting will cover several different topics. You don’t necessarily need to put timings for each part of the agenda, but if it helps to keep you on track, then do so. eg:

0 – 2mins: Introduction
2 – 10mins: Outline of current marketing spend
10 – 30: Brainstorm potential avenues for exploration
30 – 50: Voting and discussion on top three
50 – 55: Wrap up and actions.


Depending on the type of meeting you’re having, you may have some requirements of the attendees. Perhaps they’ll need to read a report, or view a video or even just spend some time jotting down a few notes about what the meeting is about. Give people advance warning of what they may need to prepare for. If there are some documents required, then attach them to the meeting request (you can even do this with Google Calendar, you just need to enable a labs setting). Make sure attendees know:

Folks, before you come to the meeting, it’ll be a good idea to review the current state of the marketing budget/system architecture/world. I’ve attached a document that you should review before coming and make some notes on how you think we might proceed.


Finally, let people know what you will do after the meeting. Whatever the outcome, the very least you should do is email all the attendees, thanking them for the time and outlining the key points of the meetings and any actions that were decided (you were taking notes, right?). That way, there is no ambiguity on who said they’d do what or by when and it gives people a chance to sanity-check their understanding with yours.

After the meeting, I’ll forward the document we wrote and outline the next steps. Any actions for attendees will also be detailed in the email.

Attendees will appreciate you making notes for them.

Meeting Length

How long should a meeting be? Use your agenda and the number of attendees as a rough guide. The more agenda points and the more attendees you have, the longer your meeting will be. Use the timing to your advantage. If you want to get a decision quickly, then book a shorter meeting. If you feel like the topic would benefit from some longer discussion, then book a longer meeting. Pay attention to the people you are inviting to your meeting? Are they pretty busy? Look at their calendar and see what their day is like, they’ll probably appreciate a shorter meeting if they’ve got a busy day.

Shorter meetings are also useful for quelling useless chit-chat and clowning (unless you’re in engineering, there’s always clowning). All attendees, no matter how busy, will appreciate spending less time in a meeting room.

One thing to note, is that Google Calendar allows you to book meetings that end earlier than 60/30 etc minutes. This gives attendees a few minutes to get to their next meeting, which is very useful if they’ve got a meeting following yours.

Remember, when the outcome of the meeting has been achieved. End it. Let people disperse, if you want to carry on talking, you can, but make it clear that the purpose of the meeting has been achieved and people are free to go.


Who should you invite? Only you will know that, but if you’re not sure, make people optional and let them know, add a note to the bottom of the description:

(Bob, I’ve made you optional, you might have an opinion on this, but your attendance isn’t required. I’ll send around meeting notes and the achieved outcome afterwards either way).

Think about your attendee list and ensure you’re mindful of the fact that people are busy.

Attending a meeting

Hey, look at that! You’ve been invited to a meeting! Aren’t you the popular one! Your responsibility for being a good meeting attendee starts well before the meeting, in fact, it starts the moment you get the meeting request.

Responding to a meeting

So, you’ve been invited to a meeting. What should you do? Well, I’ll tell you what you shouldn’t do first, you shouldn’t hit “accept”, not yet anyway. How do you know you’ll get any value out of the meeting? How do you know you’ve not been the victim of a meeting muppet and just been invited willy nilly because they like the smell of your aftershave, or the way you wear your hat? You don’t, so, pay a little attention to the invite.

Ideally, the person booking the meeting has followed the details above, if they have, it will be fairly simple to decide whether or not to go, ask yourself the following questions:

Do I need to be there, or can I just send in some information by email.
Do I need to attend in person, or can I dial in remotely?
Is there someone else going who would be able to represent me?
If you’re not sure on anything, or the person booking the meeting hasn’t given an agenda or outcome, then you can reply to the meeting request and ask for more information before deciding on whether or not to go. If you think you should go, but require more information, then again, email – ask for clarification or further documentation! Don’t just go because you’ve been invited! It’s not rude to ask for more information.

The rule of thumb is, if you feel like you can provide no value, or if you will get no value from the meeting, then feel free to decline it. The onus is on the person booking the meeting to give you a compelling reason to come.

Finally, respond AS SOON AS YOU CAN. Declining a meeting five minutes before it’s due to start is, frankly, badly behaved.

Being a meeting attendee

You’ve decide to go. You’ve turned up on time, prepared, with a pen and everything, what now?

Stick to the agenda, pay attention, be present.

Remember, it’s not your meeting, you are there to help the person who booked the meeting achieve the outcome they need. If you feel like the agenda isn’t useful as you proceed through the meeting, then suggest you change it – but don’t hijack the meeting and don’t switch off. You are partly responsible for the successful outcome.

Other than that, being an attendee just requires you pay attention and get involved. If you’re in the meeting, you’ve already decided it has some value in you being there, so behave like that. There are a few guidelines that, while they shouldn’t need to be said, I’ll say anyone. Meeting etiquette is just about not being a dick:

  • Mobile phones: No, just … no. Leave it in your pocket on silent.
  • Laptops: maybe. If they’re needed for the meeting, or you’re taking notes, but ask the room “Does anyone mind if I take notes on my laptop?” This will both ensure everyone knows you’re not managing your fantasy football team in the meeting, but you’re taking notes and also means your notes could be shared with others.
  • Turn up on time. You said “yes” to the meeting. Be punctual, it shows respect. If you want to get a coffee, then get it in good time. Leaving your desk at 10:59 to get a coffee for an 11am meeting is a muppet move. If you’re going to be late, let them attendees know and an ETA of your arrival time, it allows others to potentially delay the meeting by a few minutes so you can fully take part.

After the meeting

If you don’t receive an email from the organiser, send one to all attendees, thanking them for their time and outlining the actions as you know them. People will appreciate the reminder.


Meeting etiquette is not rocket science. Be polite, thoughtful, courteous and respectful. These people are your peers, often your friends and always your colleagues. Treat them the way you would expect to be treated and you won’t go far wrong.

Got any other tips for meetings? Leave them in the comments below!

I’ve forgotten how to play guitar … again.

I’ve forgotten how to play guitar … again.

I’ve had a guitar since I was in my early teens (before that, a cello, which my mother had to walk to and from school with, because it was too big for me to carry). During my late teens and early 20s, I was pretty good at it – not band good, but I could make it do what I want and I enjoyed playing it. The trouble is, I’d stop playing for weeks, sometimes months and then forget my chords, notes and the songs I’d learned and have to re-learn everything.

This happened again recently – my son has started guitar lessons and this piqued my interest as I twanged away on his 3/4 size classical, so I got mine out, replaced the strings and … blanked. I’d forgotten most of the stuff (again). I can remember Knockin’ on Heavens door, but that’s about it.

I’ve had to relearn everything again and this got me thinking. It’s like a analogous  to most other things in my life, if I don’t do them regularly, I forgot how. Like playing board games, setting up symfony2 or running a retrospective. I have the idea that I can do it, as I have done it in the past, but the doing it eludes me until I’ve spent some time with it.

So, remember to practise things, even if it’s not daily – keep your hand in the game and work out your muscle memory. It’s a pain having to relearn everything (even if it does take less time), especially we you can be learning new stuff, instead of relearning old stuff.

In response to Forget Productivity by Jim Highsmith

In response to Forget Productivity by Jim Highsmith

(In response to Forget Productivity by Jim Highsmith and first posted as a comment to that article. I thought it worth repeating on my own blog.)

More of this “programmers are artists/crafters/code artisans — they should be treated like special snowflakes!” rhetoric — it drives me nuts!

I agree that writing code is an art and a craft. It is not like building a wall or working on a production line — it doesn’t have defined processes and actions like those.

However, posts like this ignore that simple fact that most business are in business to make money, in order to do that, businesses need to have *some* idea of when things will be delivered, or how much of a thing will be delivered by a certain date. This could be to support a marketing initiative, or because they need to order some hardware or other with a lead time that cannot be changed (and, having this hardware in inventory and not in use is waste), or simply because that’s the date that it needs to go to market.

So, let’s take the two metrics suggested as superior to “productivity” (whatever productivity is — is it story points?).

Value: Yes, let’s do the highest value items first. Let’s generate as much value as possible. “Which items are most valuable?” “How they hell should I know, we haven’t made or deployed it yet — we’ve done some focus groups and monitored our competitors, but we don’t really have a clear idea of which is the most valuable, so we’re guessing”. You’re just passing the whole “productivity” issue up the line, let someone else decide what we should build based on their own set of made up metrics and measurements.

Cycle time: Yes, this would be absolutely wonderful if we could measure everything by cycle time, but when you’re elbows deep in making a product, do you stop to care about how “big” (or whatever sized you use for a story) is to be able to compare it to other size stories to understand cycle time? (The premise being that, to gauge cycle time accurately, your work-items should be similarly sized) then you’re just back to estimating productivity again, surely? “Well, this is a small/8/dog sized story and we have usually done those end-to-end in a week/month/quarter, so expect this delivered around …”

There is no good answer to any of this. Forever more, we’re going to be working with unknown unknowns, sketchy, made up requirements and changing technical and business landscapes. I agree that wasting too much effort on measuring productivity is waste, but claiming you should measure in value or cycle time because it’s a better measure is misleading.

If I told you that a wall I have built previously was 14 bananas high and 82 bananas wide, you could probably build me a similar size wall. Whether it’s bananas, penguins, story points or inches, we’re only every using them relatively to gauge what might be based on what was — which is all estimating really is, no matter what method you use.

Confidential, not anonymous. Performance, not pay rise

Confidential, not anonymous. Performance, not pay rise

(First posted on Medium)

Peer performance reviews are broken, but if you must have them, read on.

Traditionally, peer reviews are anonymous. Reviewers are asked a bunch of questions and possibly asked to give a grading of a peer or colleague. I’ve never seen this work particularly well anywhere I’ve worked and there arecountless articles decrying their use. There are two fundamental reasons, I believe, that cause them to suck.

  • The purpose is unclear: why am I reviewing this person? How do I know my comments will be taken seriously and in the context I wrote them in?
  • Mistrust: how do I know the process is fair? Are my reviewers spending as much time as me? Do they know me enough to give a balanced review? Will this mean I get less of a pay rise? Is it worth my time?

These lead to two secondary problems:

  • Procrastination: everyone leaves doing their reviews until the last minute, this means they’re rushed, low quality and bland.
  • Closure: what happens to my comments? How do I know they made a difference? I am apathetic about this.

I dislike the anonymity of these kind of reviews chiefly because they do their part in fostering a culture that doesn’t value transparency, they make secrecy seem like it’s a behaviour that’s sanctioned by the company — secrecy shouldn’t be sanctioned — we demand openness, transparency and honesty — anonymity inhibits these behaviours during one of your most crucial activities.

What can we do about it?

Performance, not pay rise

This one is easy(ish).

Dan Pink talks about the three things people need for high performance are autonomy, mastery and purpose. Of the three, purpose is what is important in this context. Give your reviewers a reason to complete a review. The reasons, of course, are up to you — but what is key is that, to get the most of them, they should be unhitched from pay reviews. Peer and performance reviews are about helping the person being reviewed to improve in some way — either professionally (usually this is the case) or personally. Linking them to some kind of increase (or, decrease) in remuneration will kill the value of these reviews faster than video killed the radio star.

Do your peer/performance review cycle at a different cadence to pay reviews
It’s easiest to do them all at once, I know, but staggering them (even by a couple of weeks) will be useful in this context. In Work Rules! by Laszlo Bock, he states the Google have their pay review sessions a month after their performance reviews. This is enough time to decouple them in the minds of Google employees. He says that it reinforces the idea that they are separate to have the activities as separate in everyone’s calendar.

Make it obvious what they are for
When you send out whatever missive you choose to kick off a review cycle, make its purpose absolutely explicit and keep repeating this. In The Advantage by Patrick Lencioni, he says that, to get the message of what is important across to an entire company effectively, you need to repeat it and repeat it until and don’t stop, even if you think everyone gets it.

Follow up and close the feedback loop
This one is important and almost universally missed out.

As a conscientious reviewer, you spent time and effort on writing a good, balanced review of your peers, giving examples of behaviour and congratulations on a job well done. You hit the “send” button with a sense of a job well done and then … nothing.

What we’re missing is feedback for the reviewer. The whole process is (rightly) geared around the person being reviewed — we look to change behaviour through decent feedback to the person being reviewed and give them concrete reasons to improve, or continue down a certain path. There’s really no good reason why we can’t follow the same logic for the person doing the reviewing. Otherwise, they will only ever feel like their feedback is dropped into a black hole.

For example, let’s say that Bob was being reviewed, and he was informed that, while his work on the Acme project was excellent, his timekeeping could be improved so as not to keep his colleagues waiting around at the start of meetings. Bob discusses this with his manager and agrees that he’ll make sure he ends meetings five minutes early to be on time to the next one.

After the review process with his manager, Bob will pen a short email that is sent to his reviewers:

Dear Colleagues,

Many thanks for taking the time to give such honest and balanced feedback, I’m glad that my work on the Acme project was appreciated, I worked hard to make it a success.

I’m sorry that my poor-timekeeping is causing a problem for some of you, I wasn’t aware it was having such an impact — I’m in too many meetings! I’ve committed to leaving meetings five minutes earlier to make sure I’m on time — please bear with me while I do some rescheduling, as it may take a week or two to get into the new routine.



Without much more effort, Bob has closed the loop, for both himself as a means to thank his reviewers and apologise (if necessary) and also for his reviewers, they can see their feedback was taken seriously and acted upon.

Next time they’re asked to complete a review for someone, they’ll remember the feedback loop was closed and will try to provide good, constructive feedback that can be acted upon.

Confidential, not anonymous

Making reviews and reviewers public leaves many people quaking in their boots. Complete transparency is not for the faint of heart (but, it’s somewhere you should aspire to) and consequently, not something I would encourage jumping straight into for anyone with an already established process. What I would encourage though, is moving from anonymous to confidential.

The difference is important on many levels. But what does it mean?

Anonymous means that nobody knows the identity of the reviewer, neither the manager or the reviewer. Confidential, on the other hand requires that the reviewer’s name is known, but only to the manager of the person being reviewed. The benefits of a confidential review system outweigh any potential risk that may come with one.

For the reviewer
Removing the comforting blanket of anonymity means that anything written down, must now be carefully considered. If I know that the manager of the person I am reviewing will know what I’ve written, I can’t provide useless waffle, bland platitudes, backbiting or simple bullshit. The fact that my feedback can be sense-checked means my feedback will be more considered and, hopefully, of a higher quality, which will improve the process end-to-end. I also understand that, should my feedback require clarification, I’ll be asked, directly, to provide it. So, I feel some measure of shared responsibility for resolving any issues that I bring it.

For the manager
In the past, I’ve seen feedback that is useless. Sometimes it’s personal feedback (one employee has a personal problem with another), other times, it may not have an example accompanying it, on rare occasions, the feedback may border on gross misconduct, or a sensitive problem that cannot be dealt with in a normal peer performance review process. When the feedback is anonymous, it stops there. There’s not much I can do about it and adding it to the performance review brings little value.

If, as a manager, I were to know the author of the feedback for one of my employees, I could do something about it. I can understand both sides of the issue and, when it’s not anonymous, I can take remedial action that may otherwise be impossible. For example, a personal problem could be fixed by encouraging the parties to discuss it — “Pete is frequently short with me in our Thursday afternoon meetings and it bothers me, have I done something to upset him?” — Pete has a call scheduled with the unreliable service vendor before the Thursday meeting and he is often arguing with them on the phone (and only I know this). I can encourage Pete to reschedule his meeting and then spend some time with the feedback author to explain the situation and ensure them they’ve done nothing to upset them. Of course, I would know both sides and can discuss this potential outcome with the author of the feedback and see if they’re happy to sit with Pete to discuss it — this would expedite the resolution to closure much quicker than me saying “Pete, you’re grumpy in the Thursday meeting and someone thinks you’re upset with them”.

I can find clarity on any feedback that I don’t understand (“Sarah didn’t do a great job on that work for Bobs Books INC” — “What do you mean Sarah? What was the problem?”).

Finally, I can deal with much deeper problems sooner that I could with anonymous feedback. When feedback is anonymous, the remedial action is broad, when it is confidential and I can seek clarity from the author and the remedial action can be precise.

Obviously, any outcome to a more serious problem would be discussed with the author beforehand, to ensure they are comfortable with the process and that confidentiality remains.

For the person being reviewed
If I know that my reviewers are not hiding behind a shroud of anonymity, I know that any feedback will be considered and of a higher quality. I also know that because my manager knows who the feedback is from, I can assume it will be fair and balance and that my manager will do what is required to make it fair and balanced if it isn’t. In short, with it being confidential and not anonymous, I know it will be fair and I know it will be meaningful for me in helping to improve myself.


Most of us don’t have the luxury of running HR or People Ops for the companies we work for and, for the most part, or demands for a better system of performance reviews (or NO performance reviews) will fall on hard-of-hearing ears. However, small changes like these I propose will move us closer to a better, fairer way of reviewing our staff and actually make sure it is a meaningful process that provides value for everyone involved.

Ways and Means committee

Ways and Means committee

The inaugural meeting of the Ways and Means committee convened at ThoughtWorks Werkstatt Berlin on the 31st of March. This first event of the committed brought together tech industry people from all over Europe. Hosted and conceived by Dmytri Kleiner and Dino Frese from ThoughtWorks, the Ways and Means committee is a group that aims to help tech leaders share experiences, discuss problems and cultivate a network of a trusted peers with which to seek advise.

This meeting asked the question “Why do sprints fail and what can we do about it?”. We were not looking to solve the industrys problems in a single session, but really, to see what kind of things that, as tech leaders, are within our power to influence.

After an introduction presentation from Dennis Traub from ThoughtWorks and a conversation starter from Mike Pearce from, the session broke into groups to brainstorm just why sprints do fail. The teams jotted down ideas on post-it notes with no filtering, trying to capture the behaviours or conditions required for sprints to fail. Once that was done, we grouped similar post-its toeether and identified the following themes as being categorical causes of failing sprints:

  • Stakeholder expectation management
    • Some examples of these kind of issues were stakeholder patience, predictability issues, lack of transparency, bad requirements and stakeholder mandated solutions
  • Team Culture
    • Picking the “easy” bits of “agile”. The inspect and adapt loo is missing. People are “convinved” to commit to too much work.
  • Bugs and Fires
    • Business as usual will always be a fact of life, how do we deal with these kind of things without losing momentum on what really counts.
  • Process as ritual
    • When you decide what to do, you decide how you’re going to do it. But many become slaves to what is laid down as process – unquestioningly following it without really understanding why. The backlog becomes a theological debate, velocity is the only truth of progress etc.
  • Purpose/vision/Focus
    • Why do we do what we do? What is driving is to build these particular feature? Lack of understanding around what the purpose

Given we had three teams and limited time, we dot-voted on which were the themes that we’d most like to discuss further. These were “Stakeholder expecatation and management”, “Team Culture” and “Process as Ritual”. We agreed that our goal, like the original Agile Manifesto, was to come up with a set of principles that could guide a team when coming up against any of the above problems. As we weren’t able to solve for every issue that we had recorded (and frankly, wouldn’t be able to) principles were a better way of providing broad guidance for a multitude of sins without being too perscriptive.

So, after some lengthy debate, these were the principles that we created.

  • Stakeholder expectation management
    • Values and Metrics: Meet a business value over showing productivity.
    • Transparency and Dependencies: Transparency over commitment
    • Milestones and continuity: Goals over features
    • Goals and business value over showing productivity and finishing features.
  • Process as ritual
    • Question the process
    • Don’t be a backlog pack-rat (don’t keep every story for the sake of theology)
  • Team culture
    • Agile has to be cultural (not from a scrum manual)
    • Culture starts small. Build organically, infect and contage.
    • Hire to cultural fit
    • Teams should look at their own balance of culture, but needs to work bottom-up-top-down.

We closed the session with a mini-retrospective on how we should continue with the Ways and Means committee, the general consensus was that it should be a little longer, less warmup and more discussion and that we should communicate by way of a mailing list.