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.
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 it’s crucial to 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. This is a creative and fun process!
Quite often we started off with a great idea on star level 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 to come onto cloud level. What’s the point of doing it? What’s the value and is this in scope in regards to our contract and the story that wanted to become reality? If yes, we got creative and looked for simpler and better solutions within our budget. It took some iterations of creating mock-ups, splitting into user stories, and estimation.
In this process we came close to tree level as costs and value came into the desired region and we took the feature forward into the development stream. We added the needed stories to the story maps, discussed them with developers and the stories changed: now we focused on the bare necessities to deliver the basic concept behind the idea.
While working on 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.
- When asking stakeholders how much they want to pay for a function or a quality you can spot the mismatch between cost and value.
- Putting the focus on the bare necessities provokes reactions by stakeholders. Just like the designers do, when they remove until too little remains. It was quite easy to spot what really mattered to the stakeholders once it was removed.
- In our creative phase from stars to tree we looked closely for common interaction patterns, shareable components and common structures. We simplified our design by reusing such assets and we saved on testing by isolating them into common code.
- Special cases, i.e. the cases that do not fit the identified patters can become very expensive. We tried to remove them from scope whenever possible or in a few cases, had to enhance the basic concepts. If the value was high, we invested some of our budget into refactoring the existing units to the next level that catered for the special cases.
(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 enlarge 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 very good 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.
- User story maps that align stories with the process allow to much better see what is really needed.
- If you deliver as little as you dare to support a process and let users work with it, you see what they really need.
- However, what you deliver needs to create a great experience to the users from the beginning. It must be promising so they 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 the 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.
All those who do not know the fantastic book Momo from Michael Ende should read it.
But to come back to our definition of done issue: 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.
To get rid of the first issue we had to slow down our product owner side. Product owners must absolutely not give the their pressure for features onto the team. Its crucial that they calm down, concentrate on why all that stuff really matters, get into the creative mode and together with the team find a simple solution.
To get rid of the second point we introduced a simple story acceptance meeting just before the devs said they were done. 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 rounds, developers and product owners started to interact even more intensively and even do some quick review after a first implementation was here.
- 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 done and focus on the essentials to deliver in time!
(4) constantly reduce debts
Visualize them and constrain the available space for 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 UI clean up, a small function amiss, a automated test not running, and more.
In our project, because we pushed ourselves forward, we let debt accumulate in the beginning. We made a lot of progress that was just an illusion. Obviously all those debts cropped up later and we needed some substantial extra hours 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 focus even more 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.
Just don’t. In our project we had the one or the other developers who rejoiced when they were allowed to create a great framework. Still: many of the things we evaluated before actually building real functions we had to take out again.
Some things we did better. E.g. our application security layer was introduced after a substantial amount of functionality was build. Everybody had a bad feeling about it because, well you should care for such a fundamental architectural thing early on, that is what we were taught the years past. But it turned out: Work is easier that way. Because once you have a substantial amount of functions and data ready, you really know what to secure. And resulting layer is much closer to the needs imposed by what is built and less by some dreams.
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.
Or rather one? Focus on users, their life, their work and their dreams?
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. The whole complexity cries for frameworks and heavy architectural work, creating more time pressure. Debts pile up, quality sucks and users complain.
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 participate in a work simulation based on these mock-ups.
- 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 let users perform their work with our product increment at least as much as it was possible to simulate the work environment.
- 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.
My conclusion: Work-life-balance in a project like ours is much better, if the project teams take 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.