Scrum: A Recipe for Effective Teams or Just Theory? | Michał Pięciorek | Euvic Talks

Bartek Śliwa: Bartek Śliwa, this is the Euvic Talks podcast, where we connect technology with business.

Today we will slightly demystify the concept of agility, talk about what Scrum is, and our guest is Michał Pięciorek. Hi Michał.

Michał Pięciorek: Good morning, hi Bartek.

Bartek Śliwa: Michał, standard question for everyone. What connects you with business?

Michał Pięciorek: That’s a good question.

Let me introduce myself briefly. Michał Pięciorek. I have been associated with Euvic for three years. I started my adventure here as an IT recruitment specialist. However, I graduated from the University of Economics.

I think that in retrospect, I can say that studies were merely an addition to what I did on a daily basis, because I very actively participated, let’s say, in student life, and I operated in organizations such as the student parliament, the Student Form Business Center Club Foundation, where I worked as a project coordinator, later regional chairman, and then for three years on the nationwide board.

Hence my professional adventure with the Business Center Club in the Katowice Lodge, where the Business Center Club is an entrepreneurs’ club that brings together companies all over Poland. I co-organized the 23rd and 24th Silesian BCC Gala.

So that contact with business was there, and the problems that entrepreneurs encountered back then or encounter today are not foreign to me. Currently, I am a Scrum Master, I cooperate with development teams, we work with international clients, and we create top-quality digital products.

Bartek Śliwa: What intrigued me is what you said about business problems not being foreign to you. Can you share any of the problems that stuck in your memory during your work with BCC?

Michał Pięciorek: When it comes to such problems, they were very diverse and, of course, some were more complicated, others less. In general, BCC as a club not only brings entrepreneurs together, but also helps them on a daily basis. These were problems often of the nature of company transformations or perhaps interpretations from tax offices. Law changes quite drastically, which makes it difficult for business to operate. So the problem was even more—well, it was even simpler, but I think… daily work.

Bartek Śliwa: OK, OK.

Right, you are my colleague in the profession because you are a Scrum Master, and I assume that unfortunately the market has heavily corrupted the concept of Scrum and Scrum Master, and our clients often have such an ambivalent attitude towards agility in general, so maybe tell us in your own words what your role as a Scrum Master is? What does it actually do, what is it for?

Michał Pięciorek: Good question, and I often encounter this as well. Whether it’s, say, explaining to my family somewhere at a birthday party, “what exactly do you do there, son?” or when I talk to people who are not connected with IT on a daily basis, they don’t fully understand this role. I’m not even surprised, because the role of a Scrum Master is quite specific. That is, while everyone has more or less heard what Scrum is, those responsibilities are not so clear. That is, the specificity of this profession lies in the fact that the effects of a Scrum Master’s work are not visible immediately. That is, only after time can you check whether the Scrum Master is actually delivering, whether the team is operating more efficiently or not.

Because in Scrum we have three roles, for those who haven’t encountered them, so that we have the same understanding. We naturally have the product owner, which is that business representative who gathers requirements, whether from stakeholders or from the market, prioritizes these tasks, sets a certain direction, indicates what we should do first, so it’s easy to classify and imagine such a person.

We have developers, or the team in general, who transform these requirements into functionalities. And whether they write code or build a product at all, because Scrum is not only in IT. And we have this unfortunate Scrum Master who sits on the side and actually nobody knows what he does, what he should be held accountable for, and so on.

A Scrum Master is responsible above all for ensuring that Scrum is used according to how it was created. That means, in my opinion, for Scrum to bring that value, to fully utilize the potential of Scrum, those rules described there must be preserved. There are not many of them, but they must be taken as a whole, so they ensure that all these elements cooperate with each other during the work process.

They are also responsible for the team’s efficiency. And if the team is efficient, achieves sprint goals, and the product is created incrementally, meaning we build functionality step by step, that’s a good sign. That means the team is working, so this Scrum Master is perhaps helping there.

A Scrum Master also helps the product owner. While the product owner is responsible for setting the direction, they won’t always know what is most important or has higher priority, so the Scrum Master is the person who helps find some prioritization techniques, serves as support, and together we figure out what we should focus on, so they are also support for the product owner.

Of course, a Scrum Master should train, whether the team or organizations, also in soft aspects, which also eliminates waste that quite often occurs in companies. And a good Scrum Master above all should look not only at the team they are in, because those are often small teams, but it’s also good for them to focus on the whole as an organization, to eliminate this waste not just at the team level, but across the entire organization, because that’s the scale effect, you know. In a nutshell, they ensure that the process is used properly.

