I attended the 2011 NCR Agile conference a few weeks ago. This was the second such Agile conference I was attending within an year's time and what brought me back weren't the speakers or the interactive sessions alone. It was largely the debate & discussions on different ways of getting software done right and the networking sessions where you could actually discuss potential challenges & issues on your software development techniques with others in the practicing community.
There was one such discussion I got into with one of the speakers at the conference that was to do with distributed software development. In my 8 years at Tata Consultancy Services, I had mostly worked on a distributed offshore/onsite or a multi-shore model but always using the traditional waterfall method. In my 2 years at a product startup, we used agile and always worked out of the same floor and so we never had to face the challenges of distributed agile or scrum. However, from my TCS days, I recalled that the biggest challenges we had were to do with communicating enough, communicating correctly and ensuring enough visibility for all teams across locations. And we used different techniques to make this work. For starters, we tried to enforce an onsite/offshore rotation policy so that everyone on the team is acquainted with one another as much as possible. We also tried ensuring that all victories even the small ones are celebrated and that any sincere effort never went unnoticed. However, most importantly, what really made distributed software development successful were our onsite & offshore coordinators. These 2 people could make or break the projects and in no uncertain terms were their jobs the 8-hour-a-day type. These were almost cross-functional specialists in a sense and their skill-sets spanned across ensuring operational excellence and managing client relationships and team members. I found the ones who were more good with people to be much more successful than the ones who were simple more good technically. The gentlemen I were discussing this with didn't take it too kindly. For one they were both these coordinators on a not-so-successful distributed scrum project and they were both technical leads on the project. However, more importantly, they didn't think that specialists such as people managers or project coordinators had any place on teams practicing Agile software development where the emphasis was on everyone doing everything.
I could actually relate this to 2 other speakers at the conference where while one mentioned that one of the dangers of agile was that everyone seemed to be focusing on generalists and trivializing the importance of specialists and the other mentioned that agile is simply another process of getting software done and that the process is irrelevant given that it was the outcome that eventually mattered.
The other debate I got into was to do with if developers in product companies were better at their jobs than those at service companies. This is largely true at least from what I have observed. However, the real question to ask is if product companies are as effective as service companies. I know a zillion more failed product companies than I do service companies. If we are really smarter than our counterparts in service companies, then we should be doing much better than them at making profits. I know that this could be an apple-to-oranges comparison and that the balance sheet isn't everything but the cash reserve our top 5 India-based service companies have could put some of the most famous global product companies to shame.
There was yet another interesting discussion on metrics and measure of performance of projects doing agile. For one, collecting even simple metrics takes effort and given that the real value is in the delivery of software, should one be spending time on data collection at all? I believe that it is worth the time and that it is also best kept simple and easy to measure. They have many advantages: they help us know where we are, on what we can make further continuous improvements and help promote this transition.
This has been a long post. At the end of it all, I just want to say that continuous improvement is at the core of all this and that the process isn't everything. The process is just an enabler and we should just keep it that way. From that perspective perhaps the philosophies across most software development methodologies aren't that different after all. Its just that some have more boxes and arrows on their diagrams than the others.
There was one such discussion I got into with one of the speakers at the conference that was to do with distributed software development. In my 8 years at Tata Consultancy Services, I had mostly worked on a distributed offshore/onsite or a multi-shore model but always using the traditional waterfall method. In my 2 years at a product startup, we used agile and always worked out of the same floor and so we never had to face the challenges of distributed agile or scrum. However, from my TCS days, I recalled that the biggest challenges we had were to do with communicating enough, communicating correctly and ensuring enough visibility for all teams across locations. And we used different techniques to make this work. For starters, we tried to enforce an onsite/offshore rotation policy so that everyone on the team is acquainted with one another as much as possible. We also tried ensuring that all victories even the small ones are celebrated and that any sincere effort never went unnoticed. However, most importantly, what really made distributed software development successful were our onsite & offshore coordinators. These 2 people could make or break the projects and in no uncertain terms were their jobs the 8-hour-a-day type. These were almost cross-functional specialists in a sense and their skill-sets spanned across ensuring operational excellence and managing client relationships and team members. I found the ones who were more good with people to be much more successful than the ones who were simple more good technically. The gentlemen I were discussing this with didn't take it too kindly. For one they were both these coordinators on a not-so-successful distributed scrum project and they were both technical leads on the project. However, more importantly, they didn't think that specialists such as people managers or project coordinators had any place on teams practicing Agile software development where the emphasis was on everyone doing everything.
I could actually relate this to 2 other speakers at the conference where while one mentioned that one of the dangers of agile was that everyone seemed to be focusing on generalists and trivializing the importance of specialists and the other mentioned that agile is simply another process of getting software done and that the process is irrelevant given that it was the outcome that eventually mattered.
The other debate I got into was to do with if developers in product companies were better at their jobs than those at service companies. This is largely true at least from what I have observed. However, the real question to ask is if product companies are as effective as service companies. I know a zillion more failed product companies than I do service companies. If we are really smarter than our counterparts in service companies, then we should be doing much better than them at making profits. I know that this could be an apple-to-oranges comparison and that the balance sheet isn't everything but the cash reserve our top 5 India-based service companies have could put some of the most famous global product companies to shame.
There was yet another interesting discussion on metrics and measure of performance of projects doing agile. For one, collecting even simple metrics takes effort and given that the real value is in the delivery of software, should one be spending time on data collection at all? I believe that it is worth the time and that it is also best kept simple and easy to measure. They have many advantages: they help us know where we are, on what we can make further continuous improvements and help promote this transition.
This has been a long post. At the end of it all, I just want to say that continuous improvement is at the core of all this and that the process isn't everything. The process is just an enabler and we should just keep it that way. From that perspective perhaps the philosophies across most software development methodologies aren't that different after all. Its just that some have more boxes and arrows on their diagrams than the others.
No comments:
Post a Comment