How can we educate our customers and domain experts to adopt to the agile process
Background: In Switzerland and Germany agile development is not yet exercised by many .Net developer shops. Most of the companies still work according to the water fall model with a big upfront design. As a consequence customers are not accustomed to this methodology.
The goal of this session was to get some answers on how to address problems faced during the communication with the customers and the domain experts.
Some problems that were discussed
- the customer does not know anything about agile software development:
- how to convince the customer that you are not going to make a "big upfront design"
- what can I guarantee to the customer as a deliverable and where can I just promise "my best effort"
- how to compete with non agile teams when writing an offer for a new project of a (new) customer.
- often we have to offer low, just to get "our foot into the door"
- an small agile shop has less overhead and can thus offer a lower price
- the customer and/or his domain experts are not available for regular meetings and/or feedback after a sprint
- we have to put some minimal requirements regarding participation of the customer and/or his domain experts into e.g. the contract
- we have to make the customer aware of that if its collaboration is not optimal the developer (lead) has to do more work which causes additional cost
- the customer wants to put more and/or larger tasks into a given sprint
- for each task the customer wants to put into a sprint another task has to be removed and thus the list of priorities has to be changed.
- for large tasks the time estimate is difficult and inaccurate. Thus the task has to be split up an re-prioritised
- how to deal with heterogenous or changing teams where you cannot define the velocity of the team.
Comments (2)
Derik Whittaker said
at 10:12 am on Nov 2, 2008
I really do not like that we use terms like convince when talking about bringing change. We should focus our efforts on showing benefit rather then trying to convince. Typically when we are trying to convince, we are preaching. When we are preaching we come off as better then others.
Doc List said
at 11:38 am on Nov 2, 2008
One of the key features of conversations I have about agile adoption/organization transformation is "business value". It's all about creating/contributing to/understanding value - value to the business, value to the business's customers, value to my team, value to my organization. Once folks get that, it eases the way.
You don't have permission to comment on this page.