When I started the university we learned about Microsoft Project, waterfall modell, V-modell and RUP. But time’s changing. With the keyword agile there’s a lot of upcoming development methodology. Scrum and Kanban are getting more and more popular in software development circles. The common problems about methodologies are that they have to be implemented for the company’s needs but theres’s no guidance how to do it right. So people read the agile manifesto and try to customise it. Customisation includes the temptation of interpreting the rules for the individuals’ demands and comfort. Are these really so universe as they meant to be? Are these good for all developer team? Or is it possible that sometimes these just make convenient to avoid all confrontation with the customer in present? Because this technics provide a way to deflect all responsibilities on the customer. I saw many times how the being agile approach could ruin whole projects in a traditional customer-developer model.
There are some legend around about how the Agile Manifesto was created. But first let we see it:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
This sounds very well. So what on earth could go wrong?
Requirements
Customer: Okay, I’m the customer now. I want …
- a fully featured webshop for my products.
- it to be fast, easy to use and nice.
- it to be ready as fast as possible.
- it to be as cheap as possible.
I don’t care about technologies. I don’t understand what php, html, jquery are stands for. I can only see that if I click on the search button will I see the correct results or not. I’m only care about the appearance, speed and sales performance of my site.
Developer: From the developer company’s point of view I want …
- Work in scrum or kanban because this will guarantee the customer satisfaction.
- The customer to be involved as much as possible so he/she will be able to make the decisions easily.
- I want the project to be finished in time and get the money as soon as possible.
I don’t want to make business critical decisions. I don’t want to make plans for the whole project. Agile is convenient.
The conflict
The problems’ base is when the customer wants to make significant changes on plans ( for example design ) as the principles of agile developer makes it. The customer wants to change something again the developer does it. And this goes on until the deadline is getting in sight distance. The customer now wants to see what they discussed at the beginning of the project. But only the 60% of functions was implemented. The developer says: “but you made so many changes during the development the requirements had to be modified”. The customer says: “okay, but nobody told me anything about modified functionality. I want everything we discussed to be ready for the time we agreed.”
What happened?
As always a triangle can explain everything.
Agile triangle
Agile methods consider cost and schedule as constraints. However each sprint must deliver tested, working and full features but feature set could be decreased. Contrarily if I’m a customer I will only care about the features I wanted to see on my webshop and I want them all on the previously established deadline to be done.
Let me show an example. If you’re taking your car to the car mechanic will you be willing to go back there every day to discuss about how your car is going to be fixed? Would you accept the answer that almost everything was fixed but the second gear won’t work because you asked them to change the oil too? I’m sure you won’t. For the most of the customers software development is like repairing car. They go to a profession because they aren’t adept in it. They want their problem to be fixed as soon as possible. Meanwhile they want to deal with their own business what they are good at.
Conclusion
I think Agile methods are very good. Especially I love Scrum. But always use the right tool for the problem. In a customer-developer model where customer and developer is not in the same organisation and customer can not be the organic part of the development a strict V-model or RUP could be much better choice for developing a new software. With detailed requirement specification, a particular planning and a scheduled development process with correct delivery customers are going to be much more satisfied in long-term.
Always be aware of being agile is in the favor of customer or yourself…
Recent comments