hello

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.

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.

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.

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”.

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.

I sometimes wonder whether people have actually even read the Agile manifesto. It is made of four core values and 12 principles, I won’t paste them all here, you can find them at the above link. Maybe the principles are hard to find, but you can read them here.

That’s all there is to it. Agile isn’t a “framework” or a “methodology”, if anything, it’s common sense. Common sense described in four values and 12 principles.

Agile is not a synonym for scrum, or kanban, or anything else. The term “Agile” shouldn’t be used as a description of an all encompassing set of practices that it doesn’t describe. For example, what does “Agile adoption” even mean in this context? Does it mean you’ve finally decided to use common sense? No, it means a company is adopting a framework or methodology that is inspired by the Agile manifestos values and principles, such as Scrum.

Agile is a mindset, a way of being. So please, stop posting things about how “Agile has failed”, or “Agile does damage” unless you actually mean that common sense has failed, or common sense has caused damage. Which is unlikely.

Remember, you don’t DO agile, you ARE agile, it’s a way of being, not something you do.

I gave a talk at LondonWeb a couple of weeks ago. It was a lot of fun. I tried to broadcast it with Google Hangout on Air, but the hotel wi-fi was rubbish. Luckily, @nathanlon recorded it too, so here it is:

and the slides:

Slides for ‘How big is it? A guide to agile estimation’

So, George Osborne today announced that, in exchange for between £2,000 and £50,000 of shares, employees can relinquish some of the rights they have as employees. These rights are; claiming unfair dismissal, redundancy, time-off for training and flexible working. There’s also an extra right to relinquish for women, which is to give 16 weeks, instead of 8, notice when returning from maternity leave.

Essentially, what Mr Osborne is saying is that you can either be a) ejected from the company with no recourse or b) imprisoned at your company with no way out for some figure between £2,000 and £50,000.

I understand that this comes down to a matter of ‘shared-ownership’, meaning that, now you have these shares, it’s up to you to do the very best you can to make the company a success, afterall, if the company is a success, you’ll do well too. I also understand that this is voluntary for existing employees, but could become compulsory for new employees, should an employer choose to do it that way.

What I don’t understand is how on earth he thinks this is a good idea? Claiming unfair dismissal is what protects employees from the pointy-haired bosses who surround them. Redundancy, unless political or strategic, would indicate a company not doing so well (so, who would want shares?). Training is important if you want to retain, improve and increase the value of your staff and flexible working? What on earth does he mean?

For some shares, you get to give up the ability to work from 9 – 5:30, every day in the same office? What a marvellous idea! Let’s ignore the fact that people don’t all march to the same drum – folks aren’t productive when you want them to be, they’re not creative when the clock showing a specific time. Let’s ignore the fact that people have children, families, teeth, health and the multitude of other things that mean working 9 – 5.30 is difficult and a dumb idea. Further, we should force people into thinking that spending time in a particular location, between particular hours is a measure of how well they’re working. Let’s completely ignore the fact that by focussing on WHEN we are, we cannot focus on WHAT we do. Business should focus on results, not hours.

This new proposal from the CHANCELLOR OF THE EXCHEQUER clearly shows that he has almost no idea how business works in the 21st century. Stop trying to apply old fashioned, often Taylorist views, on how you think businesses should be run and be forward-thinking, pragmatic and revolutionary in helping small- and medium-sized businesses achieve greatness.

I read a lot of blog posts, articles, papers and what-not on creating, maintaining and coaching teams. It’s the one thing that, for me, has no set formula. Each team is different, as they’re made from different individuals, each with their own set of morals, ethics and experiences that drive their behaviours. There is no ‘one-size-fits-all’ team guide, unfortunately.

So, what we’re left with is a miasma of different works, all decrying or promoting some way or other of how to form and maintain a team, how to help them become high-performing, how to retrospect, plan, work, play, love, eat, argue and play football together. None of them are right and, equally, none of them are really wrong. But the one thing I see frequently is suggestions, and often demands, that “if they don’t fit, you’re hiring wrong/replace them” and this is alarming.

The common theme I see is that, yes, there IS a formula for creating the winningest team and, if one of the members of the team you’re trying to engineer to stardom doesn’t fit your mould, then he’s out on his ear … hit the road jack, your awesome-coding-but-complete-lack-of-personal-skills ass is outta here!

