Building Skyscrapers and Shattering Dreams in Product Development | Guest post by Rainer Tikk

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.

BONUS: Lean and Agile Financial planning with Maarit Laanti and Rami Sirkiä

The financial processes of companies can defeat their own efforts to become more agile. It’s simply impossible for an organization to be adaptable if their project processes require all projects to be specified up-front and funded months ahead of their starting date.

Tackling the financial process changes in our organizations is one of the make-or-break aspects of helping organizations become Agile and adaptable.

In this episode, we talk about Lean and Agile Financial Planning (PDF article download), an approach that tries to adopt Agile and Lean thinking in the funding and financial processes of an organization.

The reason why Lean and Agile Financial planning is a core aspect of Agile transformation in enterprises

Continue reading BONUS: Lean and Agile Financial planning with Maarit Laanti and Rami Sirkiä

Doug Knesek on moving from Scrum “enforcer” to Scrum Master

When we get started as Scrum Masters, especially those that have a Project Management or Management background, we tend to “enforce” Scrum. As our understanding progresses though, we start to learn that there’s a lot of value in helping teams learn by themselves, help them feel confident and take over the process.

In this episode, we discuss that change in our approach to the Scrum Master role, and a lot more!

We talk about Extreme Programming and how that approach should be looked at by Scrum Masters. We also refer to Kent Beck’s Extreme Programming Explained and Martin Fowler’s Refactoring book.

About Doug Knesek

Doug has been an agilist since before it was cool, as his first agility client can attest. He is currently the Director of Agile Development & Coaching at Wisconsin-based Flexion inc., leading agile teams that serve both private and public sector clients. His current hobby is thinking beyond agility, to antifragility.

You can link with Doug Knesek on LinkedIn and connect with Doug Knesek on Twitter.

BONUS: Ben Aston on Project Management lessons that Scrum Masters can use

Ben is a project manager with experience in developing digital services and products for worldwide clients. He’s learned some very important lessons and shares some of his key insights with you in this special episode, where we dive deep into the project manager role and the project management world.

Continue reading BONUS: Ben Aston on Project Management lessons that Scrum Masters can use

BONUS: Geoff Watts on what makes a great Scrum Master, the key challenges to Scrum adoption and much more about Agile

There are quite a few books out there about the Scrum Master job. However, the classic that many refer to over and over again here on the podcast is Scrum Mastery by Geoff Watts.

In the description of the publisher writes: “Scrum coach Geoff Watts has identified patterns that separate a good Scrum Master from a great one”.

As a podcast for Scrum Masters, we wanted to have Geoff on, to share the key insights in the book, but also what he learned since the book was first published in 2013.

But, before we go into those new lessons learned, let’s quickly review some of the key insights from the book

The key insights from Scrum Mastery, the book

Read on for the detailed show notes and all the links…

Continue reading BONUS: Geoff Watts on what makes a great Scrum Master, the key challenges to Scrum adoption and much more about Agile

BONUS: Allan Kelly and Vasco Duarte on #NoProjects and #NoEstimates the latest trends in the Agile community

This is an episode about #NoProjects, #NoEstimates and introduces a unique, and 1-time-only workshop by Allan and Vasco that will take place in London in February 2019. Check out this page about the #NoProjects and #NoEstimates Workshop to know more.

In the past few years a few new trends have emerged in the Agile community that have challenged some of the basic assumptions of how software should be delivered. The first one, #NoProjects is challenging the idea that software work is best managed as a project. As Allan puts it in this episode: “Successful software does not end. It continues. And projects are for temporary endeavours, that have a known start and fixed end. That’s now how software is developed today.”

With that start to the episode you can expect that many unconventional (and inconvenient?) ideas will be shared in this podcast focused on the latest trends in how to manage software development.

Read more… Continue reading BONUS: Allan Kelly and Vasco Duarte on #NoProjects and #NoEstimates the latest trends in the Agile community

BONUS: Mary and Tom Poppendieck on Lean Software Development, Business Agility and how autonomous teams enable adaptability

Tom and Mary Poppendieck have authored several books over the years about what needs to change in how we develop software to be able to meet the demands of the market, competition, and the growth in complexity of technology businesses. A recurring pattern they have witnessed is that people keep trying to discover a “silver bullet”. We explore why that is a bad idea and some of the changes in product development that make it an impossible quest.

Read on for the details, and all the links shared during the show.

Continue reading BONUS: Mary and Tom Poppendieck on Lean Software Development, Business Agility and how autonomous teams enable adaptability

Ricardo explains that if you do not have poising people in the team performance in his experience its always driven by the system.

By his experience every time a team was not performing the reasons were related with a poor system. Before we blame people we should look into how the organization is assembled.

About Ricardo Fiel

Ricardo has 12 years experience in software teams, He had multiple roles from developer to architect to CTO, working in both startups and global corporations. He led teams from 4 to 30 members. Currently, he leads product development (SaaS) teams at Rupeal. You can find Ricardo in linkedin or twitter.

Ricardo defines success of a Scrum Master as the capacity of helping the team to ship software fast and with quality

If a team is able to ship a product day after day, with increased quality and increased velocity this is a clear sign, at least for Ricardo that he is doing a good job as Scrum Master.

About Ricardo Fiel

Ricardo has 12 years experience in software teams, He had multiple roles from developer to architect to CTO, working in both startups and global corporations. He led teams from 4 to 30 members. Currently, he leads product development (SaaS) teams at Rupeal. You can find Ricardo in linkedin or twitter.

Ricardo Fiel explain us how important the job of Scrum Master is.

Ricardo tells us that a good Scrum Master is not the one that is there to solve all the problems but the one that help the team to solve their own problems. Being always there for the team will not help the team to become self organized.

About Ricardo Fiel

Ricardo has 12 years experience in software teams, He had multiple roles from developer to architect to CTO, working in both startups and global corporations. He led teams from 4 to 30 members. Currently, he leads product development (SaaS) teams at Rupeal. You can find Ricardo in linkedin or twitter.