Bartek Śliwa: Exactly, because we observe various distortions, meaning the Scrum Master as a micro-manager.

Michał Pięciorek: Yes, or a secretary, or… a coffee maker.

Bartek Śliwa: So it’s not about sticking colored sticky notes.

Michał Pięciorek: Absolutely not.

Bartek Śliwa: And eating cookies.

Michał Pięciorek: Yes, I am fully aware of what the situation looks like on the market. Most Scrum Masters…, I don’t know if I can say this, but the market is a bit corrupted. And weak Scrum Masters do a very bad job because they sit in these meetings, don’t help the team, and the team actually wonders what they are even there for. And it creates this aura that they are basically the team’s secretary and nobody knows what they do or what their impact is. And as I mentioned, the impact of a Scrum Master’s work is seen after time, through the team, through whether the product is delivered.

So I myself, I must admit, I send memes about Scrum Masters with the teams I work with and I laugh at it too, because you have to have some distance. But there is indeed such a tendency.

Bartek Śliwa: Let’s take a step back. People often put an equal sign between the concepts of Scrum and Agile. Do you think that is correct?

Michał Pięciorek: No. Agile is a much broader concept. That is, Agile is a certain way of working, a certain mindset, perhaps even a lifestyle for some.

Bartek Śliwa: Yes, mindset is that word I always like to use in relation to Agile.

Michał Pięciorek: Yes, I fully agree, so to explain it most simply, it is the ability to adapt to the surrounding reality, whether in the professional field or the private field. Because we know we can plan something long-term, and later, well, reality knocks and is different from what we planned. So such an ability to adapt to market or private realities. That’s how I would classify Agile.

Whereas Scrum is a slightly narrower concept because Scrum is a framework, meaning rules of procedure, a specific way of working. I think that might stem from people treating them as synonyms, it might stem from the fact that Scrum is simply the most popular, most frequently used way of working. It’s worth remembering that it is not the only one, and there are many, many more agile approaches. It’s just the most commonly used one, hence I think these kinds of mistakes happen.

If I were to visualize it, I would compare Agile to an ocean, while Scrum I would compare to an island, perhaps even Australia, because it’s the largest.

Bartek Śliwa: Poetic.

Michał Pięciorek: I try.

Bartek Śliwa: Exactly, since we are moving into poetic comparisons, you said that Scrum is like a frame. I once liked the comparison to a photo frame. Scrum is a nice photo frame, but if we put a bad photo in there, a nice frame won’t do anything, so it depends on how we carry out this Scrum implementation and then we’ll see if we get benefits from it.

Alright. Often when seeing job offers for a Scrum Master, a technical background is required. What for?

Michał Pięciorek: That’s an age-old… there are two schools and an age-old battle rages over whether this Scrum Master must be technical or not. And so to speak, both approaches have their pros and cons, because now, you know, if a Scrum Master is technical, they are an additional person on the team who gets what’s going on, is able to help somewhere, and is an extra person who understands all the complexity of software creation. So that’s an undeniable plus.

The downside of this situation is that the Scrum Master in this case must be very aware of what role they are playing. That means whether they are acting as a developer, because you can of course combine your roles like that, but when this Scrum Master speaks up, they must limit whether at that moment they are a developer or a Scrum Master. The downside is that abuses of the position can occur, meaning everyone in Scrum is equal and we are one team, but obviously if someone has a separate role, their opinion might influence things so that decisions are forced slightly from above. So there is such a risk, for the Scrum Master to know what role they are stepping into.

And that’s the technical part. If we talk about a non-technical Scrum Master, then it’s the reverse. The downside is that they won’t help the team, won’t say, look, you’re doing this wrong and we should adopt other assumptions. However, the plus is the fact that they don’t have to at all, because the role of a Scrum Master is entirely different. They should look at the team as a whole and look for these mini-improvements.

The plus is also that without understanding what is technical inside, they look at the product through the eyes of the end user. That means they don’t have to know what framework it’s in at all. Just like the end user doesn’t care about the technology. Whether it’s in this framework or that language, it just has to work. So even trying to find out how it works slightly forces the team to adopt that perspective through the eyes of the end user, right? And I think that’s a plus.

It’s known that most companies prefer the Scrum Master to be a technical person. However, I personally believe a good Scrum Master doesn’t have to be. They can be, but it’s not a mandatory requirement because their role is somewhat different.

Bartek Śliwa: Clear. You also touched upon combining these responsibilities and mentioned a case where the Scrum Master is also a developer, for example. I think then we must have a very mature team, and unfortunately life shows, or at least from my observations it follows, that very often organizations want to cut costs and therefore dump the Scrum Master’s responsibilities onto a developer who doesn’t necessarily know how to perform that role, and distortions happen then.

Michał Pięciorek: That’s right. Those are those minor deviations. In those cases, Scrum doesn’t give the full value it could give. Because truly if a developer does this on the side, then that’s not their main interest or main duties. So some… may happen.

At that point, this developer might not notice the waste appearing along the way, but I also agree that I see it that way in some cases. That’s why there are three roles and each is responsible for something different after all.

Bartek Śliwa: Exactly, but all three roles are responsible for delivering the greatest value. And what is this value anyway? Because it has quite a few definitions, probably everyone understands this term differently and probably we can come up with some term of our own now and someone will agree with it or not, but let’s try to frame it somehow. What is this maximizing value using Scrum about?

Michał Pięciorek: Meaning what are the benefits of using it, is that what you mean, or what is the definition of value, then we could…

Bartek Śliwa: Interpret it however you want.

Michał Pięciorek: OK, so it seems to me that the advantage of using Scrum is that it allows you to very quickly verify certain business assumptions. Because OK, everything looks beautiful on paper and in Excel. If a company wants to create some product, well, you know that at the presentation and goal-setting stage in a room, everything is great. However, it may turn out that ultimately, well, we can create a product that doesn’t quite match user needs.

Now, if we work in Scrum, we don’t have to spend a whole year on development and only at the very end find out that hey, actually nobody wants this product. So, those are budget, time, and effort savings as well. The advantage of Scrum is also that it doesn’t require creating the product all at once and delivering a finished product immediately. We can create a part of the software that works and measure on an ongoing basis whether it meets expectations, whether it reaches clients, whether our assumptions were right. If they are right, great, we move on. After each sprint, meaning after each stage, we build another working functionality and we build this software step by step. It’s a bit like building a castle out of blocks. We have blocks, we want to build a castle, but our vision can change over time. We can add one element, change another, and that allows us to tailor the product or whatever we are creating to our needs.

I had another thought. Would you agree with the thesis that if we don’t involve these stakeholders, this business, using Scrum makes no sense?

Bartek Śliwa: I think so, because the greatest value is precisely this close contact, whether with stakeholders or above all with, well, the end user, because okay, stakeholders are very important, but the client is always the most important, because we do it for them. And if the client, if we hit the need and fulfill those needs, then the stakeholder will be satisfied as well. And if we don’t have this feedback loop, this information loop—listen, are we going in the right direction, does what we’re doing make sense?—then we lose one of the most important values, because that’s what it’s all about, for these feedback loops to be short, fast, and substantive.

Michał Pięciorek: So simply speaking, a proper Scrum should somehow force this so-called inspection and adaptation loop upon us, meaning looking at what the team delivers through the potential recipients of this product. Exactly.

And well, you also have to be completely honest. Not all decisions—because now of course we praise Scrum—however, not all decisions will always be correct. And now, OK, if something turns out… we make a mistake, a normal thing, it happens, at that moment we don’t have to go further and persist in these flawed assumptions, we just cut it off right away: “listen, this doesn’t work,” we throw it out, and with every loop, with every sprint, we learn more and more about the client and requirements, so the final outcome is much better and responds to concrete needs, and not to what we came up with in a closed office, right?

Bartek Śliwa: Meaning responding to change over following a plan.

Michał Pięciorek: Exactly. Like, I don’t know, the Agile Manifesto.

Alright, Michał, is Scrum the answer to everything? Of course not. I wish it were as a Scrum Master. Of course, I could praise it, but of course not. I’m also not such a… traditionalist. Yeah, yeah, to say Scrum is always and everywhere the most important. Of course not, let’s approach it with common sense. It all depends on what the need is, meaning what we have to do, because if, for example, if we want to build a house, we’ve already built our nth house, we know what needs to be done, what the stages are, what follows what, what the estimated cost is. Well, in that moment, if we have these types of projects that are repeatable, predictable, and we’ve already done them, stuffing Scrum in there makes total sense—wait, total nonsense and overcomplication.

Scrum works when we don’t know what the final outcome will be. These assumptions can change, and that’s why in IT it works very quickly, so to speak, because certain initial assumptions after verification may turn out to be inaccurate, so it also allows adjusting where they appeared over time. Perhaps the client changed or wants to adopt a completely different strategy, so as I say, we don’t have to create the whole product at once and find out at the end, “hey, this actually makes no sense,” but we do it step by step and check here whether everything is fine.

