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.

Regards,

Bob

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.


So…

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.

Is it feedback, or signoff?

Keyboard Jumble by Lynn Friedman
Grubby sign off. Photo by lynnfriedman at Flickr

Many groups suffer from having too many levels of sign off: designers seek sign off on UI changes from the head of their department and, potentially, the studio manager. This is after UX have sought sign off from their functional head. After that, we need stakeholder sign off, product owner sign off, marketing, brand and communications sign off (to ensure the message is correct) and who knows who else will need to have a say?

“With all this signing off going on, how will we ever get the damn thing launched!?” said the frustrated team members.

Perhaps you’re conflating “sign off” with “feedback”. Ultimately, there is usually only one or two people who are accountable for the success or failure of the thing you’re working on. Pragmatically speaking, this would be the product owner. For the sake of argument, we can also extend this to key stakeholders too. It’s these people that give “sign off” on whether something is ready or not.

Everyone else is just giving feedback, which can be taken on board, or ignored, as the product owner and key stakeholders see fit. If it’s a decision between pixel perfect designs and getting it in front of customers, let the PO decide. If you’re one of these functional heads and you’ve employed people whose work you need to “sign off” before it sees the light of day, perhaps you’ve employed the wrong people?

As Roy Castle sang, “Delegations what you need.” (He didn’t, he sang “Dedication…” but, whatever). If you’re building websites, your mistake won’t be live long. The more time you spend in the cycle of sign off, the less time you spend with your product creating value for your users.

BDD: Starting With Quality

By Shannon Kringen @ flickr
Quality with a star and stuff

Quality isn’t defined by a lack of defects or bugs. You wouldn’t get a cup of barista coffee and exclaim, “This coffee is quality because it doesn’t have a problem with it.” (No bugs in my coffee). You can get a cup of coffee from a petrol station that doesn’t have any problems with it. It’ll be hot, wet and coffee flavoured – there are no defects with this coffee. So, where does this idea of the “quality” of something come from? It’s a subjective thing. A quality cup of coffee to me may not be the same quality cup of coffee to you. If you favour a black americano, your definition of quality is not going to involve a milky heart drawn into the top of it, which is how I like my coffee.

When we talk about the quality of a feature, the fact that it doesn’t have any defects is an implicit part of that quality, but it’s not where quality starts or stops. What makes the quality of a feature is whether or not it does what it’s supposed to do and whether it provides the amount of value to the user that they expect. Again, this is different depending on your context: what you application does, who it does it for and why.

Quality Assurance (QA) plays a fairly key role in any software development team. I know some schools of thought suggest that there shouldn’t be a QA role, and while this is probably the subject of a separate blog post, I feel that this is wrong. We have a QA in the team, just the same as we have a designer in the team. It’s a specialist role that requires certain skills I don’t expect engineers to necessarily have.

That said, I’ve always been troubled with the way that the QA role is executed in a team. Let’s suppose that we’ve got a scrum team that performs well. They commit to a given number of independent stories, work on them sequentially, so they finish the first story before starting the second and so on. Once the feature has been completed, the work of the QA starts in earnest (until that point, the QA will put together a test execution plan and a strategy for dealing with the tests during the sprint). They will begin exploratory testing and creating or updating automated tests. This is all well and good and will ensure that the feature meets the minimum, implied, level of quality. In most cases, it’s enough that it’s free of defects.

For me, this is where the problem lies. But how do we solve the problem?

We realised that actually, we never really discussed what quality meant to a particular story or sprint. We had made assumptions about the quality based on the content of the story and the acceptance criteria. As long as the story met those acceptance criteria and didn’t have any defects, we assumed we were done. In reality, we weren’t really thinking about what constitutes quality but just what constitutes the feature.

So we decided to start with quality. It made sense to talk about what we thought quality meant to any particular story before we talked about anything else. At the beginning of planning a story in sprint planning, we would spend some time discussing what quality meant to this feature. Using the example of a login screen, the story might be:

  • As a user,
  • I need to log in to the site,
  • to access all the features.

Before we chose to start with quality, we might discuss what the feature looked like, or we may already have a design for it. But then we’d just jump straight into the technical planning: how do we implement it, what code do we need, database schemas – that kind of thing. Instead, now we talk about the feature from a users’ point of view:

  • What happens if they get their password wrong?
  • How do they reset their password?
  • How long should the password be? Should it have characters?
  • What happens if a user doesn’t have an account, how should we direct them to sign up?
  • What kind of error messages do we want to show?
  • Etc.

