The day-to-day business of an ordinary development department often consist of adding new features while adjusting and improving existing features. By the time the features reach production, something else has already begun to be created or improved to be able to shorten time-to-market, or meet internal or external deadlines. Features we thought would solve all problems might initially do so, but over time new features will add to old ones and voilà we are left with multiple features solving the same problems for different users but in different ways. What happens if we just keep moving forward and allow our users to spread across all the features we have created without removing any?
If you don’t take time to remove and consolidate features you might eventually end up with the situation described above, having a Swiss Army Knife of features where changes are becoming increasingly complex and time consuming to do. The features may also be using various techniques that might have been state of the art at the time they were developed, but never got prioritized to be updated because so few used them or because there were more important features to be developed.
At a product company you should always take into account and be responsible for the entire lifetime of the software. The ambition should always be to write software that meets all best practices regarding loosely coupled modules and code quality. And to be able to keep up with the market and be attractive for developers also use new modern techniques. This along with new developers joining with new ideas and others disappearing with domain expertise and knowledge of informal requirements. As a consequence of this, the teams might end up with lack of ownership and a technical debt in terms of a monolithic code base and contradictory business logic, regardless of how talented engineers are at their craft. This state may be called that the engineers work in a so-called feature factory.
How can you make a change?
Inspired after a leadership workshop with Martin Forsman at More Intenz, me and my colleague Samuel Spånberger initiated a project to reboot this state. After having brainstormed around what we want to achieve, we created project Ernst, referring to the, in Sweden famous, handy and amiable interior designer Ernst Kirchsteiger. In his TV show “Sommar med Ernst”, you follow Ernst when he “buys” an old house that someone else has built and gives it love to transform it into his dream house.
How does Ernst address this challenge? He would probably do what we always do:
- Map the property
- Personalize the property
- Create a plan
- Use his characteristics such as being
- Seeing the beautiful
The project is thus an analogy for the teams to transform their code base into their own dream house, where we challenged them to simply “Become Ernst”! To boost the project even more, every team member was given a pin with various tweaked references and quotes from Ernst.
To accomplish a change the teams need time and confidence to create ownership and take control of their own code base. In practice, we gave the the teams mandate to use 50% of the following three sprints (three weeks each) to the project with certain predefined outputs (listed below) after each sprint.
Sprint 1 - Map the property
- Domain architecture
- Component flowchart
- Identification of problem areas
- Complexity - Functionality to simplify or remove
- Knowledge insulation
- Output: The above artifacts + a priority plan
Sprint 2 - Secure two load-bearing walls
- Two load-bearing walls shall be neutralized (set to production)
- Output: Present on sprint demo which walls you selected, why and how
Sprint 3 - Start the work with the biggest structural change
- The largest structural obstacle should be partial or completely neutralized (in production)
- To be tackled incrementally (to be able to put something to production)
- If not completed, a plan must be presented for PO for continued work during the following sprints
- Output: Present on sprint demo which structural change you have chosen, why and how
This post is the first in a series of how to create ownership for a code base. The following posts will report on the projects impact and progress.