Agile vs. Waterfall – creativity vs. responsibility? Part III of MY evaluation of Agile as the method for SAP ERP implementations

October 14, 2013 Waldemar Falinski

My personal view is that both method waterfall and Agile are very good and matured. They are different and they have pros and cons in each particular situation. My point is that for SAP ERP implementation the waterfall approach is right. Agile is perfect and may be much better than waterfall for many other components of SAP landscape but not for SAP ERP.

 

I am sure it’s very good that we have now Agile ASAP. I think however that there is need of clear message about the positioning of Agile and conditions to use it. I found something at the end of the material but I think it is too soft formulated (page 14th – “Discussing Agile Fit”):

http://scn.sap.com/docs/DOC-14725

 

I like to make now the last part of my evaluation of Agile as the method for SAP ERP implementations - I like to discuss the accents (pros and cons) of both waterfall and Agile in  terms of creativity, responsibility, flexibility, sustainability and reliability. Once again to have it clear: writing in this article about SAP ERP implementations I mean only the area of core ERP and only big implementations (no RDS).

 

Please let me make more general reflections prior to the evaluation. Agile is not something new – is more than 50 years old due to:

http://en.wikipedia.org/wiki/Agile_software_development

from other perspective Agile is the successor of so called “Spiral Model” as described in Wiki:

http://en.wikipedia.org/wiki/Spiral_model

Please note that in the linked description is following statement:

 

“The spiral model is mostly used in large projects. For smaller projects, the concept of Agile software development is becoming a viable alternative.”

 

Agile is the method of development in small groups (to 9 stakeholders). In fact Spiral Model repeats (putting this very rough) in cycles the waterfall sequences with all necessary formal regulations. Agile is focused on developing without a detailed specification. The term Agile was introduced in 2001 in “The Agile Manifesto” - that’s interesting because many known formulas of Agile like Scrum were defined sooner (1986 or 1995 depending on criterion). Note that SAP is adopting Agile for ASAP in Scrum formula – that is probably the most “conservative” with the duration of sprints to 4 weeks.

 

So why just now Agile is becoming so “trendy”? – its clear consequence of SOA architecture. Many components like BO, CRM and so on became independent and may be fully independently implemented as parts of big business landscape. Their nature makes as consequence that typical “waterfall” approach in ASAP may be not efficient. The Agile implementation approach is very effective for them and that is the reason that adoption of Agile into ASAP is the right move.

 

The main advantage of Agile is the flexibility that allows creativity. The documentation is left for after-the-realization phase. That all suits very well for components like BO, CRM and similar. The attitude of potential stakeholders is in these areas in the rule very open and creative. That makes Agile the right way of doing the implementation.

 

Lets look on the ERP in this context now. SAP ERP has become now more compact since many areas being in the past parts of it emancipated into separate components. However even the nature of very core area of ERP (FI, CO, MM, SD – counting only the main parts of core) are in this way integrated and specific that in my opinion makes the use of Agile for SAP ERP implementation (as well as every other big ERP system) very risky and hard to manage. In short words: ERP is still the same!

 

I like to draw your attention, that core ERP area is in fact still the wide accounting system – where every business event is valuated and the effect of the valuation is registered into books (ledgers). There are still valid requirements for: reliability, audit ability, traceability and that all connected with clear defined responsibility. All factors above make that the design of the system in this area has to be very well considered and diligent. That leads in consequence to the conclusion that ERP is area where the complete design before realization is necessary and suitable.

 

From other perspective: how to proceed incremental with ERP? – making the system with only part of accounts, tax schemes and only some groups of business partners or subset of material master? How to prepare reliable test under these circumstances? Its clear that it will not have much sense and will cost a lot in term of time, motivation and confidence. That is why I am sure for ERP area only the waterfall method is the right one. And as I wrote: after dozens of implementations I observed or participated in: it worked very well with waterfall so why to change?

 

The big implementations of SAP ERP mostly require dozens of stakeholders – but the right Agile team should not exceed 9 participants due to definition. So probably the Agile is suitable for the use inside implementation teams? Yes - I think that can be – if of course reasonable - but only during the blueprinting phase to test some possibilities. Then the blueprint has to be agreed among the whole projects – there are too many interconnections to allow the uncontrolled change after blueprint has been approved. Since there will be several implementation groups using Agile in the whole sequence design/realization/testing, it may lead to the situation that the cycles between them will be not sustainable and the control of synchronization will be lost.

 

Another thing is: there are some components of SAP ERP implementation like interfaces or some pieces of customer add-ons that may be treated separate. Agile may be very effective way of doing this as I wrote already in one of my previous posts.

 

Everybody who made big ERP implementations knows that it is very hard to take the right audience of key users and management and to compile the right (in terms of the level), complete blueprint synchronized between teams. I wrote already about in:

http://scn.sap.com/community/asap-methodology/blog/2012/10/14/i-am-sure-agile-is-not-for-big-sap-erp-implementations-part-ii

Please note that often the stakeholders (key users) of ERP implementation are not available in sufficient extent. They not always have the right attitude and understanding. Starting the ERP project with Agile may open the Pandora box with unexpected requests and situations or simply misunderstandings that all together may lead the project in very uncontrolled direction (or directions). Sometimes – especially in the public sector – even the stakeholders do not see the creative way of making implementation as the right. They may find the “make and try” approach as the symptom of weak product or weak consultants!

 

That means that there are many reasons to carefully consider use of Agile ASAP on SAP ERP projects.

 

PS. Dear Readers of this article –if you find it usable for you please award me wit “like” or even rank with stars! This article is effect of my evaluations with the target to create small focused on most important aspects implementation handbook: I will be grateful for every critical comment – for the essential ones I can make award in the discussion: http://scn.sap.com/thread/3247605

 

Best regards

 

Waldemar Faliński

Previous Article
ASAP Methodology in practice: involvement of users as the condition of ERP implementation success
ASAP Methodology in practice: involvement of users as the condition of ERP implementation success

Because of my research I am looking for projects with troubles to identify the reasons...

Next Article
I am sure AGILE is not for big SAP ERP implementations… Part II
I am sure AGILE is not for big SAP ERP implementations… Part II

Requirement of proper blueprinting by SAP ERP implementation: http://scn.sap.com/community/asap-methodology...