This opened up a whole new discovery phase. Product Owners cannot think of everything when writing stories and this discovery allowed us to offer our insight into how the feature works, ask questions about how it should work and these are often based on technical knowledge of the platform that the Product Owner may not have. We began by adding these new requirements to the conditions of satisfaction, but they soon become long and arduous to check. So we looked for a better solution than acceptance criteria.

The solution we chose was to use a new tool. BDD (Behaviour Driven Development) is a method of functional testing which allows you to describe the functionality of a feature in a “scenario” file in plain english:

  • Given I am on the login page
    • When I enter ‘mikepearce’ into the username field
    • And I enter ‘butteryballs’ into the password field
    • And I click “login”
    • Then I should see my dashboard.

We can then use a BDD framework to run these scenarios against our web application. We use Behat as a framework and it works really well (apart from our problem of data fixtures…). It pretends it’s a browser (and, will use Firefox if it needs to work with javascript) and does what your user would do with your system. This allows us to have automated functional testing too. Awesome.

So, when we’re doing this extra discovery step, we record our findings as these step definitions, instead of acceptance criteria:

  • Given I am on the login page
    • When I enter ‘mikepearce’ into the username field
    • And I enter ‘wrongpassword’ into the password field
    • Then I should see the message ‘Sorry, your password is wrong’
    • And I should see the link ‘Did you forget your password?’

We slowly build up a specification file for this feature, which is mostly centred around the “happy path” and add edge cases or problem scenarios if we think of them. It’s important to note that we don’t expect to think of EVERYTHING in this session as we time box it to ten minutes and expect other features or ideas to emerge during the sprint.

Once we’ve finished, we’ve got a specification file that we can run against the web app with Behat. The first time we run it, it will fail, because the feature isn’t there – but this is good! This is Test Driven Development for the masses! As the team slowly builds the feature and keeps running the Behat tests against it, it will slowly become more and more green. If new things emerge during the sprint, we add extra steps to the scenario file. By the end of the sprint, all Behat tests will be green and we can have confidence that, not only is the feature defect-free, but it also does what the user expects it to and provides them value.

So, now we have a way of assuring that our software has quality. Not only do we have a slick set of automated functional tests, but we’ve also added a low-friction, low effort step of discovery that allows us to really understand AND define what quality means to us in the context of this feature for our product.

I’d encourage you to try this in your teams. Actually having Behat (or any other BDD framework) isn’t really a requirement to get started. You can start by just writing your scenario file as the first step of your team planning a story and storing it somewhere for future reference. The value is in the discussion you have to define the quality. The artefact you create is useful afterwards for checking that you meet those requirements. The added benefit is that it’s written in a language that anyone can read – from your team and product owner, to stakeholders and anyone else in the business who is interested to learn more about your product.

(The benefits of using BDD are outside the scope of this article for more than I’ve described, there are plenty of articles on the web to suit your style, language and infastructure and I would encourage you to learn more about it. Start with this presentation from Gojko Adzic and this from Dan North)

How to estimate, pitch for and charge for a project in an agency enviroment

When I talk about estimation and planning, people often ask me the above question. The styles of estimating I talk about are more frequently used in a non-agency environment, that is, somewhere maintaining a single, existing product, or creating one, for your own company from scratch instead of the agency method which delivers software per project, per client.

The problem

The problem with this kind of work is that of estimates. Typically, as an agency, you’ll be bidding or pitching to a client to get the work. The client will probably be soliciting bids from multiple agencies, so you need to either stand out from the crowd in some way, or be the cheapest (or, preferably, both).

The client will generally be looking for a fixed price too, this is so they can go back to whoever is commissioning the work and get funding, or raise a PO or whatever.

Sometimes you’ll be given a brief, which you might then turn into a functional and/or technical spec, which then goes to the client along with the quote, then there’s some to-ing and fro-ing, an agreement and then work commences and oh shit, we forgot to add the widget to the spec and oh crap we underestimated the amount of data we’d need to use and have to re-engineer to use mongodb.

So, with this in mind, how do you estimate, quote, pitch or bid when agile methods are so fluid and you have to work to a fixed cost? You know the least about how long a project will take and what is involved right at the beginning. Using the Cone of Uncertainty, you’ll be between 4x and 0.5x inaccurate with your estimate of an end date (eg: at the beginning of a project that you estimate takes a month, it could take between four months and two weeks)?

Some metrics

