Skip to Content

New agile approaches in application development

In my last blog I introduced the classic approaches in application development and how they have evolved.  As well as the IT architecture and software development tools have evolved the approaches have also evolved.  In this blog I would like to present and discuss new agile approaches with the focus on SCRUM.

Evolution of the traditional approaches

In my last blog of my blog series, it became clear that it becomes more important to adopt quickly and flexibly the IT business applications according to changes of business processes.  With the usage of a SOA platform like SAP NetWeaver and model-driven development tools like SAP NetWeaver Visual Composer, the orchestration of business processes can be realized in an adequate time.

Not only with tools for application modeling such as Visual Composer, it is possible to create applications faster and more flexible. The encapsulation of individual functions in programming libraries for reusability and thus has led to faster application creation as well as the object orientation. In parallel, the approaches have been developed and have undergone an evolution as described in my last blog. The complexity and scope of today’s software projects also contribute to that process and newer models such as, for example, Test-Driven Development and Extreme Programming, are preferred in the IT world in order to complete successfully projects in time, budget and quality.


This newer approaches are used in recent years successfully by the global players in the IT world such as Microsoft, SAP or IBM. So you can always read in the specialized press reports on the benefits of these approaches in application development. Very often it is highlighted that the agile and iterative characteristic of these new approaches have a significant influence to project success. In the following I would like to introduce you to one of these new agile approaches that also use the SAP development. This is as earlier mentioned the SCRUM approach. After I introduced you to the basics of SCRUM, I will discuss its use in application development based on an SOA, and Visual Composer.

What is SCRUM?

SCRUM was introduced and established by Takeuchi, DeGrace, Schwaber and others in the late 1990s. The concepts behind SCRUM are pretty simple. SCRUM is a rough outline of a process, based on iterative developments, and three meetings. It comprises of three roles, three documents, and three meetings as shown in the next figure.


The three roles are Product Owner, Team and SCRUM master:

  • The Product Owner represents the stakeholders, such as customers, marketing, etc. The Product Owner has to ensure that he is representing the interests of all stakeholders. He is also providing the requirements based on the user stories of the customer, funds the project, as well as sign off on any deliverable.
  • The Development team is just called Team. The Team is responsible for developing the project deliverable.
  • The SCRUM Master is responsible for the SCRUM process, running meetings, and adjusting SCRUM to best fit the project and the organization.

The three documents are the Product Backlog, the Sprint Backlog, and the Sprint Results:

  • In the Product Backlog all the requirements are gathered and prioritized in one list as with traditional projects.
  • The development is done in small iterations, which are called Sprint in SCRUM terms. Each Sprint is a small and manageable iteration. It contains design, development, and testing. The duration of a Sprint is about two to four weeks. The goal is to produce a tested and stable deliverable which can be handed over to the customer and put into production by him immediately. At the beginning of a Sprint, the team picks the most important use cases from the Product Backlog that can get delivered in that current iteration. The list of those use cases is called Sprint Backlog. The Sprint Backlog is negotiated between the Product Owner, the SCRUM Master, as well as the Team itself.
  • Those use cases, which are completed during a Sprint, are documented as Sprint Results.

The three meetings are the Sprint Planning, the Daily SCRUM meeting, and the Sprint Review:

  • Each new Sprint starts with a Sprint Planning meeting. The Team, the Product Owner, and the SCRUM Master decide on the Sprint Backlog, based on the requirements prioritized by the Product Owner on one side and what the team can commit to on the other side. The meeting consists of two parts: In the morning the Product Owner presents the most important requirements from the Product Backlog to the team. At the end of the morning, the team selects those items that are going to get delivered in that Sprint. In the afternoon the Team plans the Sprint.
  • Throughout the project, the SCRUM Master moderates a short 15-minute Daily SCRUM meeting every day to exchange what was achieved in the last 24 hours and to discuss problems that need to get addressed. The following will be discussed:
    • What each team member has achieved during the last few days?
    • Which issues were hit and may lead to reconsideration of the iteration plan or design?
    • What each team member is working during the next few days?

    The major goal of these daily meetings is to determine progress and identify any issues which need attention or adjustments of the Sprint Backlog. SCRUM recommends tracking the progress with burndown charts, which are introduced later. On the basis of progress, additional items can be added from the overall Product Backlog to the Sprint Backlog. Or – in case of delays – items from the Sprint Backlog can be moved back into the Product Backlog to be addressed in a later iteration.

  • At the end of each Sprint the SCRUM Master, Team, and Product Owner along with the other stakeholders meet again to review the results achieved during the iteration. This meeting is referred to as the Sprint Review.

