One of the basic principles of lean management is to build quality into the process. Specifically, this means already carrying out quality assurance measures while production is taking place and not after-the-fact as a separate step in the process.

Anyone who deals with Scrum must hear a ringing in the ears. After all, many elements of Scrum are designed to deliver stable quality out-of-the-box in an ever-improving process. When in doubt, functionality can be sacrificed, but deadlines must be met.

What Scrum does not provide for is how to achieve the necessary level of quality. However, most Scrum teams have established appropriate procedures and our team is no exception.

I would like to briefly outline them here.

Every line of code that a developer in our team writes must be reviewed by at least one additional developer. It is only then that the corresponding task may be labeled as “done”, so that at least two people know exactly how this part of the software functions.

This method also has its origins in lean production. In that framework the entire team is responsible for the quality of the product. Every team member must therefore have exact knowledge regarding the separate working steps carried out by another person and, if needed, carry out these steps themselves.

Code reviews are well-suited for exactly this process. This simple procedure is used to distribute information about how the application works throughout the team – without additional meetings or presentations. This is particularly important in large Scrum teams.

We’ve established a similar procedural measure for user stories as well – not from a technological point of view, but rather from a user’s perspective.

Our team is working on an application whose hallmark is an excellent user experience. We would not be able to ensure a high-level UX, however, merely by looking at the code. For this reason, every user story that is intended for inclusion in the sprint review must be approved by our UX architect and our designer.

This helps us to focus our perspective on the user’s point of view of the application early-on in the development process – as well as being able to carry out the necessary adjustments during the current sprint. The product owner, who often deals with requirements in-depth, especially benefits from having at least one person in the team who is able to continuously consider the user’s needs.

As a fringe benefit we have been able to create a design thinking mindset in the entire team by using this process. The result is, for example, that the team questions user stories during the refinement meeting not only from a technological perspective, but conceptually as well.

Keyword: Test Driven Development (TDD). This means developing the test first, then the corresponding functionality.

The advantage here is that the developer must think about the solution before even beginning to write a single line of code. Since the tests at best are based on specific acceptance criteria, it is ensured that, by “fixing” the test, exactly the right thing is being built.

But here the difficulty also comes to light:
It is often difficult to write tests for particularly complex requirements without trying out different solutions beforehand. If you’ve finally found a solution that works, it is also rapidly implemented. Interrupting the implementation flow by writing a test is unfavorable in such situations.

For this reason we are we are not nearly as good as we would like. Although the test coverage of our code is quite satisfactory, it is precisely because of the aforementioned-situation that, occasionally, the tests are written only after the code review has taken place.

This is also understandable for another reason. After all, tests don’t provide a user with added value if the software is currently working. It’s only when regressions are discovered that the benefits of testing unfold.

I remain convinced that we will find a methodology to implement this element with even more consistency. Unfortunately, the development of tests can’t be automated.

Tasks that can be automated offer a huge advantage: One likes to take care of them. Nothing is more enjoyable than being able to move a task to “done” by, for example, pushing a button in Jenkins. And the nice thing is: It’s guaranteed that the process will always be executed in the same manner, which means it’s virtually error-free.

Because of this we try to automate as many tasks as possible.

That our acceptance tests and our build pipeline are automated, is almost taken for granted nowadays. We’re trying to push the envelope here even further though. For example, we’ve also completely automated the screenshots that we need to create for the user manual of our application (in several languages). That wasn’t really much of a problem. After all, we’ve already covered the pages that we need to capture as images with Selenium tests anyway. All we had to do then is integrate a step called “screenshot”.

As one of our next tasks we want to automate the installation on third-party systems.

For some of you this might sound like quite a bit of effort and lots of process. But, the truth is that these measures – when they become matter of course – don’t require a lot of time.

This holds especially true when looking at it from a net gain perspective. The reason is simple: It’s not a lot of fun having to deliver bug fixes instead of being able to work on features. To date, the software in our current project has had exactly one post-delivery bug.

And there must always be one. After all, we don’t want to look like an eager beaver.