There’s a few metrics you’ll need in order to derive costs from estimates:

  • Day Rate: How much a team costs per day. This is only ever going to be a rule of thumb (as there are holiday, illness, training etc.). But you should make it as accurate as possible. This becomes a key metric in working out costs from estimates. You should make sure that your client understands that for the purposes of estimating and pitching, this is an accurate, but rough figure.
  • Best, worst and average velocity: these are important metrics. Your average velocity is simple, add all your sprint velocities together and divide by the number of sprints. You could make this more realistic by using a rolling four sprint velocity, this then takes into account changes in team size, tooling or process. However, for the purposes of estimating the cost of project up front, the average will do.
    The best and worst velocities are derived by taking an average of your three most successful sprints and the three least successful sprints. Why you need these will become clear later.
    Should you have multiple teams and you’re not sure which team will be working on your project, then take an average across all the teams.

If you don’t have this data, you have two options: guesstimate, or use the cone of uncertainty.

Honesty and transparency

The fundamental tenet in any of these below strategies is complete honesty and transparency with your client. You’ll also need to invest three or four days (maybe less, it will depend on how practiced you are at this process, it will become quicker) in your client, it might sound like a lot and there is a risk there might not be a contract at the end of it, but it is worth it. Once you’ve deeply involved your client in the process from the start, they’ll feel like they’ve already started the project and so it’s easy for them to transition to being a paying customer.

From the outset, you’ll need to explain that you do things a little differently to other agencies. Whatever framework you choose to use (scrum, kanban, etc), spend some time explaining to the client what it is, how it works and why you use it. If you’re a little stuck, here are some ideas

  • It gives you a realistic view of the progress and scope of the project.
  • It gives you, as the client and stakeholder, complete control over what features make it into the final product and which don’t.
  • It allows us to deploy features to live as soon as we’re ready to, meaning you can be getting value from our work and your product, even before we’ve finished it.
  • These early and frequent deployments allow you to test your assumptions about your own users and customers and, if necessary, change the features or product without additional cost.
  • You will be encouraged to be involved throughout the whole lifecycle of the project and can view each separate feature as soon as it’s finished to help guide and steer the project toward exactly what you want (which might not be what you originally asked for).

The best way to do this is to invite your client in for a half-day, high level training and workshop. Run some exercises to illustrate the key points and answer all their queries – this is a new thing for many companies who aren’t used to this kind of agile environment, so it’s definitely worth introducing your client to it if they haven’t experienced it before.

The next step is to create some artifacts. Once you have a brief in hand and have spent some time with your product team and analysts and have a really good understanding of the brief, the market, the competitors etc, invite the client in again in order to build a product backlog of user stories. Set the scene for them and explain that, unlike other agencies, you won’t write a functional spec, or a technical spec, because they’re a waste of time. What you will do is write user stories, which describe each feature from the users’ point of view and what value each of the stories will bring.

Labour the point too. Ensure your client *really* understands that you won’t be building ANYTHING that you can’t find the value for and WHY you take that stance. If a feature, or some functionality, has no value, then why would you build it?

Work quickly through the brief and your research and build a backlog of epics with your client. Don’t spend longer than an hour or two on this and, if you have somebody, get someone to facilitate the meeting so you don’t get bogged down in ANY technicalities, or discussions that are long or drawn out. Once you’ve got your list of epics, have the client order them – which are the highest priority things? What user/customer value do they want to deliver first? Don’t worry about dependencies right now, this is only rough.

Finally, break the highest priority epic into a few slightly smaller stories. This isn’t strictly necessary, but will help the client understand the process better. Again, this shouldn’t take longer than 30 mins.

The estimate and the pitch.

Now you’ve got your feature list of epics and some smaller stories for the highest priority, get some estimating done. I won’t cover it here, but you can read the article on white elephant estimating, or watch my presentation on agile estimation. Try and use the team that will actually be doing the work. If you haven’t got a team, or not sure which of your teams will be doing it, then pick engineers, designers and QAs from multiple teams – you’re only looking for roughly accurate figures. If it’s proving too difficult because of the epics, then break some into smaller stories – getting epics and stories sized well enough to estimate will become easier with practice.

Finally, you’re in a position to pitch, but how do you do it? It all depends on your clients requirements.

It’s very important that the client understands they have complete control over what goes into their product on a sprint-by-sprint basis. Explain that you expect them to be involved in the decision making about what goes into the product, the priority of the features to be added and the scope. So, once you’ve agreed on one of the below strategies and signed a contract, the success of the project will be partially down to their input.

Fixed deadline

If your client requires the project to be finished by a certain time, you can work towards that. It will be to your advantage to provide two estimates though, allowing the client to choose their own end goal:

All stories by the deadline

Estimate the number of teams or people required to deliver all the story points by teh date, then, based on a day rate, create a figure. Remember, to be accurate (but not specific), you’ll need to provide a range, so, using your best, worst and average velocity you can say to your client, “We ESTIMATE, it will take four months, but it could take up to five and half, but it could take three months, therefore, it will cost between £40,000 and £55,000”.

