South beach diet didn’t work for me, and neither did Agile development.


Normally, I would write this in my SCN blog – but this is not about just SAP projects, I am going to do it here. As always, these are strictly my personal opinions – not that of my employer.

Some of you have seen me  – at work, at some tech conference, dog show or at an airport. I doubt if “Agile” was the word that came to your mind when you met me. I could easily lose 20 pounds and have some one ask me “hey, why are you not doing something about your weight?”. You get the idea. I have tried many a weight loss / excercise plan – and have  come to the firm conclusion that the magic bullet for weight loss is to eat less of everything I like (Rice, red meat, fried food) and excercise more.

In parallel, I was going through a similar excercise at work – trying to find an optimum way of managing the projects I get to run. I have read and tried several different things over the years in a variety of projects. Over the last couple of years, I have been fascinated with Agile development and hence I have been reading, talking to others, and trying it out in teams I manage – and again, I have  come to the firm conclusion that, just like the various dieting schemes – Agile also does not work for me.

This is not to say Agile does not work for others . South beach diet must have worked for others, and I am sure Agile would too. For me – no sir, I will pass. That being said, let me explain why it does not work for me.

Would you pay an Agile contractor to build your deck?

I need a deck built, and I don’t know how to build one. So I hire some one else to do that. And this dude tells me he can do it one of two ways. 1. I can discuss with him on how a basic deck has to be built, and he can give me an estimate. Or 2. I can give him a rough idea, and he will start building the deck, and every day or two – he and I can get together to see how it is going and what changes I want, and I can pay him for work that he has done every day. Of course in the second option, he cannot tell me how much the deck will cost me or how long it will take him to build me one – but I can see progress every day. I don’t know about you – but I know what option I will go for.  Same thing with my clients – if the work and schedule are not predictable – it is hard for them to just pay as I go.

Global and Agile are like Oil and Water – They don’t mix.

I forgot the last time I had all the IT and Business guys and gals working in the same location.  Most often – we have people working on a project from all over the globe. It is seldom possible to get teams from Japan, India, Germany and US to be on a conference call. And even if you do – without a written document explaining the problem and/or solution – it is hard to get anything done. 

There are only so many super stars in this world

In any given team, the norm is to have a few super stars, several average performers and a few below average ones. This has a direct effect on pulling off delivery in an agile fashion. Not every one can go away with minimal instructions and come back with the right solution, and right questions to ask for next day. 

It can be argued that Agile needs less programmers, and hence you can keep just the super stars and let go of every one else. This argument works only if the scope is small.  The day still has only 24 hours – and even super stars  cannot work 24X7  all the time to get everything done.

Most projects do not have dedicated business users.

The whole idea of Agile is to get something back to business users faster than in a waterfall model, and keep them informed of progress frequently. This is very good – except it won’t happen in most projects. Most companies find it hard to dedicate full-time business people to a project. More often, business users have to do project work on the side. So – even if the tech  team wants constant face time , the chance of that working out is low.

A few product companies have tried out Agile successfully. However, in the couple of cases where I got a chance to talk to people from the team – it seems, the customer was almost never present in the scrum meetings. Instead, the product manager assumed the role of being the customer voice. If that is the case, I would have to wonder aloud “so what is new?”.  Product manager is not the one who has to live with the product after it is out – it is the customer.

What works for you –  people over process? or process over people?

This is what it boils down to – Agile manifest claims the superiority of people over process. And traditional waterfall puts process over people. For me – as a manager of big teams, with a deadline and budget that seldom cuts me any slack – I would trust a good process to compensate for the human errors most of the time. I think it is a high risk for me to trust that every one in the team will perform to the same high standards. Having a disciplined process helps me get the best out my team, despite not every one being a super star. 

Would you build a mission critical solution using Agile?

I don’t know – but I keep wondering if NASA would use Agile for designing systems for their next space mission? I somehow can’t see any application that is very important and deals with life and death, or dealing with large amounts of money – like air traffic control or stock market transactions –  to use Agile.

I hope every one knows about 3C. This was the big Chrysler project that was the poster child for XP (Extreme programming). Well, guess what – that didn’t quite work out. Check this out http://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System  or just google and you will find several interesting takes on it.

Building a car and building a software solution have similarities in design. However, there are significant differences too. Just as it is impossible to build a car without knowing what exactly needs to be built – we cannot build a good software solution without knowing what the heck we are building. Otherwise, even if you follow Toyota manufacturing Process to build a Camry – you could end up with a Chevy Malibu.

Is Agile really good for long-term stability of a solution?

Most software is built by first putting a framework in place, and then building on top of it. It is the rough equivalent of putting a good foundation for your house. If you know that you will have a house with 2 floors – you will probably put a certain amount of concrete in your foundation. Now that you have finished the house – and for some reason, you now want one more floor – would you put one more floor without also doing some additional foundation work? And if you build by constantly messing with your foundation – I am definitely not going to buy that house or rent it for living.  Same thing with software – the way sprints happen from what I have seen, I doubt if it is possible to put a solid foundation in place.

It is fun, but is that good enough for customer to pay?

One thing I really like about Agile is that every one involved in it usually has more fun than in a waterfall project. This improves team morale and all the good stuff – temporarily. When you cannot get user involvement, or if a blame game starts – where there is no documentation to go back and clarify what every one agreed to, this fun does not always last. And fun for the development team, while important in a project, is not the sole reason why some one pays for a solution.

Waterfall is not such a terrible thing to do, as its opponents make it to be. And it is a big exaggeration to say the team does a very long design up front, and that user gets to see things only at the end. That is not how most projects run. Waterfall can also have users involved more frequently. Also, you can build in plenty of  feedback options and test driven development in a waterfall project. Also there are very strong visualization tools that can give the users a taste of the solution very early in the process.  For example – iRise is a great tool to use for that. Do try it out, and your whole perspective will change. Also, once you have a good change control process established, changing requirements can be handled very effectively.

So, when do I think Agile would work?

Despite all these points above, I am not an extremist when I think of methodologies.  In my opinion, Agile is going through a hype cycle exactly like how it happened with SOA.  Once the hype died down a little, we mostly figured out what is possible with SOA and what is not. SOA is great for several use cases, and terrible for others. Same is the deal with Agile.  Just because Agile possibly has the issues I called out above, it should not be inferred that Agile should not be used. If you have a bunch of highly skilled people, where the team has a clear vision of the end product, and/or where time to market is not such a big deal – all these challenges will vanish. Such a team can probably come out with a great solution using Agile. But in the type of projects I am dealing with – I don’t think Agile can succeed. 

Rather than take an extreme view of either/or – it is probably best that we let individual projects decide the methodology they want to follow.