grails (11) vaadin (11) meteor (6) java (4) elasticsearch (3) apple (2) centos (1) cloudbees (1) google analytics (1) gradle (1) heroku (1) javafx (1) javascript (1) jdbc (1) jug (1) logback (1) logging (1) mac os (1) management (1) mongodb (1) mongolab (1) mysql (1) twitter (1) ubuntu (1)

Tuesday, May 31, 2011

What is the problem with agile approach and contracts?

I have decided to write down something about agile approach and its implementation in software companies. First of all, you are not alone in this world. You have your company, people around you and there are always your customers. 

I work in software company and it happens every now and then that customers are actually saying how to deliver the software product. How is that possible? Customer is usually saying how the contract should look like. Customer knows: what money he can spend, what must be delivered and when it should be delivered. 

Well, that is quite heavy stuff. Let's analyse is a bit...
"Customer knows what money he can spend" - this is absolutely fine, budget is clear - so customer knows what is the investment for the software development of contrived software product. The question related to this sentence is - "Does customer know if the reserved budget is enough for what they need?". 
 "Customer knows what must be delivered" - the question is, how he knows what should be delivered? How the information is passed to you? If it is a functional specification - it won't work. The functional specification is never 100% ready and correct. Let's say a customer has got enough money for a little experiment. The customer creates the functional specification and write there all the features of the requested product. Then the company passes this functional specification to 3 different software companies. What do you think, will they produce the same product? Is it exactly what customer expects? Can he use it immediately? Well, you could say "It depends on how the functional specification is written, is it detailed enough?". I can answer, yes - the customer did great specification with all needed details. There is written exactly what the company needs. So what is the problem with this? It is just because we are human and everyone interprets written text differently. We can use the example with sentence "Mary had a little lamb" - well, had Mary little lamb for dinner, or had she a little lamb in the yard (or there is also some interpretation that is available only for adults). 
"Customer knows when it should be delivered" - the start date is clear. The customer knows when they should go into the production. Does customer know what features are really needed? Is there enough time to implement those features? Or can we use prioritization and define scope (needed features) according to the priorities? 
It seems, that we have to deliver something uncertain for certain money and time. It looks good. But how to write it down? How to create agile contract? How to help our customer with understanding of agile approach? 

So, if you want to over talk your customers and convince them to sign the agile contract, you have to know and have good experience with agile development. It is really not easy to convince the customer. You have to be able to explain advantages of agile approach and disadvantages of waterfall or fixed price approach. What is the core of agile approach? What they will get more (when you compare it to your competitors)? 

What is the agile contract about? You commit your team to deliver exactly what customer needs based on their priorities. First of all, you have to be able to help them with prioritization process. Just don't ask - what is the highest priority for you... Go around a bit, ask them what part of the application they use most often. What is the core of the application. What are the users' complains... and so on. You can also estimate what budget you will spend and when something what is useful and gives some value to the customer will be delivered. 
You can't over talk customer just by words, you have to have the experience and some good examples. It is good to show success story - look at this project, they had all the problems and we solved them by agile contract.

Let me say one example. You are the person that should make the proposal to customer. You have got some functional specification, so you somehow know what should be delivered. But you don't know what exactly should be delivered. Why? Because it would take you months to understand to business logic of the application. So you decide to create something like agile contract where will be written "We are committed to deliver what is needed based on customer's priorities. The maximal price for the delivery is 2M euro and 20.12.2013 is the end of the development". Deadline is given by customer and you know that your team has 10 members (so you have calculated the price and it is about 2M euro). Then you define some rules like "Customer will support development team; Test cases will be created together with customer; Customer will participate each demo presentation and development team will get direct feedback on what has been delivered; Acceptance criteria are ...". Good job, it is done. You go to your manager and you know that pass this level will be quite difficult. He will ask you few questions, you answer something like "Well, we don't know what exactly is needed - so we offer something more like cooperation on the software product then just coding according to documentation.". OK, you have passed this one. Then you manager or you go to sales guy - the guy who should sell your proposal to the customer. Can you imagine what is the end of this story? Usually, sales guys don't have experience with agile approach. Sales guy want to offer customer with something more specific. He wants to offer: this and this will be delivered, this is the price and here is the time table - so he wants to know exactly what money (and when) will flow to your company. If you have survived this, go for a beer with friends and relax a bit. You are back in waterfall and fixed price project. 

The main preconditions - all people in the company have to have the right mindset. They have to be poisoned by agile approach.

Keep trying, don't give it up.