A valuable, shippable product by the deadline.

Do the same as above, but use a fixed sized team – you won’t be able to fit some stories in, but this is fine. Use the average, best, worst to show the client the stories you will definitely do, you will probably do, you might do and you won’t be able to do. This will reduce the scope of the project, but also the cost. Remind the client that what features make it into the product is based on their input.

Fixed cost

Working towards a fixed cost is quite rare, but does happen and it will likely mean that the client won’t be able to have all the features they’ve asked for. In order to work towards a fixed cost, you need to know it (obviously…). Once your client has offered this, you can use it to work out your strategy. It will be similar to working out a fixed deadline. You know how long you have to deliver the project based on the day rate (fixed cost / day rate = number of days). So, then you have a fixed deadline to work to and can use the average, worst, best strategy again to indicate what you can definitely achieve, what you can probably achieve and what you definitely won’t achieve.

Fixed scope

Finally, there is fixed scope. The client has to have everything they’ve asked for – in practice, during the project, this is rarely true once you start building and the early, regular releases helps steer the project.

Again, using your best, worst and average velocity, you can work out a range of how long it will take and then use your day rate to provide a figure.

Cost per iteration

(I wouldn’t suggest this method unless your client is particularly agreeable to trying new things, but, assuming you did the setup correctly I describe above, then they should be chomping at the bit to try this new, visible, transparent and honest method of commissioning software)

Pitch at a cost per iteration, instead of a day rate. You can give rough estimates on how much it will cost and these will become clearer after each iteration. Pitch for a minimum number of iterations after which your velocity will stabilize and you can be more accurate in the remaining length of the project. This is a fairly ambiguous method of pitching though, you’ll need to draw on the other strategies above to work out what features and functionality can be delivered, but if your client agrees to sign you for a minimum number of iterations, and you deliver what you agreed to, by this time, your estimates should be pretty accurate and your velocity very stable, allowing you to accurately cost any stories you haven’t managed to complete.

Using your average, best and worst velocity to predict a schedule
Using your average, best and worst velocity to predict a schedule

Honesty and transparency, again.

It’s worth reiterating here that you should be completely honest with your clients as to how complicated and amorphous quoting for a software project is. If you think your client can understand it, then break out the cone of uncertainty to explain that 40 years worth of data prove it to be true.

Explain that, being agile and adopting a framework to allow for short, deliverable cycles allowing for fast-feedback means that your company will very quickly start delivering visible value to them. It will also mean that they can control what that value is on an iteration-by-iteration basis. But, probably the best arrow in your quiver is to explain that, throughout the project, they can see the progress on an almost daily basis and adjust both what you deliver and how much they want to pay you should they need to.

If you deliver some valuable piece of software that causes them to change they way they think about their product, then they could pivot their entire offering and find more funding – and who is already in place to help them achieve that?

Hooray! We won the contract!

Congratulations! Now, don’t sit on your laurels. Remember the commitments you made to your clients during the pitch process and keep them involved through the project. Begin with release planning to decompose the epics into more usable stories and begin to uncover more of the project as you go, with milestones and deadlines if necessary. Keep your client informed, involved and in-the-loop and they’ll be happy when things change (and they will).

Boo, we didn’t win the contract.

Sorry, that sucks – but use it to learn a lesson. Find out why you didn’t win. If it’s just down to cost, then perhaps review your costs, or spend more time breaking down and estimating the stories to provide a more accurate figure next time.

Send out a survey to the client, asking them what they thought of the process and whether there is anything they’d change, or something they didn’t like. Gather as much data as possible, then spend some time retrospecting with your teams about how you can do it better next time.

My client doesn’t want to be that involved or isn’t interested in how we do it.

My advice here would be to not take on the business. If your client isn’t interested in being part of the process of building their product, then you are setting yourself up to fail. You’ll deliver a functional and technical spec detailing exactly what they want, you’ll deliver it and then find out that, while you delivered what they asked for, it isn’t what they wanted.

Finally

The old black box model of estimating and pitching for client work is difficult to manage, hard to sell and will bite you in the ass later down the line if you got it wrong at the start. By getting your client on board and understanding how you do things, and that they can and should be involved from the beginning to the end, you put yourself, your company, your team and, importantly, your client in a position to succeed.

Mad, Glad, Sad retrospectives

I help my first retrospective for a while recently (that’s not to say the team hasn’t been retrospecting, just that others have been doing it in my stead!) and the team wanted to do the Mad, Glad, Sad exercise.Image

Shockingly, I didn’t know it. Or at least, I didn’t think I did.

