Agile Lab - Training, Coaching and Consultancy Blog

Friday, 4 December 2009 at

Tackling the 3 Problems that Prevent Web Development Flow

I specialise in helping companies that develop websites. Part of that is giving them training and consultancy around using Lean and Agile methods, specially tailored and focused for the web.

One of the things I'm often asked about is how to improve estimates for projects. I think think a lot of the time, what this question really boils down to is: how do you get better control of the time that it takes to develop, deliver and get paid for a web development project? I think the answer is by making sure that you keep a close eye on those aspects of the web development process that are outside your control and may take FOREVER. Here are three problems you should really keep an eye on.

Problem: Late/Non-arrival of assets

This is the biggie. Many clients who commission web sites do not understand how much extra work is involved in preparing "assets" for the web. By assets, I mean any kind of content, written copy, graphics, images, sounds, video. The effort required in writing good copy for the web is especially underestimated.

Solution

Make it clear which content aspects of the website your client is responsible for producing. Make it clear that, in your experience, this is an aspect of web site production that affects timescales. If the issue is web copy, suggest that they hire (or you hire) a good web copywriter to produce the copy.

Problem: Lack of sign-off

Actually, this is another biggie. Actually it's two.
  • For the client mucking about with designs endlessly is (seemingly) much less risky than exposing it to the world.
  • In a lot of hierarchies, many, many people have the power to say no, very few people have the power to say yes.

Solution

Make it clear how much lack of sign-off costs. One way to do this is to take the costs of lack of sign-off out of the development budget! I have recently seen this work with termendously powerful effect with one of my clients. Another way is to offer discounts if sign-off happens within certain periods. Make it clear that quotes are valid and timescales can only be honoured if sign-off.

If they really do want to see hundreds of different designs, tinker with things endlessly. That's fine. But that needs to be on a time and materials basis.

Problem: Unavailability for Meetings and Feedback

Everybody's busy. Client's often express the wish that you would "just go away" and do the website. Unfortunately, quite often, what happens is the opposite - they "just go away". They stop responding to email and phone calls. This can be because they're very, very busy, but it can also because their business is changing in ways that mean that they won't need your website anymore.

Solution

This is an impossible situation and you have to make sure that your client understands this. If the client isn't available for meetings, or sends someone to meetings who is not really empowered to make decisions, make it clear to the client that the project is stalled and that no work is being done on it until they provide their input. Again, it's also very valuable to make clear how much this lack of contact is costing. Meetings with juniors who have no power to make decisions aren't free.

If they really are too busy. By far the best thing to is to sell them inidividual iterations. This provides them with the clean "Just Do It" experience that they seem to crave, whilst at the same time reducing risks for you. If you provide them with a working prototype at the end of every iteration, there's a much better chance that they'll come back for more.

I cover these problems, and their solutions in more detail in my course Building the Lean Web Development Team

If you liked this blog post you might like: "Six Things you Really Need to Know about your Customer" and "I'm your software developer, and I'm listening"


For further information, contact mark.stringer@gmail.com (07736 807 604)

Labels: , , ,

Monday, 30 March 2009 at

In the Pub after my Difficult Conversations Talk

I was talking to this guy in the pub after my talk on Thursday.

"I've been the MD of two or three technology companies and I thought I understood what software was all about. I thought I knew all about technology. Then, just recently I started writing some macros in Excel, and then I got into VBA - and I thought - how hard could this be? And then after a couple of weeks it was like wow! Some things you think are easy are really hard - they take you days and other things, once you've got the hang of it, they're really easy. But when I'm doing this stuff - you'd better not talk to me, I can't be answering my phone or reading email of any of that stuff, when I'm writing code I've got to CONCENTRATE.

"And then suddenly it struck me - all these things programmers had been saying to me all these years..."


For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , ,

Saturday, 28 March 2009 at

Experts Know what they're Capable of - Using Velocity and Yesterday's Weather

This is a reply that I gave to someone on the London Java Community mailing list who was asking about better ways to manage estimation of tasks and time. I thought it was worth reprinting it here.

Dear X,

One of the best ways of improving your abilities at estimating over the length of a Sprint is to use two concepts combined: velocity and yesterday's weather. These are actually some of the more tricky aspects of Agile to explain, but I'll have a go just now, really quickly.

Imagine that you're first sprint is a fortnight. And so, quite naturally you plan to do 10 days work in that week and sign up to do enough stories/tasks to fill those 10 days. At the end of the 10 days you count up how many stories that you have actually done. Surprise, surprise, some things took longer than you thought so you actually only managed to do the tasks that you estimated would take you 7 days.

Ok, important concept #1: Velocity - this figure, the number of days of estimated work that you actually delivered is called your velocity. You can think of it a bit like your power. You thought you could deliver 10 days work, but actually you can only deliver 7. Ouch that hurts doesn't it? But the pain is worth it because by understanding your velocity, you're on the way to being able to accurately estimate things in the future and actually deliver things when you say you're going to deliver them.

