After the year I started the discussion:
And after gained voices in discussion like above and practical project experiences as well it is the right time to make some kind of summary. I like to present it in a few short articles about practical aspects of the use of Agile on SAP projects.
First I like to say IMHO that I can understand today’s trend to name Agile approach as better than waterfall - Agile approach has become the buzzword and that is natural and “trendy” now. For professionals however it should be clear that Agile is complementary approach to waterfall and both of them have pros and cons. Like I wrote already in one of my previous posts:
Agile and waterfall can be presented like extremes on line between safety and creativity. According to the set of best practices described in PMP or in the PRINCE2 methodology this is the job for project manager to engage the most optimal method what means to decide where to put the balance between them both on the project to organize the work in most optimal way. That means that for various circumstances and depending on the subject of the project the balance can be set on different points on that line. And this is the logic behind the ASAP 8 Agile methodology from ASAP - the hybrid method that allows to mix waterfall and Agile approaches in the most optimal way on the SAP projects.
While the characteristic of Waterfall is very well known the help in looking for the most optimal position of Agile approach can be found of course in the Agile Manifesto:
where we can find 4 sentences known also as values, as well twelve principles.
Looking on the sentences - for example:
“Working software over comprehensive documentation”
doesn't mean It shouldn’t be documentation at all on the project - as I observe sometimes! Please find the closing sentence of four values:
“That is, while there is value in the items on the right, we value the items on the left more.”
so you can see Agile Manifesto is positioning also as some kind of compromise on the balanced line with the point set more on the left side as in Waterfall what is clearly to seen in the sentences on the right.
And coming back to the SAP projects: it is hard to believe that on wide ERP project SCRUM or XP can be apply as the main methodology – from obvious reasons like I wrote in:
especially with expected “working software” at the end of each sprint. But SCRUM may be successfully applied by ERP implementation by subprojects or in some part of it (like interfaces development) where the conditions will be adequate. However there are very interesting results by using SCRUM-similar timeboxed (like weekly) defined Work Packages:
That means Waterfall as the main framework but the work during the whole project organized SCRUM-like (with the all stuff like artifacts and terminology).
But beside of ERP all other SAP components are very good or even perfect subjects of Agile approach. The Business Intelligence components can be perfect subject for SCRUM application. Another example is SAP E-Recruitment component:
For both of them making more than the lean blueprint is simple waste of time and money and for both of them even SCRUM can be applied.
In my next point I will comment right the above named value form Agile Manifesto - blueprint as a form of contract between parties for the project delivery.
I will contnue.