The exercise starts with everyone writing on three different coloured posts-its the things that made the mad, glad or sad during the sprint. We then stuck them all up on the whiteboard under an appropriate picture.

We all studied it for a while, but I couldn’t really work out what the difference was between mad and sad. The idea of a retrospective is that you inspect and adapt. Look at what you did, how you did it and change things if they need improving. The idea of mad and sad should be things that, affected us negatively that we want to change in future sprints.

But what is the difference? I asked the team. They didn’t know either.

So, we set about trying to decide what each thing meant. In many retrospectives in the past, we’ve realised that there are things that went wrong, didn’t work or just plain sucked that we could fix and there were things that can be classed as ‘Shit Happens’. Stuff that, while we might expend some effort in fixing them, are unlikely to occur anytime in the near future, so we draw a line under it and move on – there are always more pressing things to deal with.

So, using this idea, we renamed Sad to “Get stuff off my chest” and Mad to “I’m not going to take it ANYMORE”.

Image

This means, we can highlight things that annoyed, frustrated or saddened us, but that, realistically speaking, there isn’t a lot of value in dealing with and then the stuff that REALLY got under our skin and we have to deal with.

Once we’d renamed them, we then re-sorted the post-its we’d stuck under the two columns and found that, things we might have dealt with as a real problem and spent time working on, were no more than just people wanting to have a rant, and real problems might have been overlooked as they hadn’t been applied with enough gravity. Perhaps the team member feels that it’s just something bothering them and doesn’t want to make an issue of it.

We worked through all three columns and, during discussion, decided to move some from Sad to Mad and vice versa as we discussed the pros and cons of each. In the end, we had a good, solid list of things that ‘we’re not going to take ANYMORE’ which turned into a list of definite actions.

So, if you run this exercise with your team, check their and your assumptions about what Glad and Sad mean – you may be met with blank looks – and make sure you all have the same understanding to make a good exercise into a great one.

Ready, steady, ROWE!

Today, my department begins a trial of a new culture. It’s a new way of thinking about work. Alright, it’s not *new* but it is rare. Especially in the UK. The culture can be summed up with one sentence: ‘Employees are free to do what they want, when they want as long as they get the work done.

There will be a whole bunch of blog posts on this subject, so consider this one a bit of a summary of all the main points.

History

I’m talking about a Results-Only Work Environment, or ROWE for short. It started with Best Buy in the states. Two employees were tasked with making things better and they began with flexible working programs which quickly morphed into a Results-Oriented Work Environment, then settled on a Results-Only. They detail their journey in their book ‘Why work sucks and how to fix it‘. I devoured the book in one sitting and made copious notes and realised that this was what we needed.

The way business works now is outdated; why do we need to work between 9 and 5:30? Why do we need to go to one particular place to do it? It doesn’t matter if you’re a knowledge worker, or in sales, it’s the same thing: the focus should be on results, not when or where you are.

The trial

It’s not been easy getting this trial started. There are lots of questions around holiday allocation and remaining on the correct side of UK employment law and legislation. Essentially, we need to still allocate people the appropriate amount of holiday and then ensure that they remember to take it. This mostly covers the company, so if someone leaves on a bad note, they can’t claim to have not taken holiday, because, in ROWE, you take holiday whenever you need it, there’s no allocation really. Because employees get to choose when, where and how they work, the rules governing the Working Time Directive don’t count either. There’s no 48 hour waiver or whatever.

We’re starting with *almost* the exact ROWE for a three month trial, I say almost because we’ve made two concessions, which I detail in the guideposts below. After three months, if it’s still working, we’ll extend the trial. The idea is to see if vanilla ROWE as detailed in the book works in the UK. UK and US cultures are different and employment law and employee rights are also different, so we need to make sure it fits properly for us and our business. I’m 100% confident that this will work.

Freedom and culture

Ultimately, working in a ROWE is purely focussed on the results. But it gives employees absolute freedom to manage their lives they way they need to. We all have to work, there’s no way around that (unless you’re a millionaire playboy or whatever), so we should be free to fit that work into our lives as we see fit. You don’t need to take a half day holiday to visit the doctors, you don’t need to phone in sick unless you’re going to be letting someone down with a meeting or conversation and you don’t need to worry about where anyone is, you and your colleagues are available 24/7 by phone, voicemail, email, SMS, skype, irc, Google Hangout – lot’s of options!

ROWE isn’t an activity or an action, it’s a culture and a new one too. It’s about changing the attitudes people have towards work and challenging the long held beliefs that time plays an important role in measuring someones value (time is still relevant for deadlines and in some lines of work, but not in the web industry).