Planning horizon in SCRUM

The horizon for detailed planning is short and only covers a single iteration that means in SCRUM terms a Sprint. Instead of building a large plan which includes all the tasks, sizings, and resources for the entire project, only very rough high-level sizings are done at the beginning. More detailed sizings and work assignments are added at the beginning of each iteration only for those items that the team has picked to be delivered in that particular iteration. This is one major difference to traditional waterfall projects, which elaborates plans and milestones to a much larger extent. This aspect of the waterfall approach makes changes of the finalized plan quite inflexible and expensive, especially late in the cycle. In a SCRUM-based approach, project management accepts change as a fundamental planning constraint and does not waste effort in planning beyond the horizon of the current Sprint, since there are too many uncertainties. A long-term plan would be subject to changes anyway. And most important: Such a well-defined plan for the future only leads to misleading and false levels of confidence which no one should trust.

Agile approaches like SCRUM addresses this problem by breaking down a larger project into iterations and really only worrying about the content of the current iteration.  SCRUM provides the opportunity to make fact-based decisions for immediate needs. And it even allows changing the fundamental direction of the overarching goal at the beginning of every new Sprint, if this becomes necessary to reflect changed requirements and add actions to address unforeseen issues.

Tracking the progress with a sprint burndown charts

SCRUM recommends tracking the progress of the development activities and to measure progress towards achieving the given goals using burndown charts. The burndown chart is a graphic presentation of the remaining effort per day for each sprint. The amount of work a team has left to complete within the current iteration is listed on the vertical axis, whereas the time is shown on the horizontal axis. The remaining work can be shown in units of hours, person days, or number of use cases. The remaining effort is collected in the Daily SCRUM meetings in order to update the burndown chart. Ideally, the curve falls continuously (hence burndown), and the remaining effort is at the end of the sprint zero. You can already indentify during a sprint a trend, based on the extension of the negative slope whether the originally estimated effort is enough or not.

For a better understanding and visualization of the SCRUM approach I recommend the video “SCRUM in under 10 minutes”  by Hamid Shojaee.

Or another excellent video which explains the SCRUM basics:

Challenges for Project Managers with agile approaches

Agile application development has several challenges, especially for Project Managers: Stakeholders typically want to know when the project will be completed and what exactly will be delivered. In many situations the customer will only accept a fixed-price contract which requires the software development company to have a very good handle on the total cost of the project; even if it is not exactly planned till the very end.

Does SCRUM allow for a reliable management of overall cost and content at all?

First of all, it is important to emphasize the limitations of the pretended precision achieved with the classical waterfall model: The elaborated project plan of a complex IT project can only make one believe in exact predictions if one expects that no surprises will occur between now and project delivery. I refer at this point to Murphy’s Law „Whatever can go wrong, will go wrong.“. Trusting a plan beyond the horizon of the next few weeks leads you to dangerous blindness. In the final analysis, the predicted cost is still significantly different from the estimate, even if a project is planned to the very last single task. Application development is far complex. Things change during the minds about what they want or need and usually the technology is providing more challenges than expected.

In all complex IT projects, all involved parties need to accept that unpredicted challenges will occur and the final deliverable cannot be fully understood at the beginning of the project. Therefore, the focus of SCRUM (and all the other agile techniques) is not on perfecting the precision of planning, but rather maximizing the ability to adjust planning and respond to change.

The focus of the involved parties is on negotiating only the high-level requirements and major usage scenarios upfront. While a number of key use cases will be committed to the stakeholders, there needs to be some flexibility as to which additional use cases can be achieved. At the end there always need to be compromise between the development team and the stakeholders. The development team commits to certain high-level requirements within a given timeframe. But the stakeholders will also provide the development team with some level of freedom to refined use case depending on the actual progress.

