XNSIO
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

How to Involve a Customer on an Agile Project?

Recently I was in Delhi and I meet a few Agile Enthusiasts from the Agile Delhi User Group at Xebia office in Gurgaon. We had representations from Xebia, Hewitt and NCR Corporation. It was an informal meeting with no specific agenda, the idea was to discuss and learn from each other. After a round of introductions, we picked 3 topics:

• How to introduce Agile into an Organization and change people’s mind set
• How to involve the customer on an agile project
• Tips and Tricks on Distributed Agile

Majority of the people in the room were having issues involving their customers. So, we unanimously decided to talk about Customer involvement on an Agile project. Folks were also interested to know how to mitigate the risk of low customer involvement in an agile project.

We started our discussion by talking about what problems would the team face if the customer is not involved in the project:

• Issues with Requirements Clarification
• Lack of feedback
• Not having a sense of doneness .i.e. not having acceptance criteria
• No one to prioritize the stories [work]
• Lack of encouragement for the team
• The team might loose focus
• The risk of technical people making business decisions
• Lack of domain knowledge

On an agile project it feels like missing the driver/navigator of the project without the customer.

At this point, there was some confusion around who a customer is and who a client is and what about stakeholders? Following is my definition:

• Customer : Representative of the actual end users of the software. Sometime it could be the end-user. But more often than less, its really a representative who has enough domain expertise and someone who can make business decisions

• Client : Representative from the customer side who works with the software company at the account level. S/He takes care of the billing, infrastructure, contract, administration, etc kind of tasks. Usually someone from the management side.

• Stakeholder : Every single individual who would get affected by the software. Right from the end-user to the admin staff to the team who will maintain the software to the marketing department to the person paying for all this.

Based on these definition, its easy to say that every one on this list is important to ensure the success of the project. Everyone’s feedback will be important. But you want to make sure you have at least the “customer’s” involvement and commitment. Stakeholders are important and it really helps to keep them in the loop, but may be not on a day-to-day basis.

Having said that, how do we go about involving the customer?

• Kick off and Planning meetings : Its important to have the customer involved in these meeting. These meetings really help the customer to drive the direction of the project. Also it mitigates the risk of business people not making the business decision and leaving it up to the technical people to make those decisions.

• Showcases and sprint reviews : These are great forums to demonstrate what the team has achieved and get concrete feedback from not just the customer, but also from the stakeholders. These meeting can really help the customer plan the future iterations/sprints. Majority of the times in my experience, the customer knows what they want, but they don’t really know how that would look when its a part of the software. These meetings help them get the initial glimpse of what its going to be like and hence provide us early feedback which helps us drive the project much closer to what they want.

• Standup Meetings : Great forum to see the progress and get involved with the day to day working of the project. Helps them understand the issues the team is facing, which means they get enough first hand information which in-turn really helps build trust. Once this happens the customer is willing to really be a part of the team and collaborate with the development team.

• Retrospectives : Retrospectives is another great way to involve the customer into the team. This is their opportunity to listen to the team and give their point of view on why certain things happened in certain ways. Retrospectives are used by Agile teams to drive their progress and the way they work. But if customer involvement is one of the issues they are facing, it makes complete sense to involve the customer in these meetings. Initially the team might not feel safe to talk in this setup, but they need to build the trust and rely on open and honest communication. You will be surprised how many customer will love this. Having said that, there are times when customer can use this to play the blame game. When this happens, there is certainly a big issue with trust. I would rather attack this by educating the customer, than trying to avoid this.

• Frequent informal demos : may be even from developer/QA/build machines. The shorter the feedback cycle the higher the chances of you meeting customer requirements. Something that we have done on projects is have a daily demo with the customer so that they can see the progress. A lot of times they give really useful feedback. Even if they are not always giving useful feedback, at least they are engaged with the team and either sides don’t seem to drift away. Having the pressure of give a demo helps to keep the team focused. Developers don’t wonder off working on their mini-research projects. Its also a great way to plan. The customer says I see this, tomorrow I would like to see this plus that. The team can mutually work out with the customer what is possible and what is the right thing to do. During the user group meeting, some people expressed the concern, that the customer might try and make a lot of changes when they see these demos and that might introduce unwanted scope creep. This is a valid concern. But I think it is possible to work with the customer to explain them that the team capacity is fixed, so if they request something more, they have to take something out of the iteration/sprint. In my experience, most of the customer are fine with this, because they are getting what they really think they want.

