Agile India 2014 Conference – large scale distributed agile development

AgileIndia2014_LogoBig
For 10 years, the Agile Software Community of India has been holding this conference now, with ever growing numbers and great names from everywhere. With more than 1200 participants, more than 250 of these from other countries than India, extending from Norway to New Zealand, from Indonesia to Ukraine, and more than 300 women, Agile India 2014 was a huge and really diverse agile conference.
 In the previous years, I had already received positive impressions from the colleagues in Bangalore. This year I had the pleasure of participating for the first time myself, presenting the story of our Distributed Product Owner Team for an Agile Medical Development. The process of selection of topics and feedback was very well prepared and community based. While everybody could see the proposals, ask questions and comment on them, the members of the program committee took care that this would happen consistently, and did a lot of it themselves as well. For the topics selected by them, also an extended paper was necessary with a case study, which also underwent a feedback and approval process, in my case by Ravi Kumar and Pramod Sadalage .
During my presentation

During my presentation

Fortunately, I had work to do in India as well – start up trainings for a few new Scrum teams at our company – so I already had the justification for going. On the other hand, I had enough work to do so that I could not consider going to the other conference days, apart from the one I was speaking at. So I can only talk about the Offshore Distributed Agile track.

Todd Little presenting

Todd Little presenting

I enjoyed Todd Little’s keynote in the morning very much. One of the key messages that resonated most in me was „We need to treat remote teams not as coding monkeys but empowered Ewok.“ I hope as software specialist, you are familiar with the Star Wars universe and do not need to look them up in Jedipedia.Todd said exactly what we are trying to do in our big, distributed product development, and my mission to Bangalore was part of it: make the remote teams self-organizing, trusted members of our diverse product development universe. Only that in Todd’s presentation, it turned out that he only needed to add a few software developers with a domain specialist in Romania and a small test automation specialists’ team in Vietnam to his original group in the US – and they were already very successful. So: adding the right people for a good reason, valuing the individuals over corporate strategic outsourcing strategies.

The other talk I remember well was from Rajkumar Anantharaman from Intel, who stated „If you want to go lean and agile, first you need to get rid of Excel and PowerPoint“. This was of course not aimed at a nice PowerPoint by the Product Owner showing some functionality the users ask for, but at getting rid of the additional reporting needs that keep teams busy with overhead.
The venue was a bit resisting the actual number of people participating, it is certainly difficult to predict, but maybe another year they will be better off in a congress center. A difference with the European agile conferences I have been attending like ALE or XP was certainly that there were much more business-people than agile coaches hugging each others. Maybe even most agile coaches look like business people in Asia. In all cases it is very important going to India and seeing what is going on there, noticing how people discuss, what they hold as granted in agile, and what they have still doubts about.
At the panel discussion with Doc Norton (groupon) and Chad Wathington, ThoughtWorks Studios

Participation in the panel discussion with Doc Norton (groupon) and Chad Wathington, ThoughtWorks Studios

More or less, the other speakers confirmed what I have learned from our own experience: there is not the question whether or not agile is going to work with distributed organizations and teams in India, but how to make it work. You can do a pretty lot of things right or wrong, and even terribly wrong, but you can just as well be successful if you are doing many things right.  At the end of the track, there was a quite interesting panel discussion facilitated by Naresh Jain: Offshore Agile…An Oxymoron? There were a lot of interesting topics discussed. Where I could definitely contribute was when someone asked the panel whether they could just take a framework like SAFE and apply it to a big distributed product development organization to make it agile. According to my experience, though such frameworks can help, every organization has their own challenges, their constraints, and their organizational culture. Whatever lean-agile framework they will build, they need to build it on their own – but of course, taking as input the experiences of others, and agile frameworks as well as wonderful books like Bas Vodde’s and Craig Larman’s „Scaling lean and agile development“.
Photos used by courtesy of  Agile India (c)

Role and responsibility of executives in a lean/agile transition

1) Choose internal change agents carefully

Volunteers
Positive mind and change orientated
Sense of urgency
Capacity for reflection
Work level experience in software development
Transition team covers different project roles and organizational units
Involve line management
Involve product management / business people
Involve process / Quality Management early

2) Be sponsor to the transition team

Give your vision, or agree explicitly to vision and mission of the transition team
Tell them what the constraints are
Be interested in plans and results.
Reed at least one good book yourself that does not look like a Scrum Bible, but something explaining what may work and why.
Do not expect to have NO impact on project time lines, this is just wishful thinking.
Give a reasonable budget based on estimates of the transition team
Do not tell them how to make the transition. Rather be able to discuss organizational changes on their request.
Let the team choose external consultants, but ask these people a couple of tough questions before you contract them.

3) Take care about trust in your organization

Do you, and do your middle managers trust your teams to get their job done? This is an essential part of any lean/agile transition.
If you are still not there, expect transparency to grow at the project team level, but you have to inspire trust from the management level. You need to start! You need to express trust to your teams and act accordingly yourself.

4) Do not combine a lean/agile transition with negative measures

Especially, do not try to reduce headcount. This is directly counterproductive to encouraging people to share their knowledge.

5) Foster a learning organization

Expect your organization to be on a learning journey for more than the transition lasts. The agile principles expect you to hire the best people, and give them the environment so they can be productive. In traditional hierarchical companies, often people need to learn to learn again. And often the environment consists of crappy old tools that make them slow. You may have tons of legacy code without automated tests. They will not magically disappear at the agile transition. The teams have to learn and improve a lot until they will really feel agile.
You will see improvements very soon, but this is not the end of your journey.

6) Look for opportunities to benchmark your transition with others

As executive you should use your connections with your colleagues from other companies for exchanging with them and creating opportunities for the transition teams and different project roles for comparing and exchanging experience so that you all learn more quickly.