Category: estimation

Fixed price part 2, Fix it with agile!

August 4, 2009 by Mendelt Siebenga

In my previous fixed price article I looked at why fixed price is not only bad for suppliers but also for clients. I also argued that contrary to popular belief using big design up front methodologies will not solve these problems. Fixed price is difficult no matter what methodology you use. In this article I want to look at why fixed price is still popular with many clients. Then we'll look at what we need to do to be a bit more successful at fixed price and how agile methodologies can help us do this.

To look at why fixed price is popular with clients I'll start with a comment I got on my previous article. Sergey Pyatigorsckiy commented "As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it's spending money, at worst - wasting money. That is why real huge governmental projects are fixed priced: Nobody really cares."

I tend to agree to some extent. Clients often don't care about the project, they often just want the software and be done with it and for them the easiest way to get this is fixed price. So fixed price projects and clients that don't care seem to go together. In most cases clients do care about the outcome of the project. Clients have a problem they want to see solved. Or, more cynical, in larger organizations, clients want a big successful project to show their manager. Often clients don't realize that in order to improve chances of a successful outcome they should care about the project. Most clients have experience with processes like buying a new car, they specify what they want, recieve a time and cost estimate, wait a few days and get their car. Why should software be any different?

My Agile Team: On Time Estimates

February 23, 2009 by mattgrommes

Picture courtesy of John-Morgan on flickr

Welcome to the second installment of my new series, My Agile Team, where we're following my team's progress in getting more Agile and in moving from one project to multiple projects. Right now, we're still trying to put out fires and finish up the big project. We hope to start adding in things from our other projects in a couple more sprints.

The fires I mentioned are our term for the emergency stuff that pops up and has to be taken care of Now. This is usually things that customers will see; their bill being the most important. These seem to still pop up every couple of days so we have to drop our Sprint tasks and take care of them quick, fast, and in a hurry as my Dad says. It looks like we've probably stomped out the bulk of the underlying problems causing the most important fires so this coming week I'm hoping will be a little less crazy (of course now that I've said that, we're in trouble). Once we all have some distance on these issues my goal is to do a deep retrospective just on these issues that have come up since Go Live and see if we can root out anything we should have differently for next time.

One thing I'm struggling with right now is trying to get the Higher Ups to understand why we shouldn't use real time estimates on the stuff left on the big project. Read on for my thinking on this and how I'm trying to influence things.

My First Agile Project Part 11: A Tale of Two Dark Clouds

November 10, 2008 by mattgrommes

Picture courtesy of iowa_spirit_walker on flickr

And now, a story about physics. I'll get to programming in a second though, I promise. In 1900 Lord Kelvin (of the Kelvin temperature scale among many other things) spoke at the meeting of Royal Institute in London. There was a consensus at the time that physicists had succeeded in discovering almost everything knowable about the universe. Kelvin was one of the believers in this idea and also one of the most powerful and influential men in science. His speech at the Institute was on 2 'dark clouds' he saw on the horizon, 2 experimental results that didn't fit in with what they knew at the time. Since they thought they knew almost everything, Kelvin was confident that these clouds would be found out and moved past sooner rather than later. What he couldn't have known was that within the next decade, those 2 dark clouds would revolutionize not only physics but would literally lead to the invention of our modern world, including the computer you're reading this article on.

Read on for how this story relates to Agile projects. Although if you've been on a sufficiently large project, you can probably see the connection between things on the horizon that seem small and end up having a huge influence on your project. In this part of My First Agile Project I'll talk about a part of our project that seemed like a 'dark cloud' and ended up being a tornado tearing through our town.

Team Velocity: More than the sum of it's parts?

April 2, 2008 by cspag

With our move to our new company came a new way of working for our team. We used to be a tight knot team, all working the same long-term 3+ year enterprise project. Now we're working on equally engaging projects, but they are shorter term. Our "team" has been split into smaller teams of 3, 2 and even 1 person per project. We've also been working on distributed teams with our other offices around the country as well. As such, our velocities are for individuals, small teams and disjointed teams. It looks like this will be the modus operandi for the foreseeable future as well: Mix-n-match teams to put the right people on the right jobs for our clients. So, the question that has been occurring to me lately is, how do I get reliable velocities to adequately estimate bids for future work with our mix-n-match teams?

Estimating the learning curve

January 18, 2008 by cspag

Over the past two months, our development team has gone through a lot of changes...from joining a new company and setting up a new work environment to learning new technologies to serve our new clients. In general, we were a desktop-based shop that focused on the ESRI desktop stack. However, many of our new clients require web-based mapping applications. As such, our team is currently climbing a very steep learning curve to work with a new set of technologies in a new environment. More to the point, there are way more unknowns in what we're currently doing than we've ever dealt with in the past.

One of the issues this has raised for us is how valid our current user story estimates are. Right now, everything seems more complex because we are researching just about everything we're doing. Will the story points we assign to a user story today be valid in 6 months when our tasks become commonplace? Can we use our current velocity based on our learning curve to provide estimates for new work? We have lots of questions running through our heads right now and we're coming to grips with some of the answers.

Risk analysis in agile methods

December 21, 2007 by Artem Marchenko

Risk analysis in traditional software development projects is often performed for real only before getting the financing and actually starting work. After the project ends there are often the "lessons learned" sessions, which in case of a failure are called postmortems. During these pre-project and post-project risk analysis activities an attempt is being made to reduce the risks and maximize the probability of success. The recent addition to this collection of methods is the idea of a premortem that is a risks review that happens before the project start as if the projects has failed already. While all the pre- and post-project risk analysis techniques are indeed useful and can help organization to improve own practices, they only look at the potential problems at only two moments of time. Therefore there is always a danger of missing the important factors that either did not exist at the point of analysis or team members did not have enough information about those.

How to use agile methods for the fixed price contracts

November 30, 2007 by Artem Marchenko

Agile software development methodologies discourage the use of the fixed price contracts. When forced to commit to the fixed price, agile approaches advocate unfixing the project scope. However, even if it is impossible, there are still ways to realize the benefits of agile methods.

Poorly predictable complexities

Sydney opera house, a beautiful piece of art, the Sydney's best known landmark and international symbol was started as a fixed-price, fixed-date project. Unfortunately, since it was no standard building time, it was impossible to estimate all the difficulties and complexities in advance. As a result, it took 13 years and 102 million Australian dollars to build instead of 3 year and 7 million estimated - 330% time overrun and 1350% costs overrun!