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.

Practise, just that.

Wikipedia sez:

A best practice is a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark. In addition, a “best” practice can evolve to become better as improvements are discovered. Best practice is considered by some as a business buzzword, used to describe the process of developing and following a standard way of doing things that multiple organizations can use.

This is my problem with ‘best practise’ – why is it called that? If it’s the ‘best’ way of doing things, why isn’t it just ‘practise’? Why do we have ‘good’ practise and ‘best’ practise? Would you use ‘good’ practise? Probably not, especially if there’s a better way of doing it, which is ‘best’ practise. So, if you’re only ever going to do ‘best’ practise, then it becomes ‘practise’, right? Then, if it’s just ‘practise’ then you wouldn’t refer to it that way, would you?

“How do you do stuff?”
“Oh, you know, with practise.”

I guess you can have ‘bad practise’, but then, that implies the opposite is ‘good practise’, which we just agreed you can’t have, didn’t we? Moreover, ‘developing and following a standard way of doing things that multiple organizations can use’  is silly, why would you do things the way other companies do things? This would just squash any chance of innovation; ‘That’s not best practise! Other companies aren’t doing that!’ dumb, dumb, dumb.

Let’s stop worrying about ‘best practise’ and just get on and make the way we do things better through regular reflection.

Today, I received the following email:

What is this I don't even?

I had to read it several times before I understand that I could either ignore it and the transfer would happen, or click on the link and the transfer would happen. 

So, I want it to happen quickly, so I clicked on the link and saw this:

CAN HAZ RADIOBTTN?

I had two checkboxes to check and, yes, I could check them both. I didn’t, however, I only checked the one I needed.

These guys must do a lot of business, why is their system so clunky and, well, shit?

• Added a ‘simple’ view to the site, this means you get to see everything in an easier fashion for editing etc. There’s still edit-in-place, it’s just easier than scrolling through the cards. You can still use the ‘card’ view, which you’ll need if you want to print the cards.
• Tidied up some style issues with the card view, so it’s a bit neater now.
• Added a newsletter signup, so you can be kept up to date with the things I’ve added.
• A few bugs fixed.

Check it out at http://storyprinter.mikepearce.net/ and please let me know if there are any new features you’d like to see.

Feedback comes from these - image by mpeterke

Part of my new role is to review and appraise the team. Given that there are a lot of them and I can’t spend enough time with each of them (and nor would I want to) to be able to do a good review, I figured that I’d have them do 360 reviews. There are multiple ways to do this, which I outline below, but I didn’t pick one for my team, I let them vote (I also let them post any new review methods they knew of in order they could vote for those too) – can you guess which they voted for?

Traditional

The traditional approach is an anonymous review: I pick several people to review the employee, they craft and submit reviews and then I deliver this feedback to the reviewee.

This sucks on multiple levels:

• Suppose the reviewee disagrees with some of the feedback, how can they offer a rebuttal? To me? How does that help?
• What happens if they don’t understand the context of the feedback?
• What happens if, in the name of keeping the feedback anonymous, I remix the feedback and lose the actual message (but I don’t know I’ve done that)?
• We work in tight scrum teams, this means that the BEST people to offer feedback, are the other people on the team (also the product owner and potentially stakeholders, but we’ll come to that), this means that, after the review, the employee goes back to their desk, possibly seething or feeling dejected, put upon or just miserable because of the above but they KNOW that someone in their team gave them shitty feedback.
• Sucks, right?

So, another option is to have the reviewee choose the people they want to review them. No. This also sucks:

• They might pick people who don’t really have much to do with the and would offer a good, although bland, feedback.
• Again, they have no chance of rebuttal or dialogue there and then to discuss context of the feedback unless …
• …they go back to their desk knowing that one of their team gave them shitty feedback and now aren’t sure how to broach the subject.

This doesn’t suck because:

• Same as the above.

Team 360

The whole team goes to the pub (or cafe, whatever) and they take it turns to offer feedback on each other. Starting with me as a warmup so they don’t feel shy when it’s there turn (this is great for me, I’ll get LOADS of feedback). You go round the table one at a time and everyone on the team feeds back to me – positive and negative – and write it all down. Then someone else volunteers and so on until everyone has had a go.

Developers drinking...