Ok, now important concept #2: Yesterday's Weather. For the next sprint of 10 days, you only sign up to stories/tasks that you estimate will take 7 days. Ouch - that hurts even more doesn't it? But what you're doing is using your experience of how good you are at estimating and feeding it back into the process. This of course doesn't meant that if you get through all those things by the end of Wednesday on the second week, you don't find some other stories to work on. What it does mean is that over the course of several iterations, you keep checking with yourself how good you are at estimating your own velocity.

This feature - knowing what you're capable of, being aware of what you can and can't do in a fixed period of time is a well-documented feature of experts and high-performing teams. This books is a fascinating account of how experts are different from beginners http://is.gd/pots


There are bunch of other psychological tricks that you can use to detach yourself from trying to get the number right for any particular job. One that I found very useful is to try to imagine what the absolute worst case scenario figure would be and what the minimum time would be and then take the geometric mean (http://en.wikipedia.org/wiki/Geometric_mean).

I got this idea from this brilliant book about estimation -
Guesstimation: http://tinyurl.com/cypdbg



There's a really good book that looks at all this velocity/yesterday's
weather stuff in close detail: Scrum and XP from the trenches. It
also deals with "focus factor" which is a big issues in actually
delivering on estimates.

http://tinyurl.com/c26p8p


You could also come on my next course:

http://www.nmk.co.uk/event/2009/3/12/reducing-risk-and-improving-results-agile


Regards,

Mark Stringer.

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , ,

Monday, 23 March 2009 at

Agile for Programme and Project Managers

A crucial part of the Agile approach is to “Start from where you are”. This one-day course won’t advocate the complete overthrow of any project management approach. Rather, through some teaching and a lot of hands-on case studies and activities, it seeks to add Agile techniques to the project manager’s existing repertoire.

What is Agile?

We give a brief outline of the Agile Project Management approach and how it differs from other more conventional approaches. We explain why an agile approach is a much better fit for many new media and software development projects.

Estimation

What can estimation do to help you? What can’t it do? Why do people feel so bad when they get their estimates wrong? We delve a little bit into the psychology of estimation. Then we explain how the Agile concept of velocity can help you and your team to improve estimates and provide the psychological detachment from estimates that is essential for good negotiation.

Negotiation

One of the major benefits of an agile project management approach is that it offers repeated opportunities for re-negotiation throughout the course of a project. But you can only take advantage of these opportunities if have appropriate negotiation skills and are willing to have difficult. We take you through the principles of negotiation that you need to get best deal for you and your customer at every stage of a project.

Risk Management

How can Agile help to reduce risk for you and your customer? We explain the Agile concepts of prioritisation and velocity. We show how these concepts work to ensure that your team is always working on the thing that is of most value to your customer and is within realistic budgets and time scales.

Getting buy-in

How can you persuade your senior management, your customers and your team that Agile can help deliver projects more effectively? How can you still get some of the benefits of Agile approaches even if those you work for and those you work with still insist on more conventional approaches to project management? We discuss strategies for introducing effective Agile methods into real-world workplaces.

This entry as pdf

For further information, contact Mark@agilelab.co.uk (07736 807 604)

Labels: , , , , , ,

Monday, 16 February 2009 at

Using a Geometric Mean to Estimate a Piece of Software Development

I've just been reading a fascinating book about estimation:



My friend Tim was telling me about a problem he'd been having when talking to a client about software estimates and I found myself recommending using a geometric mean, although, right there and then over a deep-fried breakfast, I couldn't remember the precise details - so I'm writing them down here.

A geometric mean is another way of trying to get an estimate, slightly more complicated than just guessing, but not that much more complicated. Say you're trying to guess how long it would take to do a website. First of all, guess the maximum that it would take - say 3 months. Now guess the absolute minimum that it would take - say 2 weeks. Now, before we do anything else, put these things in the same units - 60 (excluding weekends) days and 10 days respectively.

OK, here comes the maths part, rather than "splitting the difference" i.e. taking the arithmetic mean between the two numbers. The book that I've been reading suggest that you take the geometric mean which is:

a = √bc

In our example, that comes out at:

ab = 10 x 60 = 600

√600 = 24.5 days

Of course, the arithmetic mean of the two estimates is:

(10 + 60) / 2 = 35 days

I think using a geometric mean may very well be a good way of "loosening up" people's estimating abilities. And also getting them familiar with landscape of possible outcomes of a software development project. Very often, people are just stuck with one figure and start to react with near hysteria when that line in the sand is passed.

Running a few trial numbers through a spreadsheet, it seems that one of the advantages of a geometric mean might be that terrible pessimism only has a mild effect on the outcome. For example for an estimate where the best case is a fortnight (10 days) and the worst case is a year (200 days), the geometric mean is 45.

By getting customers to think of the worst case scenario - maybe by using "yesterday's weather" of software development projects that they've been involved in in the past and then getting them to imagine the best case scenario, you're detaching them from one single figure and forcing them to grapple, just a little bit with the space of possibilities.

For further information, contact Mark@agilelab.co.uk (07736 807 604) or Matt@agilelab.co.uk (07713 634 830)

Labels: , , ,

© Agile Lab, 2007-2009. All rights reserved.

sitemap

Powered by Blogger

Subscribe to Posts [Atom]