Productivity

I’m expecting to see productivity improvements too – I have no idea what they’ll be or in what format, but I’m sure they’ll be there. For one, I find I can get a lot of work done in the wee small hours, because I’m not being distracted and there’s nothing to procrastinate about when the kids and wife are in bed – so I can’t play PS3 or watch a movie, so I work and I can get more done in less time because I’m so focussed on what I’m doing.

The results

Our teams use Scrum to build our software, so we have a built in results measure. We’ll be looking at velocity for each team and the department as a whole, as well as defects, engagement and acceptance rate of stories (the percentage of story points accepted at the end of the sprint). On top of that, all the people in my team have individual goals and objectives; a mix of skills acquisition and platform or performance goals, so I can measure individuals as well as teams.

The Guideposts

ROWE is based on a set of principles called ‘Guideposts’ which enable the change of culture to happen with a purpose, the most contentious of which are ‘Unlimited Paid Holidays’ and ‘Every Meeting is Optional’. The holiday one is easy to cover in principle – it’s irrelevant how much holiday you take, or when/where you take it, as long as the work gets done. That said, we still need to make sure that we’re adhering UK legislation and in order to do that, we still need to allocate and record holiday taken. It’s a small price to pay for that much freedom though!

‘Every Meeting is Optional’ is also difficult for people new to the culture to get their heads round, it doesn’t mean ‘flip a coin to decide whether or not to go to a meeting’, it does mean, find out if you can get, or give value to the meeting, find out, or define (if it’s your meeting) the outcomes and then decide whether you need to be there in person, whether you can dial or Skype in, or whether you’re just required to give information which you can email to the organiser. As long as the work get’s done and you’re meeting the goals, objectives and targets set, it’s up to you whether you attend meetings and how you attend them.

The one concession we made to this guidepost was that, ALL meetings are optional, but pay particular attention to external client meetings or group-wide meetings. We’re only one department in one company doing a ROWE trial, we can’t expect others to change they way THEY work … just yet. It’s a small concession and, to be fair, will barely affect our department.

Metrics and the win condition

How do we know the trial is successful? If nothing changes. Like I said, we’re currently tracking:

  • Velocity: The average rolling department velocity over the last 4 sprints (and long term velocity, but this is less volatile and less useful)
  • Defect rates: how many defects are opened per two-week period and how long those defects stay open (as an aggregate and also by priority)
  • Acceptance rate: What percentage of story points is ‘accepted’ by the product owner at the end of the sprint.
  • Engagement: we’re using Murmur to track employee engagement with the company on many levels.

We’re also looking to measure the perception of the department from across the business.

The win condition will be if nothing changes. If none of the metrics change over the next three months, then the trial will be considered successful, the net benefits of ROWE will be over and above just the impact on those metrics. So, as long as nothing get’s worse, we’ve proved ROWE as a culture in the organisation.

On top of the team metrics, we’re also setting goals and objectives on an individual level – skills acquisition or just ‘stuff that needs doing’ for the platform, our tools or whatever. So, we can watch everything that’s happening and see if it’s making a difference.

Next?

Next I sit back and wait for a sprint or two and see what’s happening, I need to keep my eye on the metrics and the individual objectives, but really, it’s business as usual … or not, depends on how you look at it!

I’ll be blogging more as the trial progresses in the hope that others in the UK who are already in a ROWE, or those thinking about going ROWE can share their progress, problems, failures and successes.

Estimating stories quickly and efficiently with ‘The Rules’

An Old Timer by hiro008
ticktickticktickBING - An Old Timer by hiro008 on Flickr

Estimating a backlog should be easy, especially if your Product Owner has looked after it, knows how to write good stories that mean something to the developers and the business and is able to prioritize based on business value (or, customer delight!). However, estimation meetings, poker planning, planning two or whatever you call it, can often be painful events that descend into chaos, anarchy and heated debate. While these things are all fun, estimation should be fast and simple, afterall applying arbitrary numbers, whose only measure is relatively sized, to amorphous items of work can’t be rocket science, so why would you want to spend much time on it?

Trouble is, developers and engineers are paid to solve problems, that’s what they love to do, so they begin the moment the problem is presented! This is to be applauded, but doesn’t really nail what should be fast conversations about stories!

