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.

Earlier, we used to treat these tool requests as stand-alone requests and decide on it based on the usefulness of the tool, cost, priority/need to buy the product and other factors. As a service provider, when we bid on a development project and if our potential customer is insisting that we have a particular tool to award us the contract – we are likely to invest on it.

So how do you justify the cost on this tool? For sure, you can use ROI to justify the investment. Normally though, most developers don’t like to be asked that question – simply because it is difficult to put a number on the ROI. It may cost $2500 to buy the tool (or) take 1-2 months to search, find and fine-tune an open source tool. But, it is difficult for the developers or end users to associate a number for ROI. (While all along, you know that savings on a highly paid engineer’s time can directly result in cost savings).

Today, when we get a tool request, we ask a few fundamental questions right at the start:

• How is the tool going to change your work life?
• How will your productivity be affected – will your work output increase or be faster?
• How will the quality of the output improve?

These questions help the teams quite a bit. They think twice before coming up with a tool request now – they know that unless their answers are crystal clear, it is difficult for them to justify the request. The good thing about these questions are that they are not deterrents, but actually help in fostering the innovation thought – how do I do things better than what I am doing currently? If buying or developing a tool will improve the way things are currently done, go all out and get it. Cost is not a major obstacle.

In most of the tools scenarios, the first group which has requested for the tool / used the tool would have benefited the most. And, proliferation of this tool across the organization becomes slower as time passes by. So, we ask our teams to consciously look at how we can promote the best tools that we have, effectively and efficiently (obviously, they have to justify the license costs while doing this).