In our current project, we use an approach of the minimal viable product and we steer it with the story mapping technique. From the discussions in our team, here are five guidelines (or just one?) for such an endeavor to ensure a better work-life-balance.

This article is about the sports event management system already discussed earlier. For an introduction, you may want to look at user-centred business analyis or a case for features.

The thing to keep in mind is: budget and time don’t match the wishes for features – a not so uncommon situation in software projects.

In such a project, there are two options: One tech lead put us to the first option right away: “We can already start working a sixty hour week, we won’t finish it otherwise!”. This option did not appeal to us, not only would we work hard but we would even not get paid for this extra work. Thus we chose the second option and did what the customer asked for and why he hired our company in the first place: We used our brains, got creative to find a way the software can be build with the time and the money available.

Thus in order to have some private live left: get the scope right. From the experiences made in the project of the sports event management software, here are five guidelines for a better work-life-balance.

(1) Invest into reducing functionality

Find a simpler solution. And then simplify it. Now strip all unneeded things off. And at first only deliver the essential part of this, the basic concept.

Quite often we started with a great idea somewhere between stars and clouds about how the user’s world could be made wonderful and shiny. Of course, this was never feasible within budget.

We had to look closer. What’s the point of doing it? What’s the value and is this in scope in regards to our contract or the overall story? If yes, we got creative and looked for simpler and better solutions. It took some iterations of creating mock-ups and testing them.

Once estimated costs and value came into the desired region, we took the feature forward into development and it changed yet again: we focused on delivering the bare necessities. We learned much better what mattered to users and what we had to add or enhance. And that was really much less than what we started with and users were still happy!

Here are few starting points for reducing:

• Having one powerful story allows identifying functions and qualities that do not contribute to the story and move them out of scope.
• When looking closely at the processes we found steps where system support offers much higher benefit than for others and we preferred such steps first.
• Communicating costs of features to stakeholders changes their priorities.
• Delivering the bare necessities provokes reactions by stakeholders. It becomes quite easy to spot if something really mattered once it was removed.
• Common interaction patterns, shareable components and common structures simplified our design and we saved on testing by isolating them into common code.

(2) Build the system up and scale it later

First we started with the walking skeleton then added as little as it needs to make users efficient, customers happy, and everybody safe enough. Then we started with a limited set of sports events and processes we supported and are now starting to the application of our software system.

This was really one of the insights of this project. We looked at each process and each sports events we intended to support, continuously refined the initial selection and built as little as we dared to. We took care that this little felt and smelt good and provided a slim, functional, fast and good-looking user interface! So while there is just the functionality needed, this functionality is great to use. Once we had the functionality ready for a first, simple sports event, we rolled it out and then scaled to other sport events and more processes.

Thus:

• User story maps align the functionality with the users’ processes and allow to build up the system from the walking skeleton.
• Deliver as little as you dare to support a process and let users work with it. You can see what they really need.
• What you deliver must be promising so users are willing to invest into future enhancements.
• Ask your users and let them do what they are supposed to do with your product, observe them and learn what you need to add (compare with these articles: killing or curing and user story shopping).

(3) Really finish stories, completely

This means: tested and documented code. Not on the dev’s machines, on the test system at least. It also means automated tests, manual tests and deployments. It especially means clean and designed code, no warnings from compilers, style checkers and such tools. It means code reviews done, and up to date team mates. It definitely means that you’re definition of done is fully achieved.

Always sounds quite simple in theory but what is a good definition of done? And how to make the team stick to it? Especially if there is pressure by time and money?

We failed in our first iterations to deliver this quality and it fired back by demanding extra iterations and creating a lot of stress in the team. We failed to stick to the definition of done because (1) we started to rush features instead of slowing down and building a foundation based on some key features and (2) we had some developers in the team that did not deliver quality by themselves, and even some of the leads acted liked this. Btw, I recommend reading the book Momo from Michael Ende for that matter.

We first had to slow down our product owners. It is crucial that product owners concentrate on why all that stuff really matters, get into the creative mode and together with the team find a simple solution.

Second, we introduced story acceptance meetings during the sprints. Product owner and Devs sat together, looked at the story, the automated and manual tests, the code, the documentation, the translations, the performance and made sure it was finished. And only then this story was allowed to proceed to our testers. After a few sprints, developers and product owners started to interact more frequently and even do some quick review after a first implementation was here.

Thus:

• understand what good enough means for your product, make sure the definition of done reflects this.
• constantly improve the team so that you actually deliver good enough with each story.
• Stop running. Slow down.

(4) Constantly reduce debts

A debt is anything that we need to still do even though the story is closed. This can be a bug, a needed refactoring, a clean up in the user interface, a small function amiss, an automated test not running, and more.

In the beginning, we let debt accumulate. Progress made was more illusion than reality. All the debts crept up later and we needed some substantial extra time to get rid of it. Ooops. There goes the work-life-balance.

As many others did we started visualizing the debts and allocated some budget to remove debts continuously. And suddenly, we did not let them accumulate that much. Our velocity slowed down and in consequence, we had to even more focus on the essentials and do less.

(5) Base architecture on a need

The classic mistake of course. I was recently visiting a project where the product owner team just finalized the initial backlog and the developers finished the thirteenth(!) sprint. Guess what the developers did …

… yes: frameworks, architecture, security layer, evaluation of charting libraries and a reporting engine, setting up development infrastructure, and creating some system interface they will need later. All with little understanding what the whole software is actually to do.

Also in our team we had the developers who rejoiced when they could create a great framework.

Just don’t. E.g. our application security layer was introduced after a substantial amount of functionality was built. Everybody had a bad feeling about it because, well you should care for such a fundamental architectural thing early on, isn’t it? It turned out: Adding the security layer later was not a bad decision at all. With that substantial amount of code in place, architects were able to design the framework that we actually needed.

Our conclusion is to start with the concrete functions and take the time and invest into a higher level of abstraction later, when the actual need arises (See this comment about investment and harvesting).

(1) tp (5) in a nutshell: Focus on users

Reviewing the five guidelines in our team, it occurred that all of them relied on the sole understanding of what really matters to stakeholders and especially to users.

Without such understanding, it is really difficult to reduce functionality to the essential and to provide the right quality user interface. Building the system-up from the walking skeleton and scaling it to more processes and products after the first release remains hazardous and the rat race for features is unstoppable.

In our project we establishes a tight feedback loop with users and customers:

• First we talked to the user what they do today, what works well, what not so well and where do they really need improvement.
• Second we drafted the coming system with early prototypes (mostly mock-ups of the user interface) of the new software and reflected our understanding by letting users experience it.
• Third we had weekly meetings where we showed and let users try our very early product increments.
• Fourth, once we had the walking skeleton we gave to users and they were able to do some work their in what we called a dry run.
• Fifth, we broke our project in several releases and learned from the real life feedback what really matters before we scaled our solution to all processes and sports events. And of course, we started with uncritical events.

My conclusion: Work-life-balance in a project like ours is much better, if the project teams takes the troubles to first understand what really matters to users and stakeholders and start building the respective software. And their is no other way than interacting with these persons.