We’ve recently been coarse estimating the next releases’ worth of stories for each if our products, the backlogs for these products contain between eight and 38 stories, depending on the goal. When we started estimating these, it was clear that it was going to be painful, so I created ‘The Rules’ (to be clear, they’re guidelines, remember the Shu Ha Ri!):

  1. Reset the countdown timer to five minutes.
  2. Product Owner reads story and acceptance criteria.
  3. Team ask questions to clarify their understanding of the feature. No technical discussion.
  4. When no more questions, the team estimates.
  5. If estimates converge or there is consensus, GOTO 1 and start a new story.
  6. If no consensus, start more discussion. Technical discussion is OK here.
  7. When the conversation dries up, or the time ends, whichever is first, the team estimates again.
  8. If estimates converge or there is consensus, GOTO 1 and start a new story.
  9. If a consensus isn’t reached, reset the time for another five minutes.
  10. When the conversation dries up, or the time ends, whichever is first, the team estimates again.
  11. If a consensus still hasn’t been reached after 10 minutes, put a question mark next to the story and GOTO 1 and start a new story.
  12. Optionally: create a spike story to discover more information in order to estimate the difficult story.
This means that the team will never take more than 10minutes to estimate a story. Usually, I’ve found, that the first estimate, right after the PO reads the story and the team clarify their understanding, is enough and rarely do we need the time for the second timebox of five minutes.
Remember, these are just estimates, they can be revised later if necessary and, really, the important part of this meeting is the conversation to clarify the requirements and, thus, ensure that business value is met.

You don’t really want a faster horse!

French Officers watering horses
Horses, going slowly. Photo by The Library of Congress - http://flic.kr/p/a88fYb

Henry Ford is quoted as saying “If I’d asked my customers what they wanted, they would have asked for a faster horse!”. While this might be true, this is a short sighted view of product management.

Often, our customers will ask us for something they want, but they’ll frame it in the context of something they already have. This seems to them to be the right thing to do. It’s helping us out as the people who build their products, right? Kind of. If we were to take the view that customers always know what they want, then I suppose so. However, our customers will endeavour to give us a solution to the problem they have, instead of being clear about their problem and letting the problem solvers have at it instead.

If your customer says “I want to be able to send an email to all my users informing them of X,Y and Z.”, You’d think they what they wanted to do was send an email to customers about X, Y and Z. But is that what they really want?

If you probe a little deeper, by asking open questions, you might find a different answer:

“What is X, Y and Z?”, you ask.
“Well, it’s the new promotions we offer, we want to tell our users about them as they might not find them in the promotion list.” Replies your customer.
“How does the promotion list currently show them?” you probe.
“It’s ordered with the newest on top, but if our customers aren’t looking for promotions, they might miss them.”
“So, you need a way of highlighting your newest promotions?”
“Yeah, I guess so. But we’d like to be able to send them emails about other things as well, like changes to our terms, or new features.”
“OK, so am I right in saying you need some way of informing your customers of new features, promotions and other pertinent information?”
“Yes!”

Now you have the real problem, which turns out to have little to do with email and there are many ways to solve this kind of problem. It’s now a case of discussing these ideas further with the customer and the team in order to find the right solution … which might not be a complex email system.

So, if Henry Ford had asked his customers: “What do you want?” and they said “A faster horse!”, he might have asked, “What do you need a faster horse for?” and the answer might well have been, “Duhh! To go faster!” Which is the real requirement. One that he fulfilled quite well.

Originally published on Technorati.

The Definition of Ready

Well, I’ve only gone and got myself published on the Agile Journal! Here is what I had to say:—–

Ready 4
Are you ready? Image by Kevin Dooley on Flickr

Development teams use the idea of a definition of done (DoD) to decide when they think a user story is ready to be shown to the stakeholder for review. The DoD is like a bouncer or doorman, ticking technical criteria off on a list before the story is allowed in to party. The DoD is a powerful tool, and while its explicit value is obvious in ensuring the quality of a user story before review, its implicit value is equally, if not more, important. The DoD forms a contract between the development team and the product owner (PO). This contract not only ensures that stories meet a baseline of quality but it also creates a bond of trust. The PO knows that, with a DoD, he can trust the team to deliver a quality technical solution, and in agile software development, trust is key to your success. The acceptance criteria form a similar bond between the PO and the stakeholder or business. The criteria are designed to help a PO decide if a story meets the stakeholder’s requirements. It’s this list—defined in conjunction with the stakeholder—that creates trust on the stakeholder’s side. They know that their PO will deliver what they need, because it says so on the story. The DoD and the acceptance criteria combine to make a powerful ally for your team’s success. But both of these things require that the user story itself is sensibly written and defined and that the acceptance criteria aren’t some magical pie-in-the-sky, moon-on-a-stick list of ridiculous demands that would give a hostage negotiator nightmares! The PO can make use of a similar DoD called the definition of ready (DoR). This can be used for all the same reasons the DoD is used for the team. It’s useful if the Scrum team helps the PO come up with a DoR, help her define things about stories that make them easy to understand:

  • small enough to be manageable in a sprint
  • contain enough detail to estimate accurately and
  • create acceptance criteria that really help define “done.”