In SCURM, each Sprint is 15 – 30 days long. The length of the Sprint or iteration should be reviewed at the beginning of a project and possibly adjusted for example based on how long it takes to compile and deploy the whole application. A complex product that needs several hours to be compiled may require a Sprint length of five or six weeks, just due to the long deploy process. Here you also see that a good infrastructure that can deploy the application quickly and provide it to test in a matter of minutes or hours is an important component to run an agile project or to make a project more agile. Needless to say that it is important that each Sprint has a predefined fixed length and everything that was not done and needs to be finished up in the next iteration, unless this “almost” done part is a scenario on its own, production ready and can bring value to customer.

Is SCRUM ideally suited for application development with Visual Composer based on a SOA?

I remember that my friend Luis have written in the past a blog called Visual Composer Apps delivered “On-Time”. Luis has quoted my friend Mario, who is author of the first Visual Composer book. Mario have written in this book “Modeling is an art, with any art, there are many ways to do something … “. I fully agree on this thesis, but I think that you should choose an approach that takes advantage of the benefits from SOA and Visual Composer. As I have mentioned in my previous blogs the benefits of SOA-based application creation with Visual Composer is the rapid creation of applications. In my opinion this fits perfect to the SCRUM approach and its concept of the Sprints.


I come to the conclusion based on my experience that the new agile approaches are the best for application development with Visual Composer and a SOA, because as I have mentioned you can take advantage of the rapid application creation. That means the end users have the chance at the very beginning of the project to have a hands-on to the application. Based on this hands-on the development team gets a feedback very early from the end user and can make sure that development goes into the right direction. This saves not only time and money, because misunderstandings of the requirements and wrong expectations of the end user are eliminated in a very early phase of the project.  The iterative approach also makes sure that the development is on the right track, which leads to the expected quality. And finally the project is finished successful in time, budget and quality.

