If you plan to attend the next Agile Bangalore User Group [A-BUG] meeting, please RSVP via email to nashjain@gmail.com.

Agenda:

• 7:00 - 7:30 - Intro, Welcome, Snacks…(SetUp)
• 7:30 - 8:30 - User Group Meeting
• 8:30 - 9:00 - Q&A, next meeting discussion,…(Teardown)

Topic
TBD. If we don’t find any volunteers we might use 35 to come up with the topic.

Venue
Valtech India Systems Pvt Ltd
# 30/A, First Main, Industrial Suburb,
Opposite Jayadeva Cardiology Hospital,
J.P. Nagar Third Phase,
Bangalore - 560 078
Phone Board : + 91 80 2607 9100 / 9999

Sponsors
Thanks to Valtech for hosting the meeting and sponsoring the snacks.

More details : http://agileindia.org/asciwiki/tiki-index.php?page=Aug+1st+BUG+Meeting
Schedule of future meetings : http://agileindia.org/asciwiki/tiki-index.php?page=Schedule

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.

I’m thrilled to be back in Bangalore. One thing I really missed in US was the craziness of driving on Bangalore roads. Everything was so systematic, there was no thrill, so excitement, no fun, I would be bored to death. The other day I started thinking what I really like about driving on Indian roads? There was something about driving here, that strikes a chord with the way I work [you would have guess by know, .i.e. develop software]. After spending an hour thinking about them, I concluded that, driving on Indian roads have a lot to do with the way I build/develop software .i.e. using Agile methods. Here are my initial thoughts why I think so…

• Chaos from outside : If you are not driving on Indian roads, it looks like the epicenter of chaos and noise. It will take a while for you to figure out why the traffic on the roads are oriented in 360 degrees. Everyone seems to be honking at each other. If you talk to someone who has watched an Agile team work for a week, they can share similar thoughts about chaos and noise. Companies where I have tried to introduce Agile, chaos and noise seems to be one of their top concerns. Once you are part of the system, life is wonderful. Trust me, you will never look back again.

• Embrace change : If you drive though a street and come back to it a week later, there is a high probability that the direction in which the traffic flows would be reversed. Changing the directions of one-ways is very common here. Driving 2 wheels with helmets on is another rule that has changed at least 10 times in the last few years. The good thing is folks embrace change and continue with it. Strikes a chord with what happened yesterday during the client meeting?

• Heavy emphasis on open communication and continuous feedback : If you watch people in India drive, you might wonder why they honk continuously and sometimes flash their headlights? Well, that’s our way of communication and feedback. If you watch carefully, the intensity of honking and the frequency of flashing lights varies depending on what one driver is trying to communicate to the other. A gentle honk, means, I’m about to overtake you, watch out. Continuous honking means, move out of my way, you are wasting my time. A gentle flash of light means watch out, I’m behind out. All of us know the importance of open communication and continuous feedback on software projects.

• Self organized : If you look at the traffic rules in India, we are not so rigid about the rules. You will find people overtaking from left and right. Sometimes you’ll find group of vehicles jumping the lights when the opposite side is empty. We don’t even have cops standing everywhere with Speed guns. A lot of busy junctions, don’t have cops. People nicely self organize and move on. I believe in self organized teams and I think that is the most effective way to build software.

• Adaptive planning : Its quite common to find one of the roads in your route blocked due to some maintenance work or accident. It very rare you’ll find people waiting for it to clear up. Immediately people find another route and move on. We plan to work and not work to plan. Its very rare to find that everything on a software project going according to the plan. Things change, we always have surprises and we learn to adapt and move one. Also note that let it be heavy rains, floods or heavy winds, none of these seem to bring the traffic to a standstill. People adapt and move on.

• Stressful and Intense : All said, you are having fun and all the good stuff, but driving on Indian roads is stressful and can be intense. This is the same feedback I get from people who work on Agile projects. Pair programming session can be quite stressful and intense. Trust me, you’ll feel much more exhausted in 4 hours of pair programming session compared to 10 hours of working on your own. Both of these activities needs a lot of attention and can drain you out soon.

• Mitigate risk : From outside, it might feel like driving on Indian roads is very risky. But if you look at the number of deaths caused due to accidents in India, its far less than that caused in US. Please note that number of deaths includes humans and animals. For those who live in suburbs in US, can tell you how many deers they find dead everyday. The trick is with people traveling so close to each other, there are very little chances to be caught by surprise. With constant feedback and continuous collaboration on Agile projects we try to mitigate a lot of project risks. Pair programming and collective ownership is another great way of mitigating the risk of one person being the bottlenecks.

• Maximize the throughput : If you notice the number of people that travel through these roads each day, its amazing. Look at the roads, every inch of the road is occupied and sometimes we don’t even spare the footpaths. We like to maximize the usage of the available resources. Every software project tries to maximize its throughput and Agile gives me a great platform to do so.

• Minimize the operating cost : I’m not too sure, but my gut feel says the amount of money and effort invested in maintaining and building roads in India is far less than what they do in other countries like US. Also consider the ratio of number of cops to the number of people traveling through these roads; it is very very small. We believe in reducing any form of overhead This is the harsh reality of software projects. But Agile helps me strike a good balance.

• Agility [the verb] : With the short distance between the vehicles, one needs to have really good reflexes to survive on Indian roads. Its amazing to see everyone jamming their brakes when something unexpected happens. They recover and move on. Being Agile [verb] is the key to success on a software project.

Having said all this, its always easy to find things that are done quite different in these 2 scenarios. Taking any analogy to an extreme causes more harm than good.