POs don’t just pluck an idea out of the air, write a user story, and drop it onto the backlog (we hope). Stories go through a process just like the software they drive does. The PO has a responsibility to the team to create user stories for them to estimate and, at some stage, work on, that aren’t badly defined or not thought through. Team members don’t want to have to do a bunch of the PO’s work in order for them do their own work and deliver value. To this end, a PO and the Scrum team might find the DoR useful. This is a contract that the PO has with the team in order to say “Before I put a story in front of you, I will have done everything I can do make it not suck.” Some examples of criteria on a DoR are:

  • Story contains actors, problem, and value
  • Story should fit in a sprint
  • Story should be appropriately documented (does it require wireframes? User-journeys?)
  • Value should be obvious, if not, it should be explicitly stated
  • Story should have reasonable conditions of satisfaction
  • Story should focus on problems, not solutions

Using the above example, we could ensure that the user story: Show users other products that they can buy before they checkout which begins life as a throwaway request from a stakeholder at an audio-visual online storecan be rewritten using the DoR as: As a customer, I would like to see products that I might like to buy at the same time as my television, hi-fi, or other product, so that I can be certain I have everything I need. Acceptance Criteria:

  • Show users products that other customers, purchasing the same products as this user has chosen, have bought also
  • Based on what the user has added to his basket, show him products that could potentially be used with it, e.g., if he has chosen a TV, then show him cables, TV stands, and Blu-Ray players
  • Show ratings and percentage of customers who ended up adding the additional products to their basket.

This shows the actor, problem, and value for the customer. The value for the business is implicit in that it will increase uplift. The story is appropriately documented with reasonable acceptance criteria, however it doesn’t tell the developers how it should be done technically. I’m a big fan of release planning meetings. These meetings include going over the team’s DoD to see if there are any changes team members want to make in conjunction with the PO or stakeholders before they start sprinting. This is an ideal time to create your DoR as well. In addition to the explicit value you get from having a contract between the Scrum team and the PO, the DoR also goes a long way to fostering trust (as long as the PO follows through) in the same way that the DoD and the acceptance criteria do. If you have a bad sprint, during the retrospective, you can review your DoD and your DoR. Did the story require more work before it went into the sprint backlog? The DoR provides a similar yardstick to that of the DoD when looking for root causes of failure. Try adding a DoR to your process, especially if you’re having trouble with your stories being difficult to estimate or work on. You’ll reap benefits immediately, building trust and creating stories that have real value.

Lower the pain threshold and you’re not waiting, you’re impeded.

Jenny by  jamesfischer on flickr
Jenny by jamesfischer on Flickr

Women, it is said, have a higher pain threshold than men. I saw evidence of this as I watched my wife give birth … twice. She went through something that I can’t even imagine having to endure. I’d have screamed ‘epidural!’ the moment the first contraction hit, but then I am known to be a bit of a wuss. My wife however, gritted her teeth and got on with it, I’ve never been more proud.

I’ve witnessed a similar thing with scrum teams. Some of the teams I coach have an extremely high pain threshold when it comes to dealing with impediments. It’s often been one or two days later that I’ve even heard about the impediment, let alone had a chance to deal with it. I suspect this might happen in other teams too and it’s worrisome; it may mean that the team doesn’t believe their SM will be able to remove the impediment (which would illustrate a trust issue and is the subject of another post), it might be a show of machismo to tough out the impediment themselves and resolve it without bothering anyone. This is an honourable motive, but chaps, this isn’t 12th century Japan, if you need help, you can, and should, ask for it. Understanding when you’re impeded and recognising the need to seek help is a more macho thing than flexing your muscles and baring your teeth, it also makes the ladies swoon*.

However, the most likely reason that people don’t raise the issue, is the team simply don’t see it as an impediment in the first place. In standups, or in just day-to-day team chat, the term “I’m waiting for…” crops up quite frequently, usually in reference to the design or operations team. This term is poisonous, it’s a pseudonym for “I’m impeded by…” and teams don’t recognise this is the case.

If you’re waiting for something to occur before you can do something else, you’re impeded by it and your best course of action, if you’re unable to un-impede it yourself, is to raise it to your SM (or your coach. ;)) and have them try and remove the block for you. Next time you catching yourself saying “I’m waiting for…” remember, you’re impeded.

Don’t tough it out, leave the high pain threshold stuff to the mothers of the world, they’re much better at it.

*Probably, I have no data for this, I made it up.