Don’t leave broken windows unfixed

The Broken Windows theory was developed in 1982 in the US in the area of crime prevention. The theory describes norm-setting effects of urban disorder. Simply put, it means that if the windows of a building are broken the likelihood of further broken windows increases. This is a metaphor to stress that environmental and cultural settings have a huge impact on the behavior and norms of people.

For instance, if one window is already broken and nobody cares about it, it seems to be acceptable to break other windows as well. Broken windows encourage people to break windows. If all the windows of a building are intact, the inhibition threshold to break windows is much higher. Although the theory was developed in the domain of criminology, it can also be applied in software development projects. I am sure everyone working in IT already knows about broken windows.

Examples of broken windows on a technical level are:

  • Unfixed bugs, e.g. a wrong calculation
  • Violating integrity rules, e.g. microservice design principles
  • Not using ubiquitous language but lots of synonyms and technical slang instead, making it hard to understand the codebase

As broken windows produce more broken windows over time the software might become harder and harder to maintain which sometimes requires a complete rewrite after a few years.

How can broken windows at the technical level be fixed and avoided?

One way is to understand that not just functional misbehavior in applications, e.g. the inability to save customer data, is treated as an error. Violating design principles and coding conventions should also be treated as errors which have to be fixed as soon as possible. These errors are usually not detected by functional testers but by developers themselves and their colleagues. If a developer spots a violation, he/she should create an issue in the bug tracking system. Over time the code quality increases and broken windows are repaired. A culture of constructive criticism helps to foster this.

At the level of agile methods examples are:

  • People not attending standup meetings
  • Teams not delivering what they promised during sprint planning
  • Team members working on unplanned things

Over time the development process might deteriorate and create fewer and fewer predictable outcomes.

What can we do to prevent that?

It is important to address misbehavior when it happens. Do not wait until it becomes normal and is replicated by other team members. Just like a scrum master teaches the team the value of the scrum principles and artefacts and guides them on their way to an agile mindset. Mature agile teams are able to address broken windows for instance during their retrospectives.

People in software development teams are prone to the broken window effect as they do not work in isolation. They align their behavior to the accepted principles of the group. If the group includes bad role models and shows misbehavior or a bad coding style (both are broken windows) the team is likely to follow. After a while the code smells and bad habits become normal (although it doesn’t smell anymore ;-)). Broken windows produce more broken windows even when they don’t produce any immediate problems. Therefore, it is important to fix them as soon as possible. If not, the likelihood of code- or team-erosion increases. If broken windows are fixed on time, the teams and codebase can maintain a high level of quality which is required to deliver software quickly and reliably.

Keep improving…

Decision-making Poster

Agile teams work in a widely self-organized way. This raises the question who actually takes descisions in such a context.
Depending on several factors such as corporate culture the way decisions are taken can differ.
To build trust and support for descisions amongst the team it can be helpful to understand the way a decisions are made.
In order to support that, we created a poster that visualizes the most common models for decision making. It covers the most common decision models single, consultative, consent, consensus and hybrid.
Every model has strengths and weaknesses in terms of speed and sustainability. Every organisation should find the most appropriate model or even a mixture that works best in the respective context.

Visualizing decision models helps to gain insights into the way decisions are made and thus improves fairness and trust amongst the team members.

You can download the poster for free in German and English here.

Bank11 Success Story

In 2016 PLEUS Consulting supported Bank11 in the development of their brand new sales financing system VICTOR 3.0.

Success Story Bank11 is a credit institution that specializes in sales financing. In 2016 the bank decided to replace their existing software with something new. To be able to meet the challenging requirements in terms of quality, customer satisfaction and process efficiency they decided to build their own solution.

The front-ends were developed using modern web technologies such as Javascript, HTML5, CSS and Angular. For the backend Java Enterprise (JEE) and a Sustainable Service Design approach was utilized to design and build a backend with a high degree of reuse and scalability. The service landscape was established using Domain Driven Design principles.

On the technical side, PLEUS Consulting supported the teams as Master Developer and Architecture Owner. In the area of agile techniques, PLEUS Consulting supported the development teams as Scrum Master and Agile Coach. Although not 100% tension free, the combination of those roles worked quite well. With these roles the bank received thorough support in the areas of technology and methodology.

From the beginning we tried to align technology and business as much as possible, creating a people centered architecture. Central to the strategy were BPMN process models, graphical business rules and visual service contracts. In order to create appealing front-ends for the car dealers and the back office of the bank we worked closely with user interface specialists which were members of the cross functional teams. Web stack technologies allowed us to create individual and great looking front-ends. Agile frameworks such as Scrum organized the development teams and created valuable software together with the customer within a short period of time.

The project has shown that with a combination of modern technologies and agile approaches a very short concept to market cycle can be achieved, creating competitive advantages. It also demonstrates that it is possible to establish an agile culture in rather traditional business domains.

You can read more details about the project in the official success story. If you want to find out more come to watch my talks at JAX 2017 in Mainz.

JAX Sessions about Agile and Architecture

Between the 8th and 12th May 2017 JAX will be taking place at Rheingold Halle in Mainz.

On the 8th I am going to give a presentation about Agile trends, myths and best practices. . In this talk I will show why Agile is the way to go and what it actually means to work with Agile rather than just applying Scrum or Kanban rules.

On the 9th I will share insights from a banking projekt in 2016. This technical talk will show how to combine current architectural patterns such as sustainable service orientation, process automation and business rules to create an architecture that evolves around people.

You can see the timeslots on the JAX website. I look forward to seeing you there.