There is always pressure on the IT team to deliver more. However, instead of focusing on value, this is often interpreted as 'delivering a greater number of functionalities'. Meanwhile, more functionality ≠ (does not equal) value in the product. When I am asked to support a project, how do investors undervalue the following issues:
- improving team collaboration
- improving (often automating) tools
- minimizing waste
- stability of the IT team
- removal of technical debt
Meanwhile, Scrum teams need to focus on the above to generate more value in the long term.
Improving team collaboration
Some Investors are susceptible to learned thinking. This is a conditioned response that occurs when people are closed to new ways of thinking by perspectives they have acquired from previous experiences. Essentially, they transfer practices from their own business to working with an IT team. Unfortunately, this does not work because building software products is a complex field.
Products are usually too difficult to analyze in advance. It is not realistic to plan everything in detail in front of time. Along the way, many situations arise that require a change of plan. In the complex domain, you work with governing constraints to achieve the goal without deviating too far from it. It is an uncertain environment where you can hardly predict everything.
Does this mean that nothing can be done? On the contrary. Here's what you can do:
- Instead of being obsessed with the number of tasks completed, be obsessed with the ready-to-go functionality.
- Ask your team whether the activities involved in planning the delivery of value for your IT product seem easy or difficult
- Monitor how well your team collaborates on planning and forecasting
- Check how much change occurs in the product backlog over successive sprints and compare this with the percentage of the product backlog that should be completed (use BurnDown Chart)
- Determine how well you and your scrum team understand the desired value for each element of the product registry
- Consider what the benefits would be of releasing more versions of your product more frequently
- Think about what is stopping you from releasing product versions more often
Improve (often automate) tools
Automation makes work easier. A lot. Unfortunately, the barrier to entry is quite high. Some investors, discouraged by the amount of work involved in automated solutions, often give them up, wrongly assuming that they will not pay off. Nothing could be further from the truth. Test automation and product releases, although they seem like overkill in the initial phase - they start to pay for themselves after just 2-3 sprints.
If you have been maintaining your product for a long time and still have certain software development processes that are not automated at all, here is what you can do:
- reflect on which challenges are currently the biggest trouble spots
- together with your team, find one that will improve efficiency
- identify the desired impact (minimal to start with) and the way to measure it
- implement it and see if it pays off for you (only if you don't believe me. I can assure you that you will gradually introduce even more automatic improvements)
Minimising waste
There are times when the Team will not deliver a completed product increment. In such cases, the sprint retrospective should focus on how the Team can make up for the unfinished work. Remember that the Team should be able to step back to understand what happened and why they did not complete the scheduled work. The fact that all tasks have not been completed does not imply that the members are ineffective - at least not yet at this stage.
Scrum teams maximize workflow when they move individual elements through the process as quickly as possible - without risking product quality or customer satisfaction. Minimizing waste enables them to maximize value delivery. But what is this waste?
By waste, we refer to everything that does not add value for the customer. And here are the common activities that result in waste. Check which ones sound familiar to you:
- lack of available environments when needed, including failures and restarts;
- starting work on an element of the product backlog and then discovering that it is dependent on another team and cannot be delivered on time during that sprint;
- reports of non-working functionality with many nefarious or unclear descriptions and missing simple steps to reproduce the problem - this takes a lot of time and often requires additional work to clarify things;
- the constant interruption of a team member's work - because of this, they have to spend time re-implementing;
- Multitasking - according to Little's law, essentially the greater the number of things you are dealing with at any one time, the (on average) more time it will take you to complete work on each of them. So as a result - due to the many forms of waste created by this situation - it takes longer to complete the work in the end.
Stability of the IT team
This is also where learned thinking comes into play. I sometimes get the impression that many Investors think that a developer in the IT Team is like a worker on the production line in a factory - it is relatively easy to replace him with another who will do the same thing without damaging the production process.
Unfortunately, the instability of the IT team means that new Team members have to learn your product by asking their teammates and performing research every time they are forced to work in a particular area. If the product is complex, based on multiple integrations with external systems, and on top of that with a large technology debt and a complex business objective - there is a drastic slowdown of work and no completed product increments every Sprint. And this cannot be Ignored.
A system of rewards and punishments, or, horror of horrors, attempts at manipulation or intimidation, will get you nowhere. What you need is time. This is why it is worth realizing that a huge part of the 'value of your product' is 'what is in the heads of your employees, their knowledge and familiarity with how it works'. And that every Team member who is replaced takes away some of this 'value' with them. So it can be said that a company that loses people loses its capital. Can you afford such a loss?
Removing technical debt
When the creation of a project involves an accumulation of errors, we speak of technological debt. Given the numerous obstacles that teams face when doing complex work, it is highly likely that not all of them will be immediately eliminated when they can be identified during a sprint. Putting off fixing them in the rush to implement new features is what creates technology debt.
Here are some useful questions to better understand the impact of impediments:
- How much time do we spend dealing with an obstacle?
- How often does this obstacle occur?
- What impact does it have on quality?
- Is the number of defects detected in production increasing or decreasing?
- What is the cost of fixing a defect in a production environment compared to fixing a defect detected during software development?
- How does such an obstacle affect morale? Do people leave the team because they are unhappy with the impediment? What is the cost of hiring a new person?
What impact can technology debt have on your product? It can, for example:
- It can cause slower implementation of new functionality - it's difficult to create something new when you have to spend time fixing something old, otherwise, nothing will work
- It can lead to operational problems such as crashes, miscalculations, loss of productivity due to performance degradation, security breaches, and ultimately bring the project to a halt
- It can make it more difficult to respond to crises - your technical debt limits your ability to react quickly to failures and to adapt and change
- It increases staffing issues - it can be difficult to find developers willing to work in an environment of constant firefighting if they can work with the latest technology and in relative peace of mind for your competitors.
Technology debt boosts the cost of implementation and production, resulting in reduced profits. But it also builds up employee frustration and ultimately leads to staff shortages and, even worse, creates customer dissatisfaction. Dealing with technology debt requires a large investment of time and money, so it is better to think about it in advance how to avoid falling into such a trap.
The improvements described above are important, but they are only a few of the ways Scrum teams can enhance the way they deliver value. The need for these improvements often becomes apparent as part of the Sprint Retrospective, but can also come to light as a result of feedback received during the Sprint Review with the developer, and as a result of obstacles encountered during the Sprint.
The Scrum Master helps the Scrum team to improve themselves. But the members of a mature and stable Team also help each other to perfect the quality of their work and the product they are working on.
As an Investor, you also play a big role and have an impact on the performance of your team.
If you would like to know how you can maximize the value of your product and the performance of your team, please contact us. Our Scrum Masters conduct software development process audits, consulting, and workshops, also for investors.
If you are interested in this topic, I encourage you to read the book “Mastering Professional Scrum: A Practitioner's Guide to Overcoming Challenges and Maximizing the Benefits of Agility” by Stephanie Ockerman and Simon Reindl.
Source of graphics: www.pexels.com.
