Tuesday, December 02, 2008

Does agile add costs?

Another interesting question that popped out during my “Agile: the B-Plan” presentation at IAD2008 regarded the different cost schema of an agile process, compared with a traditional one. Somebody asked “How can I sell an agile process, given that I need some kind of presence on the customer site, and this will trigger extra costs for travel and hotel expenses?”. This sounded like “if you want an agile process, it will cost more”. Strong objections arose: “This is not truly agile”, which is true, just adding a communication channel towards the customer doesn’t make you agile. But I think the problem is a little deeper than that. I’ll try to elaborate.

Selling the process
Does it make sense to sell your development process? I think it doesn’t. As software companies, we are expected to sell results, not the way we use to achieve them. Agile is better to achieve results? Great, this is our business.

Unfortunately the last statement is not entirely true: agile does not work without customer collaboration in place. So the customer must be aware somehow that starting an agile project involves some commitment (dedicated time from key resources) from the organization. Not all the organizations are equally ready for this type of engagement, so you might find yourself desperately looking for some type of feedback, and this feedback might be arriving only close to the deadline. Ouch, we’re back to waterfall.

The myth of the on-site customer
XP approaches the customer collaboration problem introducing the on-site customer role. Well, in practice this is not likely to happen, for dozens of reasons. So a negotiation phase is necessary, to establish a communication channel with the customer, as well as a tuning phase to ensure results are good. This is an area were simply “playing by the book” will lead you nowhere: you’ll need to understand why you need this type of communication, how can you achieve that, and which are the shortcomings and risks of the agreed trade off. And both sides must be aware of that. Scrum places much of this responsibility on the Product Owner. The efficiency of the communication channel between the team and the PO is critical to project success.

Frequent feedback loops are necessary to both sides. The team needs feedback to know they’re developing the right thing. And the customer needs to see how the things are going, to reduce project risks. Risk management is probably one of the most powerful key words if you still want to sell an agile process. But I think talking of risk management sounds better to the management’s ears.

Project specific cost schemas
However, there are no dogmas, even in this area. A face-to-face communication with the customer, is a lot more efficient. But it does have a price. Sending 2 people to the customer offices for a day or a week has a cost, which is a lot depending on the project specific constraints. In Italy, hotel prices went up in the last years, while IT salaries went down. Traveling to other countries might be really expensive. In some circumstances, the cost of knowing that I am doing the right thing might be higher than the cost of “learning-by-mistakes” (but remember: there are some vicious hidden costs on this side, to consider). Unfortunately, almost always it takes the right person in the right place to understand exactly what we are missing. So the only way to know if we can safely reduce some costs by having a less efficient communication channel towards the customer, is to have an efficient communication channel towards the customer. Otherwise we won’t know what we’re actually missing.

Getting back to the title question: I think agile processes have a different cost schema (you save a lot in printed paper and pay more in post-it... ), but are generally more efficient overall even in fixed-scope, fixed-costs projects.

4 comments:

Teamwork's Blog said...

Dear Brando,
You are talking about agility taking a narrow perspective on the software development world: that of custom development for a customer. But (fortunately) most (and more and more) of development is done for software products, where the customer is.. the software house itself.
But the function where you simply replace the customer with yourself, does not remain the same function; you are your own customer in a very particular sense, and values, worth and procedures are different. Selling the process is not an option, but here too the process is not worth anything.
In this perspective, it would be hard to consider agility a cost, as quality is not a luxury. Could you comment on this different perspective?

Alberto Brandolini said...

Hi Pietro,

You're right. This is a narrow perspective, is the one that emerged during the discussion @IAD2008, but here some of the context is missing.

I've come to the conclusion that "the definition of customer" is one of the key ingredients for a successful software project. It's never a single person that knows everything you need and is always happy to talk to you.

Moreover, stakeholders, customers and users can be pretty distinct concepts and roles in your project.

Sometimes the customer is an organization. Sometimes the market is larger, targeting more organization, with custom versions. Some other times you want a "flat" product targeted to million of users, some other times your product is so generic that you don't know how it's going to be used by users/customers.

The more the customer/user role is fragmented, the more you need a customer's voice collector role within your company. Managing the communication channel towards the mass of users and customers is one of the key activity of the Product Owner, in such a scenario.

In such a scenario agility is not a cost (and probably never is). It's requirement to be able to manage the stream of customer requests.

Teamwork's Blog said...

Interesting: the customer is what feeds issues, requests and bugs feedback to the project, whatever the source: this way you unify custom projects and schrink-wrapped ones, at least in some way, say when you are defining a general methodology. From a commercial point of view, unification is much harder, if not impossible, but that is another story.

A nice tool that we introduced (in Teamwork's site) for collecting "user voices" (you were probably thinking of a human collector, which in the end is necessary): uservoice.com, free and really well done. In a product there are many ways to maximize probability of getting feedback, this is only one of several. Cheers,
Pietro

Alberto Brandolini said...

In Scrum terminology, the Product Owner is the only role that can assign priorities to backlog items. The team must deal with only one PO, in the scenario you mentioned this might involve a lot of data collecting operations (bugs, incidents log, e-mail, etc.).Tools might come in handy to track all of this stuff, but a smart human is necessary to prioritize and negotiate with the team.