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?
- 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.
Conclusion
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
15 Comments
