Be agile or die tryin’

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 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…

 

About charlesnagy

I'm out of many things mostly automation expert, database specialist, system engineer and software architect with passion towards data, searching it, analyze it, learn from it. I learn by experimenting and this blog is a result of these experiments and some other random thought I have time to time.
Bookmark the permalink.
  • Sebastian

    I disagree. I was running a company doing tailored development for various clients and after 6 years of struggling with the waterfall method we achieved to have agile contracts and scrum projects. That time the scrum was nothing but another cursing for the customers. Still they was grateful not having long conversations about details in a non existent applications, not reading (nor writing) hundreds of pages and sign an incomprehensible specification or design plan. The scrum turns out to be a real success for any kind of development even when the client was a total blond. The short iterations are assuring that the customers are trained step by step about the dev process. Even the big ones (like T-mobile) was grateful for demos, for having a priority ordered backlogs, and for trowing features from the end of that list.

    The agile methodology is nothing close to a car repair project. It’s more related to building a brand new car from scratch. In agile you are forced to build value in short iterations, and for a layman customer it’s easier to
    focus on the most valuable parts, than to deal with the whole.

    • charlesnagy

      I’m happy to hear that scrum worked for you. In spite of what this post might suggest I like agile methods as I wrote in the conclusion. The post was based on my recent experiences with some of my old business partners. They tried so hard to be agile that it caused the failure for them. Actually the main patterns in this post were taken from their examples.

      I know with proper teaching and coaching (and of course correct client attitude) scrum could work very well for big (>6 months) projects. But as I saw even the biggest web development projects can be done in 6 months. Of course I’m not talking about continuous development and integration. For this kind of projects I would use RUP or Scrum too.