How seerene improves agile software development

Apr 10, 2013 | CIO Knowledge

Software development is one of the most complex tasks that exist. This is why projects regularly exceed budget and deadlines. In the past it was assumed that software projects can be planned from the beginning to the end. But modern software development methodologies assume that project plans or technical concepts that have been made in the beginning, have to be altered and modified with high probability. Due to changes of requirements and challenges that arise, which no one expected in the beginning. These new software development methods are called ‘agile software development’.

How agile software development works

Agile software development methods are based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.

A widely used method in agile development is Scrum. In a nutshell, Scrum works as follows:

  • The Product Owner defines the business requirements for the software at a very abstract level, described as user stories. A user story is complete in itself, and appoints a task that the user wants to perform with the software. It doesn’t describe how the software has to look or how the requirements will be implemented.
  • Once the Product Owner created all user stories, they are prioritized and presented to the “Scrum team”. The Scrum Team is a team of developers that can be compared with the semi-autonomous work groups in the automotive industry. The Scrum Team looks at the user stories and evaluates how much effort it will take to implement each user story.
  • The actual software development takes place in “sprints”. Sprints are periods of about two weeks. Ideally at the end of a sprint a new functionality has been completely implemented. This proceeding is supposed to prevent projects from the situation that after many months of coding nothing can be shipped because essential parts are not completed.
  • At the beginning of a sprint, the Scrum Team determines which user stories will be implemented in the sprint. Every day there is a short sprint meeting where the progress and challenges are discussed. Only at the beginning of sprint requirements and technical implementation a user story will be specified. This has the advantage that adjustments and changes are already included in previous sprints and thus the creation of comprehensive concepts that are already outdated at time of implementation will be avoided. Ideally, all planned user stories are implemented at the end of the sprint. If not, uncompleted user stories will be completed in the next sprint, in which less new user stories are planned to be implemented.
  • A central element of the Scrum method is transparency. In reviews at the end of each sprint, the progress, encountered challenges and optimization opportunities are discussed. For example if not all planned user stories of the sprint were completed, it will be analyzed what has been the reason for not finishing the user stories, to improve planning accuracy for the future.
  • The project completion is documented in charts, in which for example not yet implemented user stories move from the left to the already implemented user stories on the right. In this way, all participants can gain a quick overview of what has been achieved and what remains to be done.

In comparison to the software development methods from the 1980s, 1990s and early new millennium, the agile software methods are a quantum leap. Whereas in the past at the beginning of a project, a lot of specifications and documents have been created, which partly had to be completely revised at the time of implementation, agile software development methods assume that things happen different than originally planned, anyway. So it makes sense to define details as late as possible and to involve disturbances in the process.

Evaluating code quality in agile software development

Agile software development primarily focuses on the changeability and extensibility of the software. Most of the time in the first sprint the functionality is only prototyped, to get feedback from the Product Owner as soon as possible and adopt the software accordingly. Therefore it must be possible to adapt and change the code easily.

This leads to the question: How do I manage to develop code that can be easily reshaped again and again? Agile development could be compared with pottery, where the clay becomes molded over and over again, until the clay shapes the perfect sculpture. Therefore the challenge is to keep the code from the beginning malleable. This is only possible if complexity is kept low so that the code is easy to understand and can be well structured instead of implementing monolithic code units.

To evaluate the code quality, agile development methodologies consider only code reviews. That means the code of one developer is reviewed by a second or third developer. Unfortunately code reviews are rather time consuming and thus expensive.

Managing code quality in agile software development

The role model for agile software development has been the automotive industry. In the 1980s, the automotive industry realized that it is much more cost effective when an employee who has discovered an error stops the assembly line, instead of taking apart the car after assembly again to remove the defects. While errors in the assembly can be easily removed in the automotive industry, because a part can’t be mounted or a lamp does not come to light, that brings up the question, how errors can be found in something as complex as software?

Besides error messages that are reported by the development environment at the compiling phase, the Scrum method doesn’t provide much support. According to the Scrum method, the quality of the software is analyzed in a sprint review after a sprint. How that is done, is however not defined. Even the numerous project management software solutions that support the Scrum process quite well, provide little help here.

To assess how stable, how easy to maintain and to extend the software is, it requires a code review. And here we are again at the typical software development project problems, which we have already reported on in this blog: A code review is time-consuming and complicated. Especially for large projects and when time pressure is added, it is simply not done in an appropriate way. And here again seereneTM kicks in.

How seereneTM helps in agile software development

With seereneTM automated code reviews can be performed after each sprint. These show the exact level of maturity of the recently developed functionality. SeereneTM shows exactly in which code segments refactorings in the next sprint are useful to keep the long-term costs for maintenance and extensions as low as possible. With its software maps seereneTM therefore fits perfectly in the transparency idea of Scrum.

For example if the software maps become posted to the other charts of the Scrum method, the entire management team can identify the fields of action at a glance and include them in the planning of the next sprint.

Pin It on Pinterest