JAX 2019: Agile Team Architecture and Big Data

JAX is one of the most known conferences for Java, architecture and software innovation in Germany. Im am glad to be invited this year to give some sessions. Between the 6th and 10th May 2019 JAX will be taking place at Rheingold Halle in Mainz.

Agile product teams are becoming more and more mission critical. On the 6th I am going to give a presentation about the way agile product teams can be built by applying software architecture principles such a resilience and performance to teams.

When people start learning Big Data technologies for many it seems to be complex due to the sheer amount of products in the Big Data ecosystem. On the 8th I am going to show a simple Big Data Stack to get started with. I am going to set up a working stack from scratch and implement a working lambda architecture.

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

Fintech Success Story

In 2017 PLEUS Consulting supported Yareto GmbH in the development of their new independent comparision site for the automotive finance industry.
Yareto is a fintech company that specializes in automotive financing. In 2016 the corporate startup was founded to build a brand new comparision site for the automotive finance industry. The site enables car dealers to compare credit offers in the areas of sales financing and purchase financing. Lenders get access to sales channels they couldn’t serve before.

PLEUS Consulting supported Yareto in setting up a Creative Software Workbench. The Creative Software Workbench aligns technology, processes and people in a way that creates an environment in which high quality digital products can be developed in short time.

The front-ends were developed using modern web technologies such as Java-/Typescript, 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. Operations was performed using cloud platforms.

On the technical side, PLEUS Consulting supported the teams as Lead Developer. In the area of agile techniques, PLEUS Consulting supported the development teams as Agile Coach. The combination of those roles worked quite well especially in the phases of seed and growth. With these roles the company received thorough support in the areas of technology and methodology.

The project has shown that with a combination of modern technologies, agile approaches and the right people a very short concept to market cycle can be achieved, creating competitive advantages. This is what the Creative Software Workbench is all about.

You can read more details about the project in the official success story. More info about the Creative Software Workbench can be found on the official website.

JAX 2018: Management of Requirements and Quality the Agile Way

Between the 23th and 27th April 2018 JAX will be taking place at Rheingold Halle in Mainz.

On the 23th I am going to give a presentation about the way agile companies turn ideas into valuable software in a short time and how this differs from classic requirements engineering practices.

On the 24th I am going to show how agile teams build high quality software. I’ll cover techniques and principles that help to ship software increments to the customer after every Sprint.

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

Agile Culture Cards

People are born with an agile mindset. Many of them lose it throughout their career as they are shaped by an industrial culture which is based on ideas like the lone warrior and error avoidance.

Establishing an agile mindset amongst the team members is a challenging task, especially in non-agile organisations. Behaviours and habits which have been appropriate for many years have to be unlearnt and replaced by new behaviours. Many Scrum Masters and Agile Coaches, including me, work with posters explaining the principles of Scrum, Lean, etc. While these posters are helpful, they are a bit limited as they only show abstract principles. To apply these principles, people must transfer them to specific actions, which is sometimes difficult. To make this step easier I have created the Agile Culture Cards. These cards address certain behaviours directly and offer alternatives. They are close to the reality of the workplace and thus make it easier to understand and apply agile principles.

You can download a deck of Agile Culture Cards from the download section. The cards are currently available in German only.

Agile Culture Cards intend to train an agile mindset on a daily basis.
Feel free to use them as you like. If you have any ideas for more cards please let me know so that I can include them in the next version.

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.