In my Scrum Master courses I often feel the frustration. The participants tell me about the challenges they face when introducing Scrum.
I have summarized their experiences in a story. I’ll also present an alternative. What are the conditions for Scrum to work?
Management has an idea for a project. It takes months until the project scope is defined. Based on the scope, the budget is approved. And the managers’ bonuses are linked to the scope.
A former project manager becomes Product Owner. A developer becomes Scrum Master. The project starts.
The Product Owner talks to the stakeholders. Everybody’s got…
I’ve started a new side project. The goal is to drastically simplify the development of message-driven microservices.
Event sourcing is used as the standard persistence mechanism. In the future, I also plan to implement service integration using Kafka.
The project is called Being. It’s based on the Lagom framework.
Here’s the link to the Being project.
Please leave a comment what you think, or chat with me on Gitter.
I appreciate feedback.
Diagrams as code is a term used for storing the source of a diagram image as a text file. Examples include architecture diagrams, or diagrams showing a system’s behavior or design.
In this article, I will present an approach that takes the term diagrams as code literally. I will show you how to generate diagrams from source code.
Represent the diagrams as models in Java source code. And…
Jackson is a powerful library for processing JSON. It’s the default library used by the Spring Framework. It’s very flexible and configurable. The standard way of configuring it is using annotations in the classes to be processed.
In this post, I will explain how to use the Moonwlker library that I created. It’s a facade to Jackson, and provides a builder API to configure Jackson. That way, you can get rid of anotations in your classes. I will also show you how to integrate Moonwlker into Spring Boot applications.
Before we dive into code examples, why would you want to…
Hi folks. I hope you’re doing good and staying healthy.
I just wanted to let you know that I did a major update of the GitHub frontpage of my long term side project, requirements as code.
My goal has been to improve the description of what the project is about, to clearly describe the proposed application design, and to give concrete code examples to try out.
You can find the project here.
I’d be glad if you check it out. Comments & questions are welcome.
If you want to have a direct conversation, don’t hesitate: email@example.com
Got a bit of time on your hands, and you’re wondering how to use it effectively?
I explain the fundamentals of agile software development and Scrum. How it works and the pitfalls to avoid when getting started.
Watch my online video now on Skillshare:
Everybody wants to be agile nowadays. It’s mainstream.
A lot of companies try. Few succeed.
When a company hires me as an Agile Coach, one question I ask is:
“What are the problems your company wants to solve, by working in an agile fashion?”
That’s a pretty obvious question, right?
You won’t believe how many times the answer was — silence.
Even worse, some answered: “To increase efficiency”.
Agile development can indeed increase efficiency. As a side effect.
Close collaboration and lightweight processes lead to it.
But that’s never been the main purpose of agile software development. …
User stories are a great way to plan development work. In theory. But how do you avoid getting burned in practice? I propose a radically simple approach.
Here’s a popular template to describe a user story:
In my work with agile teams and as a trainer, I often hear statements about user stories that cause problems in practice. Time to get rid of the most common myths.
The Scrum Guide leaves it open how backlog items are documented. I like user stories because they shift the perspective from the system to the user. But they are not mandatory. And they should be used more for conversation than for documentation.
You probably think of: As a user I want function so that fulfilled need.
The user story concept had nothing to do with this template at the beginning…
A hexagonal architecture simplifies deferring or changing technology decisions. You want to change to a different framework? Write a new adapter. You want to use a database, instead of storing data in files? Again, write an adapter for it.
Draw a boundary around the business logic. The hexagon. Anything inside the hexagon must be free from technology concerns.
The outside of the hexagon talks with the inside only by using interfaces, called ports. Same the other way around. By changing the implementation of a port, you change the technology.
Isolating business logic inside the hexagon has another benefit. It enables…