You need trust in the team for this and a good bond. This isn’t going to work with a new (or a ‘forming’) team and I’d advise something different (not the above, maybe just one-to-one coaching until the team are up to cruising altitude). But for established teams, or those stuck in a retrospective rut, I think this is a great idea.

I’ve run one trial of this method before putting it out to vote and the team had some positive feedback on the process (and each other!). It’s tough to do, but giving and receiving feedback is always tough, and the idea of doing it face-to-face with people you work with every day is challenging, but you should do it. Nut up and prove to your peers that you’re a grown up and can and need to learn something about yourself that you didn’t know before. This is about improving yourself in ways you didn’t know you could improve and making sure you’re not annoying your team.

This idea isn’t new, although I wish I’d thought of it, I originally read it in Management 3.0 by Jurgen Appello (the book is good, as are his talks, but his slides suck – well, he does draw them with MS Paint…)

What about … ?

Well, I mentioned product owners and stakeholders above. I’m undecided yet (but, I’ll probably let the team decide) on whether to include product owners in a team 360. They do spend a lot of time with the time and can probably offer some good feedback – it does depend on the relationship with the PO. Even though we don’t foster the feeling (and, Affiliate Window isn’t alone in this I’m sure) there’s a little ‘them’ and ‘us’ between the developers and the product team – but maybe this is a good start in breaking down that status quo.

Also, for stakeholders, having those in the team 360 would be pointless – they don’t have day-to-day dealings with the team, mostly it’s just input and output with the odd nudge in between, but we need their input. This is what the release retrospective is for but I’ll cover that in another post!

Edit: Stupid WordPress Y U NO EMbED GOOGLE DOC?

To see it, please go here: http://bit.ly/zs3ptD

This is not my cake - image by notanyron

My loyal readers. I’m very, very sorry. I’ve totally neglected you of late (it’s been a month since my last post). A lot has happened in this time. Not including Christmas and New Year, some things have changed which have taken up large chunks of my time: I’m no longer an agile coach, I’ve been promoted to a Head of Development.

This is a great move for me, I’m doing much the same role, but I have bigger teeth and can affect greater positive change for the people in my teams. I already have good relationships with the people in my department and I spent my days coaching and teaching and nudging the guys into improving one way or another. Now, however, I have the ability to do it officially and sanction their individual and team growth in ways I couldn’t before (mostly because I don’t have to ask before I spend money… )

I want them to tell me how this department should function and I’ll make it happen. Already we’re pushing each other to create and achieve short-term goals for improvement and, while the rest of the company is having an appraisal and Personal Development Plan rolled upon them, I’m letting my team decide how they would like to be appraised themselves.

It’s an exciting time and I’m hoping that, with the department in charge of it’s own destiny, we can create some exceptional software, improve and grow quickly as both teams and individuals and, above all, delight our clients.

What does this mean for the blog? Nothing much, I still intend to blog about agile and frameworks, but you’ll probably see more management stuff, training, goals that kind of thing as it becomes more a part of my role. We’re also looking for a scrum master to head up a couple of the teams, so, if you’re looking for a permanent position as a new scrum master, then let me know. I’m looking for someone with a little experience, but who needs more and wants to learn.

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.

Where I am right now, we manage our product backlogs using Google Docs. This works for us as it allows for flexibility when prioritising, we can move from room to room and, means we don’t have a large, messy surface of stories (although, I’m convinced this would help us – watch this space). One thing we do suffer from, is the transition of these stories stored digitally, to stories stored on a sprint backlog physically. Writing the stories by hand does mean there are sometimes further conversations around the stories, which is no bad thing, but it also means that often detail is missed from the cards, which causes problems later. This is due to the stories being written in a shortened form and, unfortunately often, a complete lack of acceptance criteria.

So, because of this, I put on my developers hat and created the Story Printer. This is a simple web-app, which allows you to upload a .CSV file and have it turned into printable story cards. At the moment, it’s very simple, but I’ve a few extra things on the roadmap which will add more useful features. But, for now, it does what it says on the tin.

Using the Story Printer, we now have a sprint backlog, with story cards that are identical to the stories in the backlog. Time will tell whether this prototype will prove useful.

Feel free to use it yourself and please contact me with new features, bugs or other stuff. I’d love to know if you use it, or would find it useful with additional features.

The Story Printer

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.