Moderator		Panelist		Panelist		Panelist
Pari Natarajan		Derek Waugh		Steve Jones		Gowri Subramanian
CEO and Co-founder, Zinnov Consulting		Director – Software Engineering, NCR		Technology Director, Cybit		Co-founder & CEO, Aspire Systems

Date: Tuesday, March 9, 2010

Time: 11 AM GMT

(Registration is Free)

Over the last several years, many packaged software vendors/ software providers have outsourced their development needs with cost-cutting in mind. However, that’s no longer the case. While having global R&D delivery capabilities are important, there’s more to it that just cost advantages.

Today, from architecture and design to development and support, offshore R&D teams are working hand-in-hand with their onsite counterparts to deliver innovative software at a faster pace and high quality. Global teams are now helping companies stay ahead of the curve, innovate and grow – and those who don’t utilize their capabilities are likely to be the ones left behind.

But not everyone reaps the benefits of globalization equally. So what are the factors that can help you leverage distributed R&D?

Join Aspire Systems for a Panel discussion on “Distributed R&D: Beyond just Cost Benefits”.  Some of the themes discussed will be:

• The impact of distributed R&D on software companies/teams
• How do you leverage software/product engineering expertise of global players?
• Challenges in outsourcing and how to overcome them?
• Globalization – myths and realities
• Best practices pertaining to globalization & distributed development

Agile has its own advantages and people who vouch for it. So does a completely different way of doing things – the CMM (Capability Maturity Model). What are the compelling reasons for a person who is practicing CMM processes to move to agile?

Siddharta: I’d say there’s only one compelling reason – and that is, if what you are doing currently is not working for you. If you’re following CMMI and it is working for you, that’s great, then there is really no need to change. You don’t have to change because it’s the in-thing. That’s something which I’m quite against.

But a lot of people do have problems when it comes to CMMI when requirements are unstable, because of the way it is structured, and with testing and user acceptance right at the end, which creates a lot of issues with respect to changing requirements. Or cases where you’ve not got the requirements exactly or there’s also the case where the customer sees a product and then gets lots of ideas on how it can be done. So when you have a market like this, then you find that CMMI tends to cause issues because you get bugs right in the end, you get change requests right in the end. It can be difficult to cope with it.

Whereas agile is perfectly suited for those kinds of project. You make frequent releases, there is a lot of feedback is involved, there is a lot of collaboration involved. So in these cases, agile is well suited for these kinds of projects. If you’re doing what you’re doing, and its working then fine, I’d say continue with it. But if it’s not working, then agile could be an alternative.

Right, but is it true that agile is more applicable for consumer kind of applications and products compared to enterprise-class systems?

Siddharta: No, I wouldn’t say it’s true. In fact it’s kind of interesting because where agile originated from – if you look at it – a lot of it is from enterprise applications. If you look at extreme programming, it developed out of a project at Chrysler. If you look at feature-driven development, it came out of a project in Singapore and so all these projects are enterprise projects. The history of agile is actually quite the opposite – it’s come out of an enterprise background, where if you look at it, in an enterprise setting – requirements can change often and things like that.

Now of course, if you really think about agile, it started a lot before Web 2.0 came into the scene. So that’s the background from which it has come and it just so happens, now that we talk about web 2.0, it turns out that agile its perfect for those kind of applications as well because you have releases going out very quickly. But I wouldn’t say that that’s the only type of project that it is suitable for because the history of agile is really coming out from the enterprise group. Even today if you look at it, most agile projects are Java oriented enterprise projects.

That’s a very interesting take. Can you outline some of the biggest challenges you see when people try to make the transition to Agile?

Siddharta: Yeah, there are so many. The number one is getting into a mindset and cultural change. You know, agile is not really about processes if you think about it. What agile promotes is a set of values and process is something which just comes out of a value and that’s why we have so many different processes that can all call themselves agile.

The values we are talking about is like, for example, collaboration between customer and developers and management and testers and so on, we are talking about self-management, about being adaptable. These kinds of values are quite the opposite of what traditional project managers have been used to. They are used to plan-driven projects, they are used to command & control hierarchies, they are used to contract negotiations with the customer. So coming out of this mindset and coming into the culture of agile – that’s the biggest stumbling block.

We see a lot of people who try to adopt agile without changing the values and it runs into some dysfunction or the other. For example, instead of having a self-organizing team, they do iterations but the manager tells everybody what to do. So they think they are doing agile but actually speaking I wouldn’t really call it agile. So you come across these kind of dysfunctions because the cultures as a mind-set change has not been done and that’s really the number one issue. Once you do the mind-set change then you can pick on any number of practices to do what ever you need to do but if you do practices without doing the mind-set change, you could be in some trouble.

2. Minimize server round trips: Minimize the number of hits to the server during an operation. For instance, while loading data or executing a set of operations.

3. Use memory sparsely: While using memory-critical system resources, stick to ‘Acquire Late Release Early’ principle. For example, opening web/DB connections and creating IO streams. Also determine the data required for the current page and current request and load only as much.

4. Use lazy/ asynchronous processing whenever possible: Always reduce the amount of workload for a single request by opting to delegate part of the work to a background process, by opting to make an external system’s processing asynchronous or by doing the processing later.

5. Use remote invocations selectively: Remote invocations are very expensive and have great impact on performance. Hence use them as selectively as possible.

6. Profile your code frequently: Use performance testing tools like SQL profilers and code profilers to benchmark your product’s performance. Also deploy some code analysis tool(s) in parallel, and make sure your code passes through all performance parameters in the project-specific checklist you have arrived at.

7. Audit performance: Monitor and track (log) performance-related data at chosen parts of the code consistently to monitor performance.

8. Benchmark your product for performance: Test your application periodically with large quantity of data and use appropriate tools to benchmark your application for performance.