Sapphire Agile Throwdown

In response to all the hub-bub surrounding Agile vs. Waterfall the Enterprise Geeks interviewed Vijay about his experiences with agile.  The discussion focuses on how agile impacts different teams like, SAP, customers and SIs.

Audio Only:


eGeeks Agile Development

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

8 responses to “Sapphire Agile Throwdown”

  1. Pratik Talwar says :

    It was a good talk more over discussing managing projects. Valuable insights on different development environments across organisations and shortcomings teams have implementing different approaches.

    Good to also learn about team dynamics.

  2. Chris Paine says :

    Warning – extremely cynical comments below…

    From my experience working for a medium sized consultancy firm, (there are quite a few of us but we can’t compare to the IBMs etc.) the retention of the waterfall methodology is a very important part of the cost/business model for these large consultancies.

    The waterfall model proposes a complete solution at a known cost (with change control at additional cost).

    Agile delivers a complete solution (if one can be found) at a unknown cost with change control part of the process.

    I’ve been involved in bidding for projects against many of the larger consultancy firms – they put forward a very reasonably priced solution with the waterfall model. So reasonably priced, in fact, that we can’t compete with it. The problem is that the procurement teams assigned to signing up an implementation partner are looking at that single end of waterfall number and using it to choose.

    Yet when you drill down, the costs, of making a change to the scope of the project for one of these strict waterfall projects, are huge. Perhaps this is inherent in the way the projects are designed (distributed teams, highly detailed documentation, specifications…) But the costs to the business quickly mount up. From the implementations I have seen, this change cost quickly mounts to being a significant part of the overal project cost. And the large consultancy firm (yes I am being very cynical here) is reaping in the cash. Yet as a customer, it’s your fault that the costs are mounting and you haven’t realised that amazing value for money that you were promised – because the costs are all because you are changing scope – and you have to sign off on each little change.

    The procurement teams say – “You should have defined you original scope better”, the business say – “But things change!” and the large consultancy keeps getting paid – more and more.

    Now I’m not saying you can’t have a waterfall project come in on budget, and I’m not saying that agile offers a magic bullet that would hugely reduce the costs of change (although I believe it does reduce them).
    What I am saying is that when bidding for a project, Agile does not hide these change costs – it throws the uncertainty that they may generate right up there from the beginning – dealing with change is inherent in the model. Whereas with waterfall, these change costs can be more easily hidden in the small print and seperated out when it comes time to providing that one Best and Final Offer on which the procurement team then makes their decision.

    Were all companies to move to Agile, the rigidity and overseas development teams which these larger consultancy firms rely on to be able to produce low price waterfall project bids would work against them, and suddenly the local co-located development teams would be much more attractive.

    That’s why – with my hugely cynical hat on – I think you won’t see a large uptake of Agile within the large consultancy firms – and you’ll even see a campaign against it. Their businesses are structured such that any competitive advantage they have (which I would argue does not really exist when you take into consideration full lifecycle costs) would dissappear if they were forced to go Agile.

  3. Dagfinn Parnas says :

    A related video on why lazy developers hate Agile and scrum from @dparnas (myself) and @tbroek

  4. Vijay says :

    Oh come on, Chris – I thought big and small SIs were big friends 🙂

    I 100% disagree with your position, and would like to ask you back a question. Lets say the small SI is doing the implementation – and the customer brings up changes fast and furious. Irrespective of whether you are doing Agile or Waterfall – you have only 2 choices. Either you eat the cost and say “see, this is why small SIs are better – we never charge you more than planned” or you get realistic and pass on the cost to the client. Are you saying you will not pass on the cost to the client?

    Customers are not dumb. Most of the business that big SIs get are repeat business at big existing SAP shops. Are you saying the management of these customers never wisened up in all these years – and just keep paying these SIs?

    Big or small – you have to add value, or you get kicked out. Big SIs also do small projects that don’t have remote teams. And in those cases – they can/will use Agile. RUP is an excellent example – we use it all the time when it is applicable.

    There is no evil campaign against Agile – we just do what it takes to make the customer get maximum bang for the buck. Find a way to do it better than the big SI – and the small SI will win the business. In any case – the scale of projects the big and small SIs chase is so drastically different. Small SIs cannot do the big multi year transformations due to their lack of size, IP and so on. Similarly – for small projects – Big SIs might not find that business attractive enough.

    It is a big enough pie for ever one to share.

  5. Chris Paine says :

    Vijay – Best Friends 🙂

    but to answer your question.

    Yes, you have to charge the customer for the time you take to build. My point is that with large international teams based in low cost locations, as you yourself mentioned it is very hard to allow for the agile process of iterative builds. Instead with the waterfall process and stricter documentation and control process it is possible to ship work remotely. Change is an expensive proposition in a waterfall project – because of all the documentation updates and related processing. In Agile these costs are reduced – but the cost benefits which larger SIs are able to gain by having lower cost development overseas are – as you said – very hard to achieve.

    For this reason I think that with a large part of the competitive advantage that large SIs currently enjoy, coming from their ability to use a highly skilled but low cost remote development teams, will diminish as companies try and move towards an Agile approach which benefits from the co-location of development and customer.

    This is why I (albeit with my cynical hat caveat) said I think large SIs will not want to promote Agile over waterfall – because with it goes a the ability to quote for a lower overall waterfall cost.

    As to other points about customers being silly and rehiring the same teams over and over again. Customers are not silly – if you are good, you’ll be back – but that’s not to say that cost is not a factor. I have also heard of project teams being told by procurement that they had to with the lower cost option even if it wasn’t the SI they wanted.

    For good people – there is plenty of work – I’m more than happy to share – and if Agile takes off – I think I’ll be sharing even more 😉

    Thanks for the debate!


  6. Dagfinn Parnas says :

    Since there was some confusion about my role and company affiliation, I thought I’d put the record straight.

    Sorry to say this, but you’re wrong again Ed. First you mispronounces my name, and now you get this wrong. Don’t feel bad though, Craig also thought I was a customer untill sapphire and now feels he has wasted way too much of his kindness on me 🙂

    I am a consultant at Bouvet ASA where I have also served a term as employee-elected member of the board. Bouvet is a Norwegian consultancy company with 600 employees and just started up in Sweden. We’re an SAP Service, Channel, Education and BusinessObjects partner with approx. 80 employees working with SAP. We have a very flat organization and a very good cooperation with other service areas such as system development, system integration, portals, application management and technical Infrastructure.

    Fun fact: The company is named after the Bouvet island which Norway owns even if it’s on the opposite side of the world. (Google map:

    However, you’re right in that a lot of my experience with agile come from one particular customer where I’ve been working for several years; namely the oil company Statoil. Here I’ve been working as part of a project run by the customer. Statoil has embraced a lean and agile way of thinking in a lot of areas, from budgeting (beyond budgeting) to their software development methodology. They’ve realized that going agile with their software development methodology has a great impact on other parts of the organisation, from decision makers, to HR and facility management. Agile will make the waste of your organisation visible, but in order to improve you must be willing to change your organisation. This is also why I believe once you get really serious with Agile, you need to have your corporate champion. I believe SAP has seen these challenges as well in their organisation.

    For SIs (small or big) running projects for the customer, the added complexity of the legal contract means that it is difficult to have focus on working software instead of contract negotiation. It’s hard for SIs to change the customer organisation and therefore it is extra hard to run agile to the full potential. This is not an excuse for not running agile, you just need to be more aware and better trained in the agile way. On the contract side you need to make sure that the customer knows what is expected of him when running agile, and here are a few suggestions I added to Vijay’s blog:
    “- Changes to functionality not started is free of charge
    – Changes in priority of functionality is free
    – New functionality can be added as the project proceeds, as long as similar sized functionality is taken out
    – The customer can cancel the contract at any time, in this case 20% of remaining cost goes to vendor (in Norway 4-6% is recommended)
    – It is required that the customer prioritises all functionality”

    Thanks for the great discussion. Especially some of the new insights from SAP (Thomas) and Adobe (Dan) was very interesting.

  7. Mark Chalfen says :

    Some interesting points here.

    The key point that I would like to emphasis that has been made is that the whole of an organisation needs to be thinking and acting AGILE for an AGILE project to work.

    You cant just ringfence the implementation team, and say only they need to be AGILE, all key business users and senior managers need to be bought into the methodology.

    I cant see the points about the size of the consultancy or the project.

    You can have a massive project 100 plus people using AGILE. They obviously wont be in 1 scrum, but a number of scrums, and the integration and programme management becomes more important.

    I think change in AGILE is easier to implement. You have your agreed stories, linked to a backlog. The backlog is prioritised. If the business want to change, they need to add it to the back log, and where appropiate amend the prioritisation, so the change can be applied to a relevant scrum.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: