Martin Lambert: The Empathy Agile Retrospective Format How-to

When it comes to success as a Scrum Master, Martin asks us to consider the “little things”. For example: “how does your team react to adverse situations?” This and other questions help Martin assess his work as a Scrum Master. Listen in to learn about the other questions that Martin asks himself to assess his own success as a Scrum Master.

Featured Retrospective Format for the Week: The Empathy Retrospective

In this retrospective format, Martin focuses on helping team members understand their colleagues’ perspectives. We discuss how to “warm-up” the team to this format, as well as how to execute the format. Learn also why this format is important, and what you can expect from it.

About Martin Lambert

Martin’s an agile coach, trainer and scrum master. He’s a Northener making a living in the south of England, and finds great energy and sense of purpose from the agile movement during the second act of his career. Loves the hills and being out on a road bike. And to all the European listeners, he says: “sorry for you know what”.

You can link with Martin Lambert on LinkedIn.

Martin Lambert: Are you trying to change too much? 

Martin shares a story of an engagement which goal was to help a department adopt Agile. We review his first steps in that change, what he observed when the engagement started. We then discuss some of the tools he helped implement in that organization and how that was done.

In this episode, we refer to the Goal Roadmap by Roman Pichler, and one of the most critical skills for Scrum Masters working with change: to be able to distinguish what can be changed, influenced, and what cannot be changed. Are you trying to change too much?

About Martin Lambert

Martin’s an agile coach, trainer and scrum master. He’s a Northener making a living in the south of England, and finds great energy and sense of purpose from the agile movement during the second act of his career. Loves the hills and being out on a road bike. And to all the European listeners, he says: “sorry for you know what”.

You can link with Martin Lambert on LinkedIn.

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.

Martin Lambert: Swarming a whole-team approach to getting work done

What happens when team members see themselves as specialists? We discuss some of the common anti-patterns of the specialized team member perspective and talk about the benefits of swarming, an approach where the whole team feels responsible for the deliverables they have to complete, instead of standing by and letting the specialists work alone.

Featured Book of the Week: <Redacted>

Martin wants to share some of the insights that he got from a book he read. The book allowed him to feel free from previous fears, and find space to express his curiosity. This lead to Martin finding a newly rekindled thirst for knowledge. The book? You may want to ask Martin directly on LinkedIn, his LinkedIn page is linked below, in his bio! 🙂

About Martin Lambert

Martin’s an agile coach, trainer and scrum master. He’s a Northener making a living in the south of England, and finds great energy and sense of purpose from the agile movement during the second act of his career. Loves the hills and being out on a road bike. And to all the European listeners, he says: “sorry for you know what”.

You can link with Martin Lambert on LinkedIn.

Martin Lambert: The common anti-patterns new Scrum Masters take, but should avoid

When we take the role of the Scrum Master, many of us are jumping into a new experience. Something we’ve never done before. Whether you have a background in technology or project management, Scrum Master is likely to be a very different role.

In this episode, we discover through Martin’s story what are the most common anti-patterns that we take up as new Scrum Masters. Have you been too committed to the previous ways of working? Have you tried to teach, when the right stance to take was to listen and ask questions? Don’t despair, we’ve all been there and Martin shares his personal story, as well as what he learned from that about the core of the Scrum Master role.

About Martin Lambert

Martin’s an agile coach, trainer and scrum master. He’s a Northener making a living in the south of England and finds great energy and sense of purpose from the agile movement during the second act of his career. Loves the hills and being out on a road bike. And to all the European listeners, he says: “sorry for you know what”.

You can link with Martin Lambert on LinkedIn.

Dirk Fabricius: The Secret Backlog, Product Owner anti-pattern

In this Product Owner episode, we talk about the importance of nurturing the collaboration between Product Owner and team, and we uncover The Secret Backlog, a Product Owner anti-pattern.

The Great Product Owner: Accepting team input

Having worked as a Product Owner for 2 years, Dirk has learned the hard way how difficult that role is. So, when he took the Scrum Master Role in a pilot project he wanted to help the PO. Worked to prepare the team environment, getting managers out of the daily meetings to give teams the freedom they needed. Once the team was ready, he worked with the PO to support him. He describes what behaviors made this PO a great PO, including how he treated the team members, interacted with stakeholders, and how the PO was able to accept and process team input.

The Bad Product Owner: The Secret Backlog

There are many things that can go wrong with the product owner. In this episode, we learn about a PO that wanted to micromanage the team, had a second (secret) backlog and was not able to accept and process feedback from the team or others. We also discuss what Scrum Masters can do to detect early signals of problems and to keep themselves in check. Avoiding to escalate the situation even further.

Are you having trouble helping the team working well with their Product Owner? We’ve put together a course to help you work on the collaboration team-product owner. You can find it at: bit.ly/coachyourpo. 18 modules, 8+ hours of modules with tools and techniques that you can use to help teams and PO’s collaborate.

 

About Dirk Fabricius

Dirk has worked in jobs with IT focus for 20 years. He has had the roles of Project Lead, Developer (Backend), Product Owner and Scrum Master. He’s also been a Teacher in Public Schools for 7 years.

You can link with Dirk Fabricius on LinkedIn.

Dirk Fabricius: How do we measure the Scrum Master role?

A question Dirk has heard often (and you might have too!) is: how should we measure the Scrum Master role? That led him to think about possible metrics to present to stakeholders. In this episode, we discuss possible Scrum Master metrics as well as the “self-check” questions you can ask yourself when evaluating your own success and evolution as a Scrum Master.

Featured Retrospective Format for the Week: Customizing your Retrospectives

At some point, the formats you are used to may not be enough, and you need to find another format for the issues at hand. In those situations, Scrum Masters must be comfortable with customizing the retrospective format for their team. In this segment, we discuss tools and approaches you can take to customize your next retrospective to the team’s specific needs.

A useful tool, which has been referred to before on the podcast is Retromat.org. However, there are some caveats when using that tool. Listen in to learn about possible drawbacks and how to overcome those.

About Dirk Fabricius

Dirk has worked in jobs with IT focus for 20 years. He has had the roles of Project Lead, Developer (Backend), Product Owner and Scrum Master. He’s also been a Teacher in Public Schools for 7 years.

You can link with Dirk Fabricius on LinkedIn.

Dirk Fabricius: Scrum Master Journal, a tool to survive large scale Agile adoption (and 9 other tools)

In large organizations, Agile adoption is often a long and complicated process of constant expectation management for both stakeholders and Scrum Masters. In this episode, Dirk shares with us his experience with the Scrum Master Journal, a tool that helps him reflect and survive large scale adoption.

Dirk also has 9 other tools to share with us that will help your Scrum Master journey.

In this episode, we refer to Battle Mapping and some practical tips on how to get help from the other Scrum Masters.

About Dirk Fabricius

Dirk has worked in jobs with IT focus for 20 years. He has had the roles of Project Lead, Developer (Backend), Product Owner and Scrum Master. He’s also been a Teacher in Public Schools for 7 years.

You can link with Dirk Fabricius on LinkedIn.

Dirk Fabricius: Helping Scrum teams survive micromanagement

Sooner or later, Scrum Masters will face the micro-management anti-pattern. What should Scrum Masters do in that case? In this episode, we talk about the anti-patterns that can emerge in a team that is subject to micro-management and some of the tools that Scrum Masters can use in those situations.

We discuss the Game of Trust and the Niko Niko Calendar.

Featured book for the Week: Scrum Mastery by Geoff Watts

Geoff Watts has been a past guest of the Scrum Master Toolbox podcast, and is also the author of Scrum Mastery: From Good To Great Servant-Leadership. In that book, Dirk found out about servant leadership and how that could change his approach to the Scrum Master role.

In this segment, we also mention Scrum for the people by Tobias Mayer and Product Mastery by Geoff Watts.

About Dirk Fabricius

Dirk has worked in jobs with IT focus for 20 years. He has had the roles of Project Lead, Developer (Backend), Product Owner and Scrum Master. He’s also been a Teacher in Public Schools for 7 years.

You can link with Dirk Fabricius on LinkedIn.

Dirk Fabricius: How Scrum Masters can navigate Agile adoption in large organizations

What can a Scrum Master do when they are part of Agile adoption in a large organization? In this episode, we explore some of the common problems you should be ready for. Dirk shares with us what he learned and how Scrum Masters can prepare for the predictable problems they will face.

In this episode, we refer to the technique “Battle Mapping (PDF at Scribd)” that can help Scrum Masters understand where to put their focus during a transformation.

About Dirk Fabricius

Dirk has worked in jobs with IT focus for 20 years. He has had the roles of Project Lead, Developer (Backend), Product Owner and Scrum Master. He’s also been a Teacher in Public Schools for 7 years.

You can link with Dirk Fabricius on LinkedIn.