How to break 4 vicious cycles of software development
At Flowa we have seen quite a few software projects over the years, and worked with dozens of organizations having software in the core of their business. We have identified 4 common vicious cycles and ways for breaking them.
When we work in a customer organization, or work on our own products, we pay attention to these. In the past few years we have identified a pretty nicely working recipe to tackle these challenges. Next we will introduce our recipe to success accompanied with four short case studies.
Ways to break the vicious cycles
Just ship it!
The best way to avoid long delays, is to just ship it and stop giving excuses why we should not release the next version, start marketing it etc.
Small diverse business team
Decrease complexity in the beginning by starting with a small diverse business team and avoid scaling up to multiple big teams that are dependent upon each other. At a later phase, a key success factor is to minimize the amount of dependencies.
Insightful feedback + clarity on the impact and purpose
Tackle unclear focus by making it easy for customers to tell what they need. Creating something tangible and visible that is just enough to inspire them but is not perfect, is one of the most efficient methods to get good, insightful feedback. Another thing we find highly important is clarity on the impact and purpose: it’s not only more motivating to work on software that makes a difference, a clear and inspiring goal makes us also far better problem solvers.
Experiment-driven risk management
One approach to avoid premature scaling is to focus on the tangible value in planning, and treat features just as possible ways to deliver value. Another pattern we love is experiment-driven risk management: small, low-risk experiments are a way to minimize the impact of risks without compromising the delivered value.
Cases where we have applied these
What matters to me
- What matters to me is a service for helping people with special needs for communicating their needs efficiently.
- Team: 3 person team from Flowa and business owner
- Constraints: Tight budget constraints
Clarity on the desired impact and purpose
We started with two half day workshops with the client, where we crystallized what the desired impact is and formed an initial plan to get there. After that we agreed about the contents of the initial release.
Ship it! and feedback
It took 4 days to create the first version and 2 more days to incorporate the feedback and learnings into the first release. The same method has been used ever since: agree about small chunks of value, implement them quickly and evaluate together. Once we had users, we did user interviews to see if our hypotheses about the solutions were correct and to learn what kind of challenges they face and adapt accordingly.
Experiment-driven risk management
We avoided doing anything that would take more than 3 days from as as a team. Some of the risks were also realized: for instance we could not use payment solution we originally intended to use because of contractual, business-related constraints. Within a few days we ideated and implemented a good enough alternative solution.
GoWood
- A research project, where we created a proof-of-concept for tracking wood raw materials from a finished building back to the original tree trunk in the forest.
- Core team: 2 person from Flowa and product owner from Aalto University
- Constraints: 6 weeks to build a proof-of-concept; Not clear what data we will get; Partially unfamiliar technology
Insightful feedback & ship it!
In the beginning, we didn't knew if we will get any real data. It was also unclear what different stakeholders would like to see. We focused on the user interface (UI) first to gain a shared understanding about the concepts. We also interviewed a tree harvesting company subject matter expert. At last, we gave the first demo to a group of researchers 3 weeks after the beginning of project. The first version was delivered after the first one week sprint.
Experiment-driven risk management
Once we had working UI we implemented data layer. The first version of data layer was hardcoded in frontend, the second version we added backend service and hard coded data there. In the third version we added graph database to the system and uploaded test data there. Finally, in the last version of data layer, we distributed data into two blockchain (holochain) nodes. We applied similar iterative approach in data visualization. In the first version we had just map for building. Then included added a 3D model. In third version contained there were three clickable elements in the model. When ever we needed to use technology we did not have experience, we did so in short iteration (usually no longer than a day or two).
Billing System
- Creating a billing functionality as an add-on to an existing system.
- Team: 2 developers from Flowa, client PO and UX designer
- Constraints: Many stakeholders with competing needs; Built on top of a large legacy system
Small diverse business team
At the beginning the developers built features without too much guidance from the business which created confusion but once we got a team of 2 developers, a UX designer and a PO work together in short increments, the overall understanding of the goals, decision-making and ability to produce value early were improved tremendously.
Insightful feedback, and clarity on the impact and purpose
Being able to frequently communicate and exchange ideas with the business enabled us to do continuous prioritization. Without this tight collaboration it would have been next to impossible to come up with solutions that would have produced the right value and keep the somewhat competing stakeholders and end users happy.
Ship it! and experiment-driven risk management
At one point we had an important deadline looming with a lot of unfinished things still on our backlog. Instead of just seeing if we can make it and possibly letting our users down, together we decided to try if a radically different solution would solve most of the user needs. And it did! In the end we managed to release on-time and did not cause problems for the end users with possible delays.
Marketing tool
- A single page application to increase customer understanding and to target marketing effort better.
- 4 person development team from multiple companies and client product owner and business owner. A person from Flowa worked as a ScrumMaster and coding architect
- Constraints: Built on top of number of large legacy databases and processes
Ship it!
The project was launched at the end of March. We demonstrated the first version to potential pilot customers at the early May and full scale pilot use started in the middle of June. To keep this schedule, we put our full focus to the user interface and getting data there. For instance, we simply did not implement backend logic needed to save data.
Clarity on the impact and insightful feedback
Developers attended pre-sales meetings and customer interviews and heard from customer how they reacted to the demo and what needs were important to them. This increased clarity on the impact and purpose of the application. As we were able to get feedback from the customer, we saved a lot of development time as we didn’t need to implement various laborious features.
Experiment-driven risk management
Did everything go like in dreams? Not even nearly. For instance, there were a number of components in the data layer that we implement two or three times until we got it right. This was possible mainly because experiment-driven approach and because frequent deliveries forced us to keep components small and as independent from each other as possible.
Conclusion
You might think that there is nothing new in our way of work. You’re right. This is what Agile is supposed to be: Fast-paced, experiment-driven problem-solving that strives to deliver stuff that makes a difference with minimal overhead.
Another question is how common it is to do this in a disciplined way. For instance, it’s very common to come up with excuses for not releasing at all if you feel like you cannot deliver a version that someone is willing to pay for. Revenue is not the only unit of value. In the early phase of a product, learning is often more valuable than money.
It’s also common to accept scope creep because the customer wants to have “all the necessary features”. Indeed it takes time to create needed trust with non-technical stakeholders. The starting point is to deliver at least once per week, and demonstrate progress in some way more often.
Another important thing is to be genuinely interested in what you do and show it: if a team member doesn’t see the software purposeful and inspiring, his productivity will plummet. It’s hearth-breaking to see development teams without purposeful and intrinsic inspiration.
By the way, once you manage to gain the required trust, customers will love this kind of approach. Here are a few testimonials we’ve got:
"It was a pleasure to work with Tero and Ari-Pekka. We managed to accomplish a lot in a very short timeframe. I was genuinely pleased that Tero and Ari-Pekka managed to make a blockchain-based solution working, including using Holochain and Rust, which they did not know in advance."
Pekka Nikander, Professor of practice (Industrial Internet) at Aalto University and the Scrum Product Owner of the GoWood Proof of Concept.
"Working with you is such a delight compared to other companies"
Johanna Mätäsaho, CEO of Bestser and the owner of What matters to me service
Check out our offering
Digital success stories on Google Cloud Platform
Software development services