Rainer Tikk writes this guest blog post about what Product Development looks like from the perspective of a leader of a software organization in a mid-size bank. He’s the Head of Software Development at LHV, an Estonian bank betting on IT as a competitive advantage.
To a non-IT person, developing an IT solution might often seem like a mystical activity that boys with ponytails (and some girls) do in a dark basement somewhere. Moreover, software development, in general, is an expensive activity altogether and often takes more time than it really should. And even if there is money available to pay for the software development, more often than not, it’s almost impossible to find a developer to build the stuff you need.
There is a significant shortage of qualified IT talent (at least in Estonia, where I live and work), which in a way explains why Estonian companies invest way too little into automation and the usage of modern technologies which would make their processes more efficient. However, this would be a whole other article.
Now, back to software development. We’ve come a long way from boys with pony-tails in dark basements and tech companies have more than successfully shaken off this image. The offices of tech companies are fancier than ever and there’s plenty of diversity which has made the “average stereotypical developer” almost extinct.
But the lack of time and money to develop the software solutions we need, however, remains. How expensive is expensive, is up to you to decide, but I will try to explain a little about what usually goes on in the dreaded “dark basement”.
To do this, I’ll use the construction of a house as a metaphoric example, an analogy to make my arguments clear. To simplify, let’s assume that software or product development is like construction work – somebody orders the construction of a house, somebody will build it, then other people will start using it and so on. I talk about product development specifically, because that’s what matters most in my domain.
As we are building a home for our residents, we need to make it into something they actually need and want – not just a roof over some walls. Software development (walls and roof) is just one part of developing products.
TIP: As a Product Owner you should always focus on the big picture. Product development is not a delivery problem (getting something done fast), it’s a discovery problem (discovering and doing the right things).
Where do time and money go?
Time in product development is divided between three different types of work: building a new house (new functionality/product), upgrading an existing one (making things better), and, at the end of the day, everything needs maintenance and repair (software upgrades, refactoring, redesign, etc.). In addition to all that, we provide support to the owners of the house (Product Owner/business) as well as the residents (software/product users) who also have occasional questions and issues.
Broadly speaking, one-third of all time spent is used to build new houses, one third is usually reserved for upgrading existing ones and the last third is spent on general maintenance and other organizational issues.
Why does construction always seem to take so long?
Let’s extend the metaphor a bit more and assume that the building of new houses is planned at the beginning of the year. That first one-third of the time spent on building new houses is not that long if you look at the big picture. But expectations are high, lots of new houses are expected to be finished within that time frame. Usually, that timeframe tends to be unrealistic. For large buildings, there are several intricate nuances, all of which influence the completion of one thing or another. On top of that, the planning process usually starts with merely naming and trying to articulate what needs to be achieved, it’s either: “a house”, a “larger house”, or “some kind of a house”.
The beginning is often vague, to say the least. The process will then become more specific as plans will be further articulated, refined, and many plans changed as they progress. Therefore, what is planned at the beginning of the year will not usually materialize as expected by the end of the year. But that’s fine, that’s why plans are reviewed on an ongoing basis and changed as needed.
TIP: As a business stakeholder or Product Owner you should embrace the fact that plans will change and you should be prepared to deal with it (and even benefit from it!). You need to have that flexibility in your team/processes to manage change smoothly. Note that I’m not saying that planning is not necessary, it is indeed necessary. But plans itself are eventually kind of worthless. So you should always focus on creating value instead of meeting the established deadline, budget and scope.
When it comes to building that “some kind of a house”, the fact is that detailed construction projects or plans, that state exactly what and how is needed to be done, are missing. This is where creativity and uncertainty begin (and usually never end). The prospective homeowner may not even know what kind of house they want exactly, but they’re sure they want a house.
They might say they want it made out of bricks and painted red and have a certain number of floors, but that’s about it. And that’s where it gets complicated. It gets even messier when in reality you end up having to build a 25-story skyscraper instead of the 5-story house that was originally planned. For whoever is doing the construction, it’s essential to know, what the prospective resident looks for in their new home. But they can’t usually say that for certain until they have moved in. That’s also OK because construction work is gradual – one floor is built first, and then the other floors are added and interior design works started.
The lack of detailed projects leads to a situation where it is not known how long it will take to build a “red house made of bricks”. If this house is built and the next “red and brick house” is wanted, it will not help either, because you will usually never build an exact replica of the previous house and we all know how much time and money can be spent on interior design (and other “small things” that end up taking the bulk of the time). This is OK, because the context and environment are changing rapidly, as are desires and needs and hence, it is wise to be as flexible as possible. It is important to get the result you need, not to build a random house in the middle of nowhere. This adaptability and openness to changes is what we now call agility.
Two things to always keep in mind in a Product Development environment
In product development practice, there are a few things to keep in mind.
First, don’t ask the customer what they want, instead ask, what the problem is they want solved. This will help you focus on the actual problem instead of the dream. There will always be big dreams and demands for development. And these dreams and demands will always be greater than the supply of talent and time to meet them. Meaning, you never get to the point where you have enough people and resources to fulfill all those needs. Thus, you should focus on finding the next most important thing to do (from the value perspective).
Secondly, what a Product Owner can do to help find “the right things”, is to slice the work into meaningful pieces, as small as possible. This will help you and everyone involved in the project achieve that flexibility to respond quickly to change of plans and also get faster feedback. When you get this in place you will eventually build a better product.
Being an owner means having to take responsibility
Problems also arise when the owner can’t decide which house they want most or which one they want next and the construction team has to build two (or more) houses at once. Then it takes an awful lot of time to move between sites, and of course, the completion date of both houses will consequently be delayed. Also, if we are already building one house and it turns out that a smaller shed needs to be completed in the meantime, it will take additional time to move all the equipment between building sites. And when the team gets back to the first project, they’ve already forgotten where or what they used to be working on exactly.
If, for some reason, there is a definite deadline for building a “blue and brick” house and it is known that all the remaining time will be spent on it, but the owner still insists building “red and wooden” in the meantime, it will be, for some reason, incomprehensible to the owner that if “red and wooden” will be built, then “blue and brick” can not be completed in time.
One of the biggest wastes in software development is parallel work. In other words, there is this pervasive illusion that if we are doing multiple projects at the same time, we get to squeeze more out of the team. This is not the case. Parallel work is often the bi-product of the Product Owner being unable to decide which project is the next most important to be done and thus they start multiple projects in parallel (because everything needs to be finished yesterday). The more stuff you have on that table, the more time it will take to complete it, and as a result, the completion time will grow exponentially.
As a product owner you should be aware of the consequences and avoid that trap at all costs.
Of course, several additional things affect the completion of a building – how much the owner is present and involved and how well they express their wishes, and how often the wishes change. Sometimes the team members get sick and sometimes some even leave to go work for another construction company. Then you need to find a new person and you need to do it fast. It is complicated because there is a lot of work to be done and a random builder off the street often just doesn’t cut it.
The Upgrade and Maintenance Projects
Another third of the time spent goes to upgrading existing houses. This is an essentially unpredictable activity and the needs to be tackled can come from anywhere – the owner wants to change something in their house or there is a policy change that says we need to replace all windows. In essence, this is a job that falls on you when you own a house, with little chance of you deciding what or when to do. But that’s OK because a good owner knows where their priorities lie. Right?
The last third of the time is spent on maintenance and repairs. If icicles hang from the edge of the roof in the winter, they must be removed. Regular cleaning is also generally required, otherwise, no one wants to live in that house. Sometimes you have to fix the foundation or even replace parts of it. Or take, for example, security. For critically important houses, the fact is that security systems should be renewed often. These systems need to be constantly upgraded, or else someone can break in and steal the residents’ property. That could have tremendous consequences. But that’s OK because a good owner knows that everything has to be in order and will invest in that work. Right?
Don’t underestimate the cost of having a software system.
Software systems need constant maintenance as a building and a car does. If you don’t invest in maintenance and upgrades, you’ll end up building technical debt which may eventually make the house unusable. If you keep ignoring technical debt, it will just grow.
Technical debt won’t disappear as I’ve seen too many times business owners dream of. Eventually, you end up in a situation where you need to do something (business-wise) but you can’t do it before you have removed the technical debt which literally blocks you from doing the thing you need to.
Simple questions don’t always have simple answers
Despite everything mentioned above, there are notable differences between product development and house building. For example, in product development, there are no detailed projects, but rather sketches and details are decided on a rolling basis. These things are so for a reason. It is not easy to see the progress of completion with your own eyes as there are no “rising walls”, and when it is finally “done”, 2/3 of the time will be continuously spent on upgrades and maintenance. Building a product is a complex process – it’s creative and unpredictable. If buildings were built as products, most of them would not be standing.
There is certainly more flexibility in product development, but it will also result in more opportunities to build things you don’t need or want to use. That’s why soft factors are important in achieving good results – from collaboration, communication and team physical presence to collective intelligence and ways of thinking. Also, following a textbook does not usually lead to a good result – what works for one does not work for another. It is important to learn, test and find techniques that work in your context, with your people and your products.
So how much does a “red house made of bricks” cost, you ask? It depends. But when can you consider the construction project finished? Honestly, when nobody uses it anymore.
About Rainer Tikk
Rainer is the Head of Software development at LHV, a mid-size bank based in Tallinn, Estonia. He has 15+ years of experience in the areas of software development management, product development, team leadership, and software engineering.
Over that time he has collected deep knowledge in strategic management, organizational design, agile methodologies, full SDLC and in different FinTech and banking domains (payments, cards, core banking etc).
Rainer believes in value-driven product development, building good software (high-quality, secure, sustainable), continuous improvement, automation and autonomy for the teams that develop the software.
He’s interested in growing teams and organizations, developing strategy, agile product development.
In his free time, Rainer travels, hits the road with his motorcycle, likes to breathe fresh air on a golf course, hits the slopes with his trusty snowboard, and searches for treasures underwater, but most importantly, his biggest project is raising his 2 children.
You can link with Rainer Tikk on LinkedIn.