• Estimation and Product backlog : Having the customer own the product backlog, really puts them in the driver’s seat. A well structured product backlog is a great place to get a high level understanding of what the project is trying to do. I’m not a fan of big estimation sessions. I feel a quick gut based estimate is good enough for the customer to prioritize work. Business value certainly drives the prioritization, but high level estimates and risk involved are also other important factors that can help customer prioritize stories. Estimation is a way for me to understand the requirements a little better and also a great way to engage the customer.

• User Stories : User stories are a great way to capture requirements. Really simple and quick way to capture requirements which can later be discussed in detail with the customer. Please note that some people try to capture as much information as possible. They are no longer user stories. They become narratives or epics. I guess the rational is, we have got the customer, lets try and extract as much information as we can so that we don’t have to go to the customer again. This to be completely opposite to what I would like to do. For me stories are a contract to talk further with the customer. Otherwise we’ll actually let the customer the drift away. Also thinking form lean point of view, we are just building inventory which might soon be outdated, misunderstood and it will cost us time, effort and money to maintain it. Try Just-In-Time elaboration of stories, it will be far more powerful.

• Building Automated Acceptance Tests through Deep-Dive sessions : Usually when a pair of developers pick up a story, they sit with the customer to flush the details about the story. It is important to note that we cannot consider stories in isolation. During the deep dive sessions, the customer sets the context and explain the business flow that the story tries to automate. During this session the developers can get majority of their clarifications. It also helps them get a sense of the done-ness criteria. Ideally you would like to pair with the customer and come up with an automated acceptance test using a collaboration tool like FitNesse/Selenium/Sahi/Abbot/Lattu etc. If you can achieve this, its takes a huge burden from the customer to do User Acceptance tests for every little functionality in the system. This is probably one of the trickiest practices to set in place on new teams. There are always concerns about when should the deep dive sessions occur. Some people feel without the acceptance tests, it is not possible to estimate. So acceptance tests should be ready before the planning meeting. While others believe that its better to have the deep dive sessions during the iteration/sprint. Estimation is only relative estimates, which can be easily done with little info available. I have tried both and both seems to work fine. My personal preference would be to do the elaboration Just-In-Time, so that the turn around time for each story is really short. It also eases out a lot of planning which could be required otherwise. Deep dive session are also a great place to involve the QAs on the team. After this session, the developers can develop the story while the QAs can create automated tests for the stories. Again, this helps to get a story signed off within an iteration/sprint.

• Issue and Risk log : On all our projects we maintain an issue and risk log. This is basically any issues or concerns that the development team or business team thinks can be a risk to the project. We also have frequent risk and issue brainstorming sessions where we try and capture them. Retrospectives are also a great forum to capture them. Most of the projects I’ve been involved with, we use the team wiki and a flip chart in the team area to capture these. The idea is to keep them visible to everyone. As much as they can stare into your face, you’ll think about ways to mitigate them on a day to day basis. The nice thing about this log is, it raises the awareness on both technical as well as business side. This is another tool that the development team uses to collaborate with the business team.

Customer involvement can be a catch 22 situation. If the customer feels they are in control and they have a say, they would like to get more involved. But for them to feel in control they have to actively participate in the project.

All this is great stuff, but what do you do when you cannot get access to your customer?

• I would try and educate them about the importance of this. Put the ball in their court. It is a 2 way street and both sides need to make an effort

• Find a customer proxy. A lot of project have business analyst playing the role of a proxy customer. There are lot of drawbacks to this approach. Hence it is important to keep trying educating the customer.

• If none of this works, I think walking out of the project is your safest bet. We spend a great deal of effort before we take a project on to make sure the customer is ready for this kind of a commitment. We also a quick 2-4 week project inceptions to give a feel to the customer about our way of working. Sometimes at the end of inception, we decide or the customer decides that it might not work out. It far better than realizing this 3 months down the lane.


    Licensed under
Creative Commons License