Not familiar with project Ernst? This is the second part of a series that follows a project with the purpose of creating ownership of each team’s code base. The story is told as it happens, which means that this is the first report on progress so far. Before reading on, I would recommend you read the first part about Project Ernst.
The project's first sprint goal for the teams was to produce the following artifacts to be presented at the sprint demo:
- domain architecture
- component flowchart
- identification of problem areas (bugs, friction, complexity, knowledge insulation)
- a prioritized plan
To accomplish the goal the teams were allowed to allocate 50% of their time for the project, which they chose to use in a few different ways. Some teams started off immediately with the task to map their code base, while some postponed the work until later when the other 50% of tasks was done. Most of the artifacts created was simply photos of whiteboard notes and issues in Jira.
Depending on how the domain experience was for each team, the domain architecture session looked a little bit different. For those with low domain knowledge, this session was very useful as an opportunity for reflection and education, as the more senior (on the domain) people got the opportunity to think while explaining and the more junior (on the domain) people could immediately give feedback on things with improvement potential. Practically this session took an afternoon with the team using a computer with the code base and an huge whiteboard. For those teams with more knowledge and experience this session was a bit shorter and more hands on.
As one of the underlying goals of the project was to take us a step away from a monolithic code base and a step closer to micro services architecture, component flowcharts is a key to identify potential services. In order for the work not to be overwhelming, it was concluded that the optimal way was to do it in two stages; first sorting and isolating modules clearly and after that create the micro services suited for the modules.
For some teams the code base for several different domains is shared. So, they discussed the best way to isolate their domain and communicate via interfaces instead as a first step. The next step would be able to replace those interfaces with isolated micro services.
A tool used during this session was NDepend, which is a tool that can be used to visualize connections between classes, methods and projects. This can then be used to find areas that are possible to divide into micro services or just areas with too high coupling that need to be simplified and refactored (spaghetti code).
Identification of problem areas
Problem areas can be divided into two parts: users experience and team experience.
For the user experience, the teams used a comprehensive mapping of reported bugs as connected to actual classes and methods in the code made by Johan Ludvigsson at the UX department. This was a very good compilation to start with when the teams started to identify and prioritize the areas of pain points for the users. The teams agreed on a solution to build more comprehensive bug logs with system info, instead of throwing exceptions when something went wrong.
For the team experience one frustration and a major problem with having monolithic code base is compilation time. To address this problem Josef Gustavsson built a simple application, integrated with GitHub, from which, given a repository and its contributors, built a color-coded tree displaying the current solution and where team members has collaborated and also how many commits/changes each file has. The color-coded tree can then be used to identify which files or modules that need to be moved in order to create a new file solution that contains only the necessary projects for the team in question.
To spread knowledge from the more senior team members, the teams agreed that the format of the domain architecture session was a success and something they should keep up/doing on a regular basis.
The last session we summarized all previous sessions to draw up a priority plan. The output was entered issues in Jira with rough estimates so that the team were able to choose which of the two issues they would do in the next sprint.
In conclusion, it should be said that the output from the sprint was impressive. All teams had assimilated the Ernst challenge in bravura and delivered a really comprehensive sprint demo. Next up will be sprint 2 - secure two load-bearing walls.