Not everyone can be a rockstar, you need some roadies too.

Perhaps you know someone, or have someone in your team who doesn’t really have any great ideas, isn’t that keen on researching the latest javascript framework or building some wanky Hipstagram filter in Ruby, but who can build a data abstraction layer, fully unit tested in a day and always reviews your code and finds the one or two things you missed. Where would you be without this guy?

Or maybe there’s the guy who just REALLY enjoys honking about with MySQL queries, doesn’t really give a rats ass about what the business does, but cares deeply about the quality of his code and making his queries elegant and fast.

Some of you may know the guy who get’s a real kick out of cutting HTML all day, taking the photoshop files from your rockstar, sweater-vest wearing, macciato drinking, fixie-bike riding designer and making a cross browser compliant, responsive and even working in IE.

These guys may not be the fastest, or the bloggiest, or the githubbiest, they may not even really get on that well with agile estimation, sprinting or ‘stakeholders’, but they’re rock solid and dependable.

Everyone has a place, even if they’re wearing a christmas sweater in June, they’re part of your team. Find a place for them, or, better yet, let them find their own place and do what they do best, even if it doesn’t align with your idea, or the internets’ idea, of what a perfect team is.

They tune the guitars and your rockstars play ‘em. That’s what a real team is.

Some of us inherit teams. We don’t have the luxury of hand picking the people we want to have. Maybe there just isn’t enough in the budget to fill your team with rockstars. Software gets written outside of Silicon Valley too!

This, for me, is the real notion of building a team. Not chucking money at a bunch of rockstars, but taking what you have, or building on a small budget and creating a live band – you need rockstars AND roadies if you want to wow your audience.

So, I’ve been messing about with Behat recently to try some tests of our site. I was given the challenge of testing the ‘Refine By’ functionality of our directory search. I thought it would be easy (it turned out to be, but not until I’d wrapped my head around XPath). Anyway, the refine by options are just bits of text in a label, or even a span in a label:

<ul>
	<li><label><span>Refine Heading</span></label>
		<ul>
			<li><label>Refine criteria</label></li>
		</ul>
	</li>
</ul>

Not great HTML you’ll probably agree, but clicking on the ‘Refine Heading’ or ‘Refine Criteria’ shows and selects criteria with javascript. However, there isn’t an out-of-the-box assertion for this with Behat, so after some fumbling around, I made (most of (some help from General Grecki)) this:

/**
    * Click some text
    *
    * @When /^I click on the text "([^"]*)"$/
    */
    public function iClickOnTheText($text)
    {
        $session = $this->getSession();
        $element = $session->getPage()->find(
            'xpath',
            $session->getSelectorsHandler()->selectorToXpath('xpath', '*//*[text()="'. $text .'"]')
        );
        if (null === $element) {
            throw new \InvalidArgumentException(sprintf('Cannot find text: "%s"', $text));
        }

        $element->click();

    }

I receive about 2 emails a day and probably three or four calls a week from recruiters who have an old version of my CV in their hand. The version they have is usually very out of date (some context: the company I currently work for employed me as a senior developer, then I became an agile coach, now I’m head of development) and is from a previous development job I had.

My question is, should I update my CV and upload to Monster/Jobserve etc and respond to recruiters with it so at least they send me emails and call me about relevant jobs, or is that sending the wrong message to my company?

To be clear, I’m not looking for a new job, I’m looking to reduce the amount of irrelevant mail and phone calls I receive.

How often do you update your CV or your LinkedIN profile? Does updating either of these things send the wrong message? Even if it’s just for the sake of updating it?

A had a text from a friend tonight, “They’re talking about you on the BBC!”, I was momentarily excited until I got the link to the audio from the Radio4 Today programme this morning, talking about working from home, it’s here http://news.bbc.co.uk/.

Apparently, 250 members of staff from a firm in China who worked from home were 12% more productive than the other 250 who worked from the office. The programme cites they study called Does Working From Home Work? A Chinese Experiment (Bloom et al, 2012). While the today programmed states a 12% increase, the study says there was a 13% increase; 9.5% for more minutes per shift and 3.5% as an increase in the volume of calls made due to a quieter working environment. However, one the nine month trial was over, the company rolled out WFH to the entire company, not everyone took the opportunity, some chose to come to work, about half those who were in the randomly selected working from home group and two thirds of the control group, those who worked from the office, chose to stay in the office. Interestingly, productivity went up more and Bloom et al state that, working from home as a modern working practise, along with the employee having a choice in how they work (which harks of Dan Pinks Autonomy, Mastery and Purpose piece), as a combination are very beneficial to overall productivity.