You can find this weblog in German language on the FIVE1 Blog

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Former Member
    I came across the scrum methodology recently while managing a web application dev project. I have a few queries on scrum approach:
    1. I understand it is for emerging/ changing requirements. However, do we need to freeze the requirements selected for a particular sprint?
    2. Is it strictly one sprint-one iteration relationship?
    3. I feel that we can use the sprint approach for any project (e.g. maintenance, support etc.)status monitoring. Is it correct?

    I would appreciate answers to these issues,

    Thanks in advance


    1. Former Member Post author
      Hi Vinay,

      based on my experience and my understanding of SCRUM I answer your questions:

      1.) In my opinion it is necessary to freeze the requirements in a sprint in terms of the defintion of a use case. Of course you can add additional use cases to the sprint backlog and remove a use case if the time is not sufficient, but I strongly recommend that these happens not every day otherwise your sprint is not set up correctly resp. you loose the control of the sprint with the result that no use cases can be put into the sprint results.

      2.) This depends on your project and the requirements. If you develop a big complex product like the SAP NetWeaver Portal you can have several teams that are working in parallel in different sprints. But for the teams and the dependencies you should have one sprint after the other.

      3.) You can use the SCRUM approach for many projects, but of course it depends on the project and the main focus of SCRUM is software development. I think it will be difficult to use the SCRUM approach for support of a system because the issues from the user are reported when they are occur and that is the reason why I think it is impossible to define the product backlog and the sprint backlog. I think SCRUM is the best for projects that are developing software or a system integration project.

      Hope that helps!


      1. Former Member
        Hi Marcel,

        Thanks very much for the detailed reply (as also for starting the blog). It does really help in clarifying the concept. As a matter of fact, I am currently handling an SAP netweaver portal based application dev project and we have adopted the Scrum methodology for its execution.(Though the requirements are more or less frozen and baselined)
        As regards my point # 3, what I really meant was using the Scrum approach just for daily status monitoring for other types of projects; I like the idea of 15 min standup meetings with everyone disussing only what was targeted, what was achieved (and new estimate to complete), what is the plan for the next 24 hrs and if there are any roadblocks, issues anticipated (which would be noted and addressed out of scrum meeting). I feel that this creates an atmosphere that promotes a free and transperent discussion, easy to track the progress and brings up the issues that would otherwise be considered not so critical to be formally tabled. 
        Regards point # 2, I have just one team of 7 (one of them designated as product owner). In that case I suppose we should have one iteration in one sprint with requirements and use case definition frozen for that sprint. Hope my assumption is correct (especially as I have said before the requirements are not very much dynamic)
        Thanks again for initiating the blog and answering the queries.



  2. Isaías Cristiano Barroso
    Hi Marcel,

    Congratulations for this post, I consider it as the best one on SDN,
    SCRUM is a great topic to explore on SAP World, many person have the wrong idea that SAP don’t is compatible with Agile.

    Hi Marcel, thanks for this great blog.
    Tipically nowadays most projects are fixed-price projects, where deadlines and effort are usually not supposed to change. How would you adapt scrum in this situation?
    Thanks, regards
    1. Former Member Post author
      Hi Vincenzo,

      of course also with SCRUM you have to do some estimation for the project costs. You can not do several sprints for the next years in order to deliver a hello world application. Anyway, it always depends on the size of the project and your experience in order to make a good estimation of the costs.

      I have worked the last years in an international project in which a lot of companies were involved and that project have needed several years. At the end the budget have been overrun. Why? – Because everything was planned without knowing the details and the requirements for that long term period. In my opinion it’s not possible to make an exact estimation for such big projects. You can only make assumptions. That is the reason why I recommend to go for agile approaches like SCRUM. Planning short term periods with quick wins and having all the necessary flexibility if something unpredicted happen in the project. For the whole big project you can only make assumption and guess the total cost based on estimation for all parts of the projects, but you should accept that you can not make an exact estimation for big projects that will need several years.


    If i use Scrum in a SAP Netweaver Project (ex: portal + mdm + pi)I can use Sap Solution Manager for Scrum or there is other SAP’s software for it?
    1. Former Member Post author
      Hi Rocco,

      I think I have heard or read in the last years that there is something called SAP SCRUM, which is a kind of project managment tool for projects that are based on the SCRUM approach, but I’m not sure if this is part of the Solution Manager or another component. Anyway, you can use Excel or another project management software that supports SCRUM.
      I think for the success of a SCRUM project the used software plays a minor role.


  5. Former Member
    Hi Marcel,

    thanks for this blog. I’ve read a lot about scrum and agile techniques outside the SAP-world. It’s good to read something from inside now.

    Unfortunately I had no chance to participate in a scrum project. But some of them seem to me, that they had worked better with scrum.

    Another topic that should be mentioned are the retrospectives at the end of a sprint or at least at the end of the project in order to remember what was good and what went wrong.


    1. Former Member Post author
      Hi Dirk,

      thanks a lot. I fully agree with you that after a sprint a kind of lessons learned session should be part of the Sprint Review Meeting in order to improve the approach itself.


  6. Former Member
    Hi Marcel,

    Just to share with you. We are using scrum with two small teams working on customized Abap development in our company since November/09. Our main goal using scrum with these teams is to deliver faster most important functionalities, and it is working  pretty fine with the first team (six months working on it) and not so with the second team (only two months working with scrum).
    The main aspects we noticed that helps very much is the team commitment with the new methodology and the team desire to make it happen.
    We are improving (and learning) the process, adjusting some pain points, but in general we agree that it has been helpful.

    I’m particularly interested to see your answers to the questions already posted. Are common questions that I listen every week.



    1. Former Member Post author
      Hi Roberti,

      thanks for sharing your experience in the last months of using SCRUM. I think also always improving the process itself helps a lot.
      In my opinion an agile approach must allow also the adjustment of the approach itself. Sorry for the delayed reply of the questions. I’m just back from skiing holidays without any internet. 😉


  7. Former Member
    Currently been using Agile Scrum in our company as a pilot for a data management project.  The process works very well as long as all team members are committed resources and are not impeeded by other projects competing for the same resource.  We have a load of product backlog and use 2 week sprints in order to develop, test and at times automate the QA portion of the work in testing.

    Main thing is getting everyone “onboard”, so that the scrum method works properly.  We’ve found that we self correct and redirect as needed without much inturruption.  The test now is to push our release into production when other projects follow Waterfall and don’t necessarily take the same approach for release as our scrum team.

    One big point is the atmosphere is fun, as DEV,BA’s Business Power Users and QA are all located in the same workspace. We also have support teams offshore that turn work around the next day.
    Good times and a nice change of pace !

    1. Former Member
      Hi Eric,

      thanks a lot for sharing your experience with the SCRUM approach. I can confirm that the atmosphere is even better with that approach, but of course it also depends on the team.



Leave a Reply