Bartek Śliwa: Exactly, if we were to consider in relation to IT what types of digital products apply, are suitable to be implemented in Scrum, because I assume a simple landing page not necessarily anymore.

Michał Pięciorek: No, I think in products, maybe not innovative, but… Meaning certainly too. But in products where there are a lot of assumptions, it’s worth…

Bartek Śliwa: Assumptions, not certainties, that’s probably the key.

Michał Pięciorek: That’s right. When we create a completely new system and as I mentioned, assumptions in a closed office at a presentation can be great. However, later we verify this with the market, and well, here we decide whether it’s a good idea or not. If our startup idea, which of course is always great, after two or three iterations turns out to not quite hit client needs after all, it’s better to cut the topic short or change the assumption at the very beginning than to persist and burn huge budgets on it and find out about it after a year. So Scrum works great in such uncertain projects where there are a lot of variables, a lot of assumptions.

Bartek Śliwa: Exactly, with this uncertainty, because you know, if we made a book that is documentation full of assumptions, then such a C-level or precisely, directors, people responsible for the creation of a given product, they feel confident that they know what they expect and that this is definitely it. And how to shake them out of this sense, out of this conviction that everything will actually go according to the book they wrote, which they meticulously prepared for half a year?

Michał Pięciorek: I think a factor here for sure will be the financial aspect. Meaning, if we go out with a part of the product to clients and it turns out there is no demand and yet these results are not as great as on the green charts. But they will only find out about that after release. And development will take 2 years.

That’s why a good practice is releasing as often as possible, as frequently as possible, so as not to give a finished product to the market all at once, but to deliver it incrementally year by year—step by step. Because it may already turn out at the beginning that our assumptions are wrong and at that point there’s no sense in burning further budgets. So Scrum eliminates waste, financial waste as well. As I say, well, we can, if our assumptions are good, we can persist and OK, great, we create, we add this brick, whereas if they are bad, well, that financial aspect will be convincing for C-management.

And also… Scrum Guide doesn’t have this, but there is a document called Evidence Based Management. It’s a document that is somewhat an addition to Scrum. Precisely in this analytical context. Maybe we won’t go deep into it, this document isn’t large either, but it has about 30, maybe more—I think more—different metrics that allow us to measure and extract this specific data. And as I say, it makes no sense to use all metrics, because that’s measuring for the sake of measuring. Maybe not all of them are relevant. Instead, pick the key ones that will give us information that will be helpful and assist in decision making.

Bartek Śliwa: You know, I would actually probe into this Evidence-Based Management. I’m also a fan of this framework. We have four areas there where we measure. Do you remember?

Michał Pięciorek: Yes, Unrealized Value. That potential of ours for what we can still deliver there.

Bartek Śliwa: That’s right.

Michał Pięciorek: We have Current Value, meaning what we currently deliver and where we are overall, meaning what we deliver at the present moment.

Bartek Śliwa: We also have Ability to Innovate, meaning the organization’s ability to adapt to innovation, to generate these new ideas, and we also have Time to Market, meaning… it talks about how quickly we are able to deliver an idea, concept, concrete product, in what time we are able to deliver this value.

And then we can also check whether our Scrum works, whether we are actually delivering this value. As you said, it’s important not to take all metrics, but to choose a few specific ones, yet measure across all four areas.

Michał Pięciorek: Exactly. That’s an addition. The Scrum Guide doesn’t say this, but various supplements and such concepts have emerged. Higher levels of Scrum talk about this a bit.

Bartek Śliwa: A bit.

Alright, Michał. I have a concluding question or request, for you to share something that inspired you recently. It could be a book, a movie, some activity, maybe some life change.

Michał Pięciorek: You know, recently, regarding activity, all my life I thought I didn’t like mountains. Basically, I always associated it with sad school trips where you walked all day and basically you were tired and there was no joy in it.

However, I recently discovered it’s a great cut-off from our gray everyday life. I had the bad luck—meaning I didn’t have anyone to show it to me earlier—because I rather didn’t go to the mountains when I was younger, I rather had bad associations. It was shown to me that it’s something completely fascinating, I highly recommend it. Maybe not for everyone, but that changed for me recently, that, damn, I’ll probably go more often. Especially since from the south of Poland we are close. I didn’t even realize it, and I think that’s a recent change, so I highly recommend it.

Bartek Śliwa: Where were you?

Michał Pięciorek: In Karpacz.

Bartek Śliwa: I was in Karpacz too, but in a hotel. I had a good time as well.

Alright, Michał. Thanks for today’s conversation. And we invite you to the next episode of the Euvic Talks podcast.