The experiment wasn’t ROWE though, the was a heavy focus on the amount of hours worked. In order to get some good measurements, they required those WFH to work specific times (9-5) as well as those in the office. As it was a call centre, measuring was fairly straight forward; they measure number of calls, notifications sent, corrections etc. The team leaders still dictated when the employee had to be in work as the experiment was only for four out of five days, with the team leader deciding on the day the worker had to come into the office. So, pretty far removed from ROWE, but still some good data on what it means to work from home.

ROWE in this context would be fairly simple to implement given the straightforward way they gathered and reported on the metrics.

However, the bottom line is – working from home is more productive … for the right kind of people (low performers generally chose to work in the office), but how much the culture of the Chinese and their existing working practises affected this outcome is pause for thought too. Working from home requires discipline, so this is where a focus on the results and how they can be measured is the most important thing about ROWE. If you know what you need to do and you’re going to be measured, it’s much easier for you to do the thing, knowing that that’s all that counts.

A colleague sent me a link to an article on the MIT website, ‘Why Showing Your Face at Work Matters’ and, frankly, it has really got up my nose!

The basic premise of the article is that, if you want to do well at work or in your career, then you need to put in some passive face-time (their emphasis!). Passive face-time is describe as just being in the office, not necessarily in a meeting. They go further and quote remote workers who do some, frankly, ridiculous stuff in order to be noted as having virtual face-time (my emphasis), that is, sending emails in the middle of the night, replying instantly to emails so it doesn’t look like you’re sunbathing at home, making regular email or phone updates, being ‘extra visible’ in the office and, my favourite, getting others to talk you up by being in peoples faces and forcing people to remember you (probably as the annoying one who can’t keep their nose out … whatever).

This is ridiculous! Why are these people wasting time on doing things that aren’t getting them closer to their goals or the company objectives? Surely, this is the opposite of what they should be doing, which is working on valuable stuff, ensure their boss understands what they’re doing and how they’re going to measure it and get evaluated on that?

The article also goes further and states that research suggests that those in supervisory or line-management roles will evaluate people differently based on this idea of passive face-time, they won’t, however, realise they are doing it (K. D. Elsbach, D. M. Cable and J. W. Sherman, “How Passive ‘Face Time’ Affects Perceptions of Employees: Evidence of Spontaneous Trait Inference,” Human Relations 63, no. 6 (June 2010): 735-760.). This reminds of that ridiculous “truism” – “Perception is reality” and something that needs to be rooted out, dragged into the street and shot.

MIT have studied this for a decade and settled upon two types of passive face-time; expected and extracurricular and, whichever version you engage in, changes how people evaluate you. Those who put the expected business hours in are called ‘responsible’ and ‘dependable’ and those who put in the extra face-time are ‘committed’ and ‘dedicated’.  They conducted a few experiments on this (they were a bit flaky: getting people to read descriptions of workers, then evaluating them – these being workers they had never met or interacted with) and managed to turn their hypothesis into a theory, which is useful, but I’d like to see it backed up with WHY do supervisors do this and help them eliminate this harmful practise.

They sum up by saying:

“The bottom line is that employees should be wary of work arrangements that reduce their office face time, and supervisors should be wary of using trait-based performance measures, especially when evaluating remote workers.”

Which is what annoys me the most. It shouldn’t be for the employee to ‘be wary’ of having a more flexible way of working, it should be for the employee to enlighten their boss and say ‘Hey, measure me on WHAT I DO, not how often I am in the office/making a nuisance/sending emails.”. The onus is entirely on the bosses of the world to be proactive, take a holistic view of their department or team and think “How do we contribute to the success of this company?”, then build goals, objectives and visions around the answer to that question, then measure your employees on that. Then, supervisors wouldn’t need to be ‘wary’ of making trait-based evaluations, because they’ll have something tangible to measure.

Stop measuring perception and start measuring reality, it’s really the only metric worth pursuing.