Summary
Agile project management methods address especially the inflexibility of a fixed scope in long running software projects by making the scope variable. How this is achieved and what it changes for the ABAP developer I want to show in this blog article.
Agile programming is of course not the definitive solution for all problems in SAP projects and there are also some pitfalls, especially when extending and adapting a big system like SAP - well a greenfield project is generally easier to plan. But especially the possibility to change the original specification gives the development team the possibility to contribute more than simple coding which finally can lead to better project results.
For ignoring agile approaches they have too much potential
I would never recommend to blind adopting agile programming and agile project management in SAP projects but would also beware of ignoring the agile methology only because the few drawbacks and pitfalls that certainly will coming up. For ignoring it, it has too much potential in improving the whole project life cycle.
As agile methology is such a wide field, I will focus in the following lines only on the role of the scope in agile projects and such sweet things like Change for free, which can contribute a lot to a successful project. One of the most important thing to get a variable scope is a specification that enhances it. I skip this topic for now to get this blog not too long.
Agile methology of course will not solve all your problems but as my coach a lot of years back teached me with a sense of humor: The agile development approach is also not perfect, but it is the least evil of all approaches.
Introduction
Developer:“The customer wants an information system for his sales representatives? Let’s give him a cool Fiori frontend like in the project X, then the representative can access the information about his customers also on his mobile?
Project manager:“Well, fantastic idea, but that is not part of the negotiated specification. And two years back we didn’t know about this Fiori stuff.”
Developer:“Why we need a Z-table for this feature. I know it’s written in the functional specification, but why we do not make it like we did for the other project by using BADIs”
Project manager:“No, we have to deliver it like agreed at project start with the customer”
Developer:“If we wouldn’t implement this feature, which in my opinion he will rarely to never need, we would finish one month earlier.
Project manager:“Well, but than we do not fulfill our contract”
These are some dialogues between developers and project managers that often occur in traditional managed projects. At the beginning of the project there is something agreed which is hard to change later in the project when you have more knowledge and information what the customer really needs.
The below probably well known cartoon shows in a funny way how a lot of software projects are emerging over time. Especially long running projects, for example SAP implementation projects, have mostly beside others the following characteristics:
- There are a lot of people of different areas involved. With a lot of people there is also the risk of misunderstandings
- The customers has little to nothing knowledge of SAP
- The supplier has no detail knowledge about the customers processes
- The customer's requirements changes over time
- The developer do not know all details about the selected technologies
- .. and so on.
So there is nearly always a big shortage in the knowledge about the ideal project goal and its impossible to get rid of this shortage in the short planning phase.
Business requirement management - the different views
Source: ProjectCartoon.com
Well, the cartoon of course pushes too hard on the topic, but it is a fact that in long running projects especially in the beginning the stakeholders view on the desired goal differs sometimes widely.
So how to handle the need of a detailed specification as part of the negotiated contract between customer and supplier and the changing project goal during the project period?
Managment does not want a fix scope, they want fix cost and fix schedule
Traditionally a software project starts with a specification or design phase (something about 20% of the whole project duration). Nothing wrong about this also from the perspective of agile project management. To start a project without a common specified view of the desired goal would be not a good idea.
The output is normally a large specification document and maybe a POC. But unless the project members on customer and supplier side have done a lot of similar projects before they will not be able to define all desired features in the initial specification in a granularity and completeness that the scope stays carved in stone.
The project management triangle - traditional and agile approach
In the traditional approach of project management there is a fix scope. But Projects do not run like initially planned, so you normally have the possibility to change the Cost domain, for example by additional developers or extra hours or the schedule by moving the project finish date.
The agile approach leaves cost and schedule fixed. That's of course desired by management (in budget and in time is mostly their primary focus). So if two of the three domains stay fixed the scope needs to be variable.
That means for example descoping the non essential features or to focus first only on the critical elements of the agreed use cases. (of course the skipped part have to be delivered afterwards).
But also if a project stays in time and in budget the possibility to change the scope has a lot of advantages. As a developer you can decide to bring in new ideas. Customer and supplier can much easier replace a feature in the scope because from the start of the project the fact that scope will change is considered. In agile approaches this is known as "change for free", which means that a change of a feature has not that much of additional cost like in traditional approaches as the functionality is not already fully specified and probably a lot of specification effort for features which are finally not needed is avoided.
But what advantages has agile programming for the ABAP developer. If the company takes this approaches serious there has to be some invest in the beginning of the project in tooling which facilitates robust and changeable code. But when done right, this will pay off more and more, the longer the project and the relationship to the customer lasts by avoiding extensive maintenance costs and much more important to be ready to integrate the changing business needs of the customer into the delivered software.
Its all about avoiding the creation of ZSmaug.
Abap objects, testing tools like Unit tests helps a lot to make the code robust and even Mocking frameworks are evolving in the ABAP area. There are also a lot of quality tools like the ABAP code inspector. And even continuous integration and continuous delivery frameworks like Jenkins are already touched as far as I know.
Finally it's all about to avoid the creation of the dragon ZSmaug (similarity to the dragon in the hobbit is not intended). These custom Z-program with thousand of lines sitting on a deep golden treasure of functionality which nobody wants to touch as the danger to awaken it the dragon is not worth getting changed some of his well preserved treasure of functionality. So normally the dragon is kept asleep until there comes a young brave, fearless developer who wants to adapt some of the functionality and wishes he would never had touched ZSmaug, which then spreads all the hidden smoulder.
I know it is not that easy to apply all best practices of agile programming on a SAP projectand in a lot of circumstances it is not possible and sometimes also not constructive to use some agile methology. But I am sure that a bit of agile programming makes also SAP projects more successful.
As this is for sure a topic that does not has a unique solution and of course different views I am waiting with eagerness on your comments. I hope you could get out some helpful ideas and that I can get some new insights about the following discussion.
Regards, Andreas