Not familiar with Project Ernst? This is the third part of a series that follows Project Ernst. A project that aims to create ownership of each team’s code base. The story is told as it happens, which means that this is the second report on progress so far. Before reading on, I would recommend you read the two first parts about Project Ernst and the first sprint.
Sprint 2 goal
The goal for the second sprint of Project Ernst was to secure two load-bearing walls. Which without the analogy means that they would neutralize two high priority issues identified during the first sprint.
Why not start with the biggest issue?
For us, it was important to actually get a changed state after the three sprints. The risk of starting with the biggest issue is that it’s not certain that you have accomplished anything that is ready for production, and nothing has been achieved (except the mapping) when the project ends.
The first load-bearing wall
Since the teams had different challenges and thus had chosen different types of issues to begin with, the work looked a little bit different. The kind of issues that affects both the end users (in form of inconsistency and/or lacking performance) and the development teams (in form of complexity and maybe low test coverage), may be win-win issues that gives the most effect in relation to the work effort. Two of the teams chose to start with such an issue, which may affect both end users and the team itself.
The second load bearing wall
As second load-bearing wall to address, one of these teams chose to start work with isolating their part of the domain, in order to optimize development speed and reduce dependence to other teams at a first stage in order for a later stage to completely break the domain into separate micro services. One of the other teams instead chose to turn off the opportunity to activate a major feature with low usage to eventually remove it completely.
The work went well for one team, unfortunately, the other team in this example had a release that became time consuming, which meant we made the decision to postpone sprint 2 to the sprint after for this team. Because we work agile, this is no big problem!
A brief summary from Josef Gustavsson – Developer
Sprint 1 – Recap
Dev team focused on several properties:
- Domain architecture
- Component flowchart (dependencies between components)
- Identification of problem areas
- Complexity - functionality to simplify or remove
- Knowledge insulation
- Complexity - functionality to simplify or remove
How to prioritize your priorities
It’s hard to immediately arrive at a solution, especially when it comes to complex issues. In order to prioritize and manage all the tasks under each property we choose to focus on one property at a time.
The “prioritizing sessions” became a great opportunity to spread knowledge among the team members and get deeper understanding of different solutions. While we did discover some issues in each area such as domain architecture and component flowchart, we prioritized more immediate issues that cause a lot of friction and bugs.
Keeping the focus
The goal of Ernst is for the teams to take ownership of the product and steer it in the right direction, that way teams can achieve change of state and create real business value. The idea is that the spirit of Ernst will live on and it’s up to the teams to keep working on changing the current state of affair. If we are to do that, we must first get rid of all immediate headaches and issues, thus focusing on friction and bugs.
Sprint 2 – time to make a change
We began our sprint as we usually do, plan what needs to be done and can be done. The team prioritized one of the so-called load-bearing walls and started breaking it down into smaller pieces, in this way the whole team can work on the same task and it’s also a great way to get a clearer picture of what need to be done.
Trying to optimize outcome
The task related to the issue of how we validate that our databases are not in a wrongful state. When a database is validated it warns of states that shouldn’t exist. If a wrongful state exists, it usually means that we must fix it using scripts and that’s a time-consuming process.
A lack of information
A more desirable outcome of a wrongful state is that we find the underlying cause and fix it before it can cause more wrongful states. But the actual error usually happened some time ago and often we don’t have enough information to reproduce the error.
In conclusion, we fix a lot of reoccurring bugs (wrongful states) and can’t find the underlying issue. Simply put this way of working is both time-consuming and takes a lot of focus from the sprints.
To change or ways we needed to achieve:
- A way of validating the database before causing a wrongful state. If state is wrongful, don’t make the change. Notify the user that the current action it’s not possible.
- Notify developers that a user tried to cause a wrongful state and send the relevant information, making it possible to recreate the situation.
Great, we stopped our self from fixing the database with scripts and it’s now possible to find the underlying cause, and actually rid the database of reoccurring bugs.
One more thing
We also used some of our time to identify and investigate another load-bearing wall that must be improved, unconnected consolidation chains. I won’t go in-depth on this matter because it’s too complicated. Like the previous load-bearing wall, it’s also a bug producer and we felt it necessary to find a suitable solution to stifle the number of bugs it can produce in the future. By doing this we can focus our energy towards changes that bring real business value.
So far so good
These sprints have been very meaningful. They’ve given us an opportunity to make changes that will enable the whole team to change, and the possibility to keep on changing in the right direction.
Next up will be sprint 3 - start the work with the biggest structural change!