How long until a team can “become” agile on the job? [closed]

Question

Last year I led a project for a research institute. Requirements had been in progress over the entire project, and I had lot of trouble when planning, budgeting and providing other estimates.

Now, in 2011, the customer is asking for a fixed price offering to evolve the delivered system. Again, requirements are so undefined that in the first phase I'm planning a two months or so analysis task to just DEFINE requirements.

After some thought, I'm almost convinced that an agile approach would be the answer to satisfy such a customer (and not to have yet another painful year ;)). My questions are:

1. Do you agree that an Agile approach would help?
2. With neither the team, nor the PM, having experience with Agile processes, is it to risky to try to switch at this point?
3. Assuming we will be self training, how long would it take us to successfully switch to a more Agile approach?

I understand these are not easy questions to answer. Thanks

Answer 1

1. Actually, contrary to others, I think agile might be a good answer here. Having said that I consider you sign some kind of agile contract with the customer, which means they can terminate contract after each sprint. Of course that's not so easy to negotiate this kind of contracts - you can find Paul Klipp's presentation on selling agile very useful if you want to go this way (there are slides too).

   Classic fixed-price contract with vague requirements should raise red flags, as DaveParillo points so I'd focus either on well-defined specs or convincing the client to switch to the contract which limits risks for both side in this situation.

   Using agile approach within the project team is another story which isn't connected so tightly with the contract form. You can employ agile approach in a project which is under fixed-price terms and it can work pretty well. If the client is ready to take their part of the process, e.g. product demos after each sprint or repeatedly prioritizing features, it probably is a good idea. So my answer to a question 1 is: yes, agile may help you.

2. Transition to agile with no member having experience in agile will likely be hard. A reasonable minimum is someone who has experience from different projects and different organization so they know what can work and what won't work. Also the team should be very open for learning and improving themselves over time.

   Of course it would be much better if you were able to find a coach who would help you with kick start. Otherwise it is possible that you're going to visit some dead ends before finding a way which works well for your team.

3. There is no easy general answer how long it takes to switch to a new method, no matter whether agile or not. It vastly depends on people, situation, project, deadlines etc. I can give you an example when we were switching to Kanban - approach which neither of us had known from practice before. It took about half a year to reach the point where we were pretty fluent with the way we worked, however it wasn't a single point of time - we saw first improvements after just a few weeks from the start. We had a person experienced with different approaches and the team was willing to learn and adapt. It's really hard to answer exactly but I think somewhere between month and two months we were doing better than before the change.

Answer 2

Agile is not the answer. Try rolling-wave planning with ample reserves in the contract.

Don't let them talk you into a fixed price without giving yourself sufficient resources to accommodate the iterations necessary to get better definition of the project. Research is full of unknowns.

This post, and the comments, might be helpful.

Answer 3

You are planning to commit to a fixed price contract to "evolve" something with little or no requirements stability? Fixed price + uncertain requirements are a bad combination. This should be a danger sign and no, agile is not some silver bullet that is going to magically make this problem easier for you in 2011. The whole project is risky - adding a commitment to "switch to agile" doesn't make it much worse than it already is. Sorry.

Not sure what your customer expectations are, but take a look at the Agile Manifesto. If you think that your future project might benefit by shifting focus from the items on the right, to the items on the left, perhaps some agile practices can help you.

From your question, it sounds as if no one on the project team has any experience with agile development and you don't plan to pay for training. Another danger sign. You need at least coach or a mentor - a person who really understands the process model you are trying to implement. If you send one of your own people to get this kind of training, you have the advantage of having a mentor with excellent understanding of your organizations needs and constraints. You may still benefit from outside consultants as home-grown mentors can have less objectivity than a consultant.

Rather than switching to agile (or not) because it someone on this page says you should (or not), I suggest you examine closely the problems you experienced last year and create strategies to eliminate or minimize them. For example:

1. How was planning, budgeting and providing other estimates troublesome?
2. Did the project deliver on time and on budget? Did you have a budget?
3. Can you say that you know exactly how many hours of effort it took to accomplish the project?
4. Do you know exactly how many requirements you started with and how many you ended up with?
5. How many requirements were implemented? How many deferred?

Consider a reflection workshop or a retrospective. Do this regardless of whether you accept your fixed price job or not. Sounds like you have something to learn from a past project that was harder on the team than you would have liked.

Answer 4

I think it can depend on the project. Agile works extremely well when you can start delivering incrementally - and to be fair that could even be your requirements documents.

What I would suggest is don't just try to "be agile" - make sure you start off with a tried and tested approach such as scrum when you are starting out and inexperienced. We started trying to be agile initial and got in a right mess until we took a step back and implemented a proper framework. You can always adapt it to your needs as time goes on.

Answer 5

thanks all for the feedback
Fixed price is an administrative must for the customer and we are already pushing to the highest price possible, to keep higher the margin for the unknown.
The problem is the expectations coming from the customer that too often last year were ever changing. In my idea adopting Agile would mean "force" the customer to focus on the iterations and on what we will release at each one, keep track on the backlog and adjust priority depending on their feedback. In this way I think/hope I can achieve to keep the customer expectations more adherent to the project scope limiting their researchers approach that tend to make the project so risky.
Indeed there is a big politics issue under the cover here, because the customer wants research, but the project will produce a portal of services for the citizens in behalf of the government.
I cannot drive politics, but I need a way to keep the project under control

Answer 6

In my opinion, agile methods change the relation you have with your customers when you are a IT service provider. Pricing and billing can become kind of a problem.

I think a solution is to proceed by bundles. I think it should be particulary suitable for Scrum: You define a set of stories for each sprint, and you bill each sprint, so project moves on, you keep a visibility (the scope of a sprint cannot be change while it is in development), but the project is open to change and the customer is involved.