Expand +



Agile, Scrum, and the South Beach Diet

by Davin Wilfrid

April 26, 2010

By Davin Wilfrid, ERP Expert

Vijay Vijayasankar recently wrote a blog post in which he lamented that neither the South Beach Diet nor an Agile project methodology have worked for him:

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.

Among the problems with Agile, he says, are that there are not enough super stars to go around on project teams, and that globalization has made it difficult to conduct the face-to-face sprints that are required with Agile. He also dislikes the pricing scheme:

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.

His point is well-taken, however it's also clear that a deck is far more of a commodity project that any enterprise software endeavor. The requirements of the deck (size, height, distance to the hot tub) are unlikely to change throughout the project, so an estimate based on total amount of work seems like a better option. Agile (and Scrum, the associated software product development methodology) are designed for projects that will change throughout the life of the project.

To be fair, Vijay does say that Agile must work for others -- just not for him. And he's right. Last year I published a case study on software vendor Endeca Technologies, which fused Scrum with SAP's ASAP methodology when implementing SAP ERP 6.0. The result was a 22-week implementation that met the company's needs and provided a platform for greater use of SAP as a strategic system.

You can read that case study here. In the meantime, all this talk about South Beach and dieting makes me want a Cuban sandwich in the worst way. Is it lunchtime yet?


An email has been sent to:

More from SAPinsider


Please log in to post a comment.

Davin Wilfrid

9/25/2013 8:42:31 PM

Hey Yosh,

I haven't come across anything specific on using Scrum for ABAP or other SAP development. It would be interesting to see if companies are using it for those purposes, though. I'll keep my ears peeled...


Mark Chalfen

9/25/2013 8:42:31 PM

Hi David, Great article - very close to home as I am working with a client that wants to be agile. There are pros and cons with agile - however, a strong Scrum master, and bought in team members will get certain pieces of functionality delivered in an efficent and accelerated manner.

Yosh Eisbart

9/25/2013 8:42:31 PM

Hey Davin - Interesting piece. Do you have any information re: Agile/Scrum SPECIFIC to development? Very interested on others' experience specific to integrating Agile/Expert Programming into ABAP related initiatives. THANKS FOR SHARING!