Sunday, June 17, 2018

Test Pyramid Explained - part 1

Let's take a deeper look at what the Test Pyramid is, and how it can help us achieve sustainable, high quality. In this section, we will take a look at the left part of the picture only, as understanding this portion is essential to making sense of the right side.

Yet another model of the "Test Pyramid" - there's more to it than meets the eye!

The five levels

Before we get into the "How", we will examine the "What" - the five different levels, starting from top to bottom. Why top-down? Because this is how the business looks at software.

Process Chain Tests

A process chain is a description of a user-centric feature (oftentimes, a user story), irrespective of where it is implemented. From a high level, a customer might be something like "I want my order shipped home."
Such a process chain may consist of a larger number of technical features realized across a bigger number of subsystems, some of them potentially not even software. In our example, the process chain might look like this:

  1.  User presses "Purchase" (online shop)
  2.  User makes payment (payment provider)
  3.  Order gets sent to warehouse for picking (warehouse system)
  4.  Order is picked (picker's device + warehouse system)
  5.  Package is sent for shipment (logistics + logistics payment system)
  6.  Package is shipped (logistics + logistics tracking system)
  7.  Package arrives (logistics tracking system)
  8.  Order is closed (online shop)

As we can see from this example, it's incredibly complex to test a process chain, as each system and activity has a chance to fail. The potential amount of failure scenarios are nearly infinite - regardless of how many we cover, there might still be another.

The good news is that if a process chain works, it's a guarantee that all subsystems and steps worked.
At the same time the bad news is that - if the process chain doesn't work, we may need to do a lot of trackbacking to discover where the failure was introduced into the system.

Regardless of how much we test elsewhere - it might just be a good idea to do at least one supervised process chain test before "going live" with a complex system. That is, if we can afford it. Many organizations might simply resort to monitoring a live system's process chain in a "friendly user pilot phase".

A process chain test might take anywhere from a few minutes to many weeks to complete. As a rule of thumb, lacking any further information, an hour to a day might be a solid guess for the execution time of such a test. This explains why we don't want hundreds of them.

System Tests

Slightly simper than process chain tests are the oftenplace common system tests: The system is considered an inseperable unit - oftentimes, a "black box".

A system test would be concerned with the activities and data transfers from the time data enters into one system until the sub-process within the system is closed. Resorting to our above example, a system test of the Online Shop might look like this:

  1.  User presses "Purchase" (Webshop)
  2.  User's order data is persisted as "Payment Pending" (Database)
  3.  User is redirected to payment section (External Payment service)
  4.  Payment is authorized (External Payment service)
  5.  Payment authorization ID is persisted (Database)
  6.  Order Status is set to "Payment Complete" (Database)
  7.  User is redirected to "Thank you" page (Webshop)
  8.  Order is forwareded to Warehouse system
  9.  Warehouse System sends Order Acknowledged message
  10.  Order Status is set to "In Process" (Database)
Here we see that system tests, despite having a much smaller scope than a process chain, are still nearly as difficult to test and stabilize. 

Oddly enough, many so-called "test factories" test on this level, creating complex automation scripts - oftentimes based on tools such as SeleniumIDE - which is seen as a feasible way to automate tests with little effort.
The downside of automating system tests is that a minor change in the test constellation will invalidate the test - in our example, if the "Thank You" is replaced with a modal stating "Your order has been completed.", we might have to scrap the entire test (depending on how poorly it has been written).

I have seen entire teams spending major portions of their time both figuring out why system tests failed - as well as keeping up with all those feature changes invalidating the tests.

System tests shouldn't take all too long, but 5-15 minutes for a single automated test case isn't unheard of. Fast system tests might finish in as little as ten seconds.

Integration Tests

Integration tests are inteded to check the I/O of a system's components, usually ignoring both the larger scope process chain and the lower level technical details. 

An integration test assumes that the preceding steps in the source system worked - the focus is on the system's entry and exit points, considering the internal logic as a black box.

In our webshop payment example, we might consider the following autonomous integration tests:

  1. When a user presses "Purchase", all items from the basket are stored in the database (UI -> Backend)
  2. When a user is forwarded to the Payment Website, the total purchase price is correctly transferred to the payment service (Backend -> payment system)
  3. When a payment is successfully completed, the payment data is correctly stored (payment system -> Backend)
  4. When an order is correctly paid, it is forwarded to the warehouse system (Backend -> warehouse system)
  5. The Warehouse system's order acknowledge is correctly processed (warehouse system -> Backend)

Integration tests are much smaller than system tests, and the root cause of failure is much easier to isolate.
The biggest downside of integration tests is that they rely on the availability and response of the partner system. If a partner system happens to be unavailable for any reason, integration tests can not be run.
I've seen this break the back of one webshop's test suite who relied on a global payment provider's sandbox that failed to answer during business hours, because it was constantly bombarded by thousands of clients.

Integration tests don't do all that much, their downside is the response time of the two systems. Good integration tests shouldn't take more than maybe 50ms, while poor integration tests might take a few seconds.

A good way to speed up integration tests is by mocking slow or unreliable partner systems, which can also speed them up massively, but adds complexity to the component's test suite.

Feature & Contract Tests

This group simultaneously contains two types of testing, as these go hand in hand: Feature tests are the internal logic how a system processes data. Contract tests validate how the data is being passed into / exits from the system.

Here's an example of a feature test:

class BasketValidationResponseSpec extends Specification {
   def "information given to customer" (BasketPojo Basket, String message, Boolean status ) {

   Basket.statusMessage() === message
   Basket.checkState() === status

   Basket | message | status
   [ Bread[1], Butter[1], Book[1] ] | "Valid" | true
   [] | "Empty basket" | false
   [Bread[199] ] | "Too much Bread" | false
   [Bread[1], Butter[199] ] | "Too much Butter" | false

(please forgive my indentation, HTML indentation is a pain)

Feature tests don't rely on any external interfaces being available, making them both reliable and fast to execute. Unlike unit tests (below), they don't test each method on their own, but might test a the interaction of multiple methods and/or classes.

Contract tests are the flip side of the coin here, as a feature test assumes that the data is both provided in the right way and is returned in a way that the interfaced component can correctly process. In an ever-changing software world, these assumption are often untrue - contracts help create some reliability here. I don't want to go into that topic too deeply, as contracts are an entire field on their own.

The good news is that good feature and contract tests execute in as little as 20ms, making them both incredibly fast and reliable.

Unit tests

The bread and butter of software development are unit tests. They test single methods within a class, and good engineering practice dictates that any line of code beyond getters and setters should have an associated unit test.
The purpose of unit tests isn't as much to create feature-level or user comprehensible test feedback, it's to ensure that the code is workable - even when refactored.

Unit tests will ensure your code is loosely coupled, that each method doesn't do too many things (ideal amount: one purpose per method), that involuntary design errors are quickly caught and many other things which help developers.

While well-designed Feature tests answer the question "Why" a piece of code does what it does, a unit test defines "How" the code does it. Separating these two things often neither makes sense - the boundary may be fluid. The main difference is that a unit test never relies on anything other than the method of test, whereas a feature test might rely on full object instatiation.
Their main "downside" is that their lifetime is coupled to the method they test - whenever the method gets adjusted, the unit test either has to stay valid or needs to be modified. If the method gets deleted, the test goes as well.

Unit tests are extremely fast. There are even tools executing the unit tests of modified code in the background while the developer is still typing. The limiting factors here are pretty much CPU speed and RAM: executing an entire project's unit test suite shouldn't take more than a minute (excluding ramp-up time of the IDE), otherwise you're probably doing something wrong.

Given these definitions, let's do a brief...


Test TypeDurationAccuracyDurability
Process Chain1h +Very LowVery Low
System1-15minVery LowVery Low
Unit< 10msHighN/A

If you ask me if there's any sane reason to test on the higher levels of the pyramid - I'd answer: "It's too slow, too expensive and too unreliable." At the same time, there are reasons to test high in the pyramid, including: Coarse granularity business feasibility testing, lack of lower level automation and/or lack of developer skills.

In the next article of the series, I will explain the right side of the image - the testing metrics in more detail.

Sunday, June 10, 2018

Not Scrum - not a problem

We have been warned in our CSM training: "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum." - any deviation from Scrum leads to a dangerous "Scrum-But" - or worse ... so, you should stick to Scrum as per Guide!

Is that even a problem? Forget it!

Why would we even care if "the result is not Scrum"?

Here are a few examples of "results that aren't Scrum" ...

Unless you are in the business of producing and selling Scrum - why would it even be a problem if "the result is not Scrum"!

Scrum is but one of many means of achieving better business outcomes. It is neither a desirable outcome, nor the focus of your attention - again, unless you're making your money from Scrum.

As agnostic agile practitioners, we aren't forced to sell Scrum. We're trying to help our clients achieve better relevant business outcomes - more sales, more revenue, new markets, happier customers. If Scrum helps us get there, we're happy with Scrum as far as it helps. When Scrum becomes a distraction or an impediment - we'll gladly throw Scrum as per Guide overboard and do something else that works.

 "If you deviate, the result is not Scrum!" is a kind of fearmongering that only works on those who don't know that there are other, equally valid approaches. There's plenty of them around.

Saturday, June 2, 2018

Things that never meant what we understood

We throw around a lot of terminology - yet we may not even know what we're saying. Here are three terms that you may have understood differently from how the original author's intention:

1. Technical debt

Technical debt has been used by many to denote willfully taken shortcuts on quality.
Many developers use the term to imply that code has been developed with poor craftsmanship - for instance, lack of tests or overly complicated structure.

Ward Cunningham, the inventor of the term, originally saw Technical debt as a means of learning from the Real World - software built upon today's understanding incorporating everything we know at the moment put into use. He took the stance that it's better to ship today, learn tomorrow and then return to the code with tomorrow's knowledge - than to wait until tomorrow before even creating any code!

In his eyes, code should always look like it was consistently built "just today", never even hinting that it had looked different years ago. Technical debt was intended to be nothing more than the existence of things we can't know yet.

Technical debt always implied high quality clean code - because that is the only way to incorporate tomorrow's learning in a sustainable way without slowing down.

2. Kaizen ("Continuous Improvement")

Kaizen is often understood as an approach of getting better at doing things.
While it's laudable to improve - many improvement initiatives are rather aimless. Especially Scrum teams easily fall victim of such aimless changes when each Retrospective covers a different topic.

Taiichi Ohno, known as the father of the Toyota System which inspired Lean, Six Sigma - and Scrum, stated, "Where there is no standard, there can be no Kaizen".

Another thing that many of us Westerners seem to be unaware of: there's a difference between Kaizen and Kairyo - with Kaizen being an inward-focus exercise of becoming the best we can be - which in turn enables us to improve the system - and Kairyu being the exercise of improving the system itself. This, of course, means that Kaizen can never be delegated!

Kaizen requires a long-term direction towards which people desire to improve themselves. Such a direction is often absent in an agile environment - short-term thinking prevails, and people are happy having done something which improved the process a little.

What this "something" is, and how important it is in comparison to the strategic direction may elude everyone. And there's a huge chance that when we consider what we actually want to achieve, our "improvements" might even be a step in the wrong direction.
Have you ever bothered talking about where you yourself are actually heading - and why?

3. Agile

"Agile" is extremely difficult to pinpoint.  It means something different to everyone.
Some think of it as a project management methodology, while others claim "There are no agile projects".
Some think of a specific set of principles and practices, while others state these are all optional.
Some confuse a framework with agile - some go even as far as thinking that "Agile" can be packaged.
Some are even selling a certain piece of software which allegedly is "Agile".

Yet everyone seems to forget that the bunch of 17 people meeting at Snowpeak were out to define a new standard for how to better develop software - and couldn't agree on much more than 6 sentences.
Especially in the light of Kaizen above - What do 'better ways' even mean, when no direction and no standard has been defined?
A lot of confusion in the agile community is caused by people standing at different points, heading into different directions (or: not even having a direction) and aiming for different things - and then telling each other what "better" is supposed to mean.

The Agile Manifesto is nothing more than a handful of things that seemed to be consistent across the different perspectives: It answers neither What, How nor Why.
To actually make meaning from that, you need to find your own direction and start moving.

Thursday, May 31, 2018

Does "being agile" reduce IT cost?

Which truth is to the claim, "using the agile approach could cut banks' IT spending by 20% to 30%" as proposed by BCG and other consulting companies? 

I doubt that it will reduce a single penny in IT spending. Let me explain why.

Perspectives matter

Let me start with a metaphor.

As a hobby gardener, when I buy a new rosebush, I go to the garden shop and I can get one at around €10. It takes me about 1 hour to drive from and to the store and select a bush - and another 2 hours to plant it (hey, nobody said I'm a pro digger - a pro could do it in half an hour!)
Assuming that working time costs €80 per hour, let's compare the Cost of "planting 1 rose bush".
Hobby gardener:  €250.
Professional gardener: 50.

Superficially, you'd obviously turn to the professional gardener to plant your rose then.
Unfortunately, if I want a rose for €50, I would need to hire the gardener - full time.
And that means spending €60k annually on gardening, while I currently spend €1k.

So - it depends. Do you want to run one IT project, or do you want a cost-efficient IT that can deliver a hundred?
If I want only one rose, the professional gardener's cost is a few hundred times higher than the inefficient DIY approach.

As long as you focus exclusively on one project, cost for that one project is all that matters. Looking at IT overall, which constantly and consistently produces value, it's an entirely different story - which we will explore now.

The bottom line

Let's suppose I run an IT organization with 250 people. They cost me €20m in salary every year. Add 1000 servers that cost me €10m in hardware+maintenance every year.

In the past, I was working Waterfall.  How much did I spend? €30m per year. 
Let's say I switch to an agile approach.  How much do I spend? €30m per year.
Now where is the cost reduction? 

Truth is: Bottom line cost doesn't go down. 
Where are my savings? Do I fire people or turn off my servers to reduce cost? 

How agility reduces cost

There are many ways in which an agile organization has lower cost than a traditional organization:

Optimizing the work itself

When people are restructured into cross-functional teams where all people working to bring a feature into production cooperate in close proximity, a lot of activity dissipates. For example, we're no longer organizing a meeting to get information from each other - we just talk. We no longer write detailed specification documents - we collaborate to draft out something that everyone can work with, and then document only that which is needed for posteriority. We don't need to review DSD's any more, as we discuss until everyone has the same understanding. Oh - and since we no longer work based off a dead document, we can talk to the person. We're no longer tormenting our brain, "What did they mean?" - we just ask. And when we turn understanding into executable tests first - we're no longer getting into arguments whether the tester tested the right thing or the developer developed the right thing.

We can save a lot of time by reducing all of this scheduling, coordinating, intermediary documentation, reinventing the wheel and pointless arguments.

Optimize the flow of work

Traditional organizations often create huge batches of work, called "projects" or even "programs". These are intended to be delivered at a certain specified date.
Agilists would cut this batch into small, independent units and purposely descope all but the single one they work on and get that delivered. At best, they wouldn't even let the big furball of undone work accumulate and start working on every single item as soon as it become the highest priority.
By only having one thing to worry about at a time, we save efforts on task switching, status tracking and coordination.
We make work items independent and enable different teams to deliver autonomously. This massively cuts down on coordination overhead as well.

Optimize the content of work

Traditional project contain a lot of things which were considered to be important when the project was defined. Nobody really knows how much these features will actually be used until they went live - i.e., until the project is completed. By default, all project features are "Must-Have" (everything else isn't delivered anyways). A project must deliver the entire scope to be fully successful, so this is what the project manager will ensure.
Studies have shown that a good 50% of software features are "rarely used" or even "never used". Any effort invested into such unused features is burnt money.
As agilists, we would constantly apply the Simplicity principle and start incrementally increasing the value delivered. If the first simple version of the feature isn't even being used, we would stop building and focus on more important things.
We reduce the waste of building useless features.

Optimize value streams

When people can eliminate useless activity, they can deliver more features in the same time. By spending less time on delivering useless features, a higher percentage of developed features will actually help the business. By delivering in small increments instead of big batches, value gets into the hands of business earlier.

Optimize responsiveness

When new information comes up that invalidates old information, in a classic project, we have three options:
1. Ignore the new information. Do another project in the future.
2. Escalate as the project's goals are in danger.
3. Scrap the project and go back to the drawing board.

In environments where new information comes up on a daily basis, it's hard to fix something for months in advance. Many project managers have gone back to option #1, as that's the only way to ever conclude any project under such circumstances. Unfortunately, this means that the business always gets sub-optimal, outdated solutions.
While IT can perform well with this option, business performs terribly.
By reducing the lead and cycle time as well as delivering in smaller, incremental amounts, we reduce the risk that a specific new information devastates whatever we have been working on - and even if that happens, we reduce the loss incurred by incorporating the change.

We become more responsive to change, the main purpose of being agile.

All of this means - IT has a chance to become more efficient and more effective.
Oddly enough, none of this means that IT will be any cheaper.


The math is not "When you're agile, your IT cost goes down". It's "When you're agile, your business ROI goes up".
IT cost cuts are only possible when the organization is in the comfortable situation that they have too many developers and too little things that could be developed - a rather hypothetical stance, as not even corporations like Google or Amazon ever run out of work for developers.

What matters is not how much IT costs. What matters is whether an investment into IT is good. IT should have a high business value. And agility helps a lot there.

Cost - is the wrong focus. ROI is better.

Sunday, May 27, 2018

Three statements separating poor and great leaders

Many people think they are great, but when push comes to shove, they succumb to fear - and avoid doing the very thing that would be required for others to move forward. This applies to workers and managers alike - it's everyday leadership that we should all exhibit, or, as Tobias Mayer coined the term - it's merely "thoughtful citizenship". 
Here are three statements that many leaders might be too afraid to state:

I don't know

Smart people can easily come up with a plan or explanation which sounds so feasible that others will nod in appreciation. People with high charisma can make others believe even the most ludicrous things, such as for example: "clouds are actually giant, floating marshmallows".
This is very dangerous, as there is a huge potential of leading people on rabbit chases, and in extreme cases - even on witch hunts against those who disagree. The more respect a person receives, the more ready they should be able to state, "I don't know". Prominent leaders exercise great caution when making claims or providing instructions, as they have experience that a statement affecting many people can lead to massive problems, even when made from the best intentions.

I was wrong

"Hindsight 20/20". It's easy to be wise after the event. Statements about the future are always subject to error. Great leaders know this, and when they discover a dead end, they should be the first to pronounce, "I was wrong, we can't go on like this." Similarly, when they haven't seen the problem by themselves and are made aware by others, the three words will be like a rain of relief after a scorching summer: "I was wrong." - no lingering, no justification. Just closure. This open the door to progress. It frees others to go on.

I need help

Many people feel that exposing vulnerability is a sign of weakness, something that can and will be used against them. Great leaders don't care about weakness as much as about strength. Instead of saying, "I can't do this" - they say, "I need your help to do this!", knowing full well that everybody is good at something else.
In some cases, they will even ask others from help not because of their own need - they do this in order for them to grow and build them up! 


"I was wrong." - "I don't know" - "I need your help." 
These three sentences sound like they describe a weak person, even though saying these three things requires an incredible amount of courage. A person using these three sentences when appropriate displays massive strength of character and integrity. On the other hand, a person too afraid to speak these simple words when needed isn't worth following.

Do you have the courage to stand in front of your team, your company - even your own family - and say these words?
What consequences do you expect when you utter them?

Wednesday, May 9, 2018

How agile coaching changed me

When I actively started going into the direction of coaching, I was a typical consultant. In short: Do as requested, give the customer what they asked, play by the rules - help wherever possible, and be a nice person overall. All of that has changed. I will use Dungeons and Dragon's "Alignment Model" to explain what, how and why. To avoid confusion, remember that this is a model, not a religious view. The terminology is set like this simply because I'm copying a pre-existent model!

This is a rather personal post, I neither expect you to agree with my position, nor to adopt it. I created this post to encourage you to reflect on your own outlook at life with this model.
As coach, it's not our job to tell others the rules, they are well able to discover their own.

The model

One can sink quite a bit of time into this model, so I'll keep it short:

On the "Stance" X-axis is the distinction between "the belief that everything should follow an order, and that obeying rules is the natural way of life" (lawful), as opposed to "the belief that life is random, and that chance and luck rule the world" ("chaotic).

On the "Morality" Y-axis is the distinction between the belief that one should put the benefit of others before oneself ("good") and the belief that one can take advantage of others for one's own benefit ("evil").

The "Neutral" middle ground in either direction is a respectful attitude without any form of compulsion in either direction.
From a structural perspective, it means that law has advantages and disadvantages, and while order is often preferrable, it is neither attainable nor unconditionally desirable.
From a moral perspective, it is a stance that helping others is preferable to harming others, yet taking care of oneself and those with a close relationship is more important.

My journey

The past

For most of the past ten years, my behaviour could have been described as "Lawful Good" in the model.

My stance
I used to believe in explicitly defined structures and processes. I supported organizations and managers in optimizing their structure, defined rules, created process charters, developed and conducted change initiatives. I monitored and enforced the adherence to plan, structure and rules. It was my duty.
That's "Lawful".

My moral attitude
I always believed that I must help others and that my contribution is important. Is that bad? No - and yes. I made thousands of hours of overtime to help projects and help my company succeed. I didn't have time for friends or family. I neglected those who should have mattered to me in order to help others. Help them succeed, help them earn money, help them advance their career.
That's "Good".

The journey

As I started the coaching journey, I already had some issues with Scrum and the ScrumAlliance's moral setup. But because my company wanted me to become a CEC, I tagged along, so I applied. I got rejected, but that's a story I already told.

How my stance changed
As coach, I learned that it was the structures, processes and rules which destroyed the productivity of intelligent people in so many different ways. For example, developers are forced to commit to plans that can't possibly work out, they are expected to make a forecast on the Unknown - and they are entrenched with processes which forbid them to do the right thing.
I learned that neither is structure always helpful, nor does predictability always exist, and there's no way we can correct that once for all.
There was a short time when I resented and loathed hierarchy and structure, but it was a phase. I have become agnostic to those things, seeing both ups and downs.
I came to accept that we can't know upfront whether the rules we're following are helping or hindering, and rules themselves can lead to both good and evil: One can't be good and support evil rules.
I learned that a "Lawful" stance can achieve the opposite of what it is meant to do.
I have taken a "Neutral" stance ever since, being much more wary of the impact a rule might have.

How my moral attitude changed
Through reflection, I came to realize so many things:
First, that "well meant is the opposite of well done", aka. "The road to hell is paved with good intentions" - I had no way of knowing whether the help I provided was actually achieving its purpose. Too many times, things happened such as misguided transparency bringing people into trouble, well-meant processes misfiring and causing damage yada yada.

And the worst part - the people whom I helped and for whom I sacrificed so much were, for the most part, evil (based on this model). Not evil like Dr. Mabuse or Hannibal Lecter - but they hired and exploited me as well as others for their own benefit. The systems I created exploited many for the benefit of a few. And I let it happen!
Being good doesn't mean the outcome is good.
I have since learned that trying to help others is a double-edged sword. I have taken a "Neutral" attitude, dropping the concept that doing things for others is better than enabling them to do things on their own.

That's me

I classify myself as "True Neutral" in the D+D model, and I'm proud of having come there. I am no longer under a compulsion to do something for others, and have become unwilling to further an "evil motive", as in letting others take advantage or oppress me.

I can appreciate beneficial rules and structures without losing my freedom to scrutinize anything that I disagree with. I accept that we can't control the future, and understand that tremendous harm can be caused by trying to create a "perfect system". While I have no problem with ambiguity and uncertainty, I understand the fears of people who prefer to be stuck in a bad structure towards having no structure.

I can positively respect both Lawful and Chaotic people, I can get along with both Good and Evil people, but I don't have to be like them or support their cause. I prefer a good environment over an evil environment, but I won't go on a crusade to make it the way I think it should be. Instead, I will seek balance with my environment and harmony with the people around me. 

I work to help others gain a deeper understanding of their situation, so that they can freely choose to take whichever course of action they consider most suitable. At the same time, I reserve my right to not join them on a course I personally disapprove.

I am "True Neutral".

Thursday, May 3, 2018

The "Technical Triangle" of Effort Distribution

"The TQB Iron Triangle" has long since been overhauled. Still, there is a tradeoff that we need to make - and we all do this, every day. Unconsciously. The Effort Distribution Triangle is one way to bring the tradeoffs we make into visibility, so we can have a meaningful discussion whether we're making the right choices.

The Model

The label indicates "We aren't investing into it" and the opposing line indicates "Everything invested into resolving this".
The normal condition would be somewhere in the middle.

We have 100% of our effort to distribute. We can invest it any way we choose into delivering features, improving technology and discussion about goals and methods.
Regardless of how we distribute our effort, 100% is 100% - so choose wisely!

Opportunity Cost

By delivering features that might add value to our product, we do what development teams are supposed to do: create tangible business value. We always need to keep sight of business value, as this is the purpose of doing development work.

At the same time, excessive focus on delivery might cause us to neglect the underlying technology or communication.
In turn, the risk we run by spending too much time aligning and optimizing our technology is the time we lose on innovating and delivering things others need. This is our opportunity cost.

Technical Debt

Phrased positively, "Continuous attention to technical excellence and good design enhances agility."
It allows us to get more things done faster, and make changes with less effort.

Taking a pessimistic view, everything that isn't as good as technically possible can be called "technical debt". We always have technical debt, so at best we can control whether we consider the debt pressing or not.

Sometimes, we just want to get something through the door, and we're cutting corners on a technical level. We might have skipped the occasional refactoring, or anything like that.
Without accusation, I have observed many developers who prefer spending time on improving technology over time spent in meetings. While there are bad meetings, the consequence might be that some people don't understand things they should understand - communication debt!

Communication Debt

As mentioned in another article, "communication debt is the communications we should have had that we didn't have".
Good communication provides alignment, transparency and clarity of purpose. It's the basis for autonomy and self-organization within a company.

Communication takes time. Scrum, for example, dedicates five Dailies per week, plus one Planning, a Review and a Retrospective plus occasional Refinements - for a total of roughly 15% of your calendar to pure communication, and it's incredibly difficult to function as a team by going any lower. And that doesn't even include work floor communication, such as whiteboard design sessions, pair programming, code reviews and whatnotever.

Communication effort is an integral part of your total capacity to do things.
While some effort put into communication is in fact part of your ability to optimize both delivery and technology - there is also communication aside from that: Like letting other people know what you're doing, letting them learn from you or learning from them.

Make your choice

Take your pick anywhere on the triangle. Discuss the long-term consequences of this choice with your team. This choice is never once-for-all, you can always change it. Yet, there are choices of strategic nature and choices of tactical nature.
Strategically, a delicate balance is most suitable to maximize sustainability. Tactically, the team might decide to go all-in on technical improvements or feature delivery. That's not viable - so the Scrum Master and Product Owner should keep an eye that the triangle doesn't get too lopsided for a prolonged period of time.

Closing question

Who in your organization is making that choice for your team - and who is aware of the consequences of this choice?

Sunday, April 29, 2018

Environmental influence on Planning

"How can we make an Iteration (Sprint) plan to deliver an Epic when we still have too many Unknowns?" - this question plagues many teams on their journey to agility. Let's explore!

Someone asked me this question, and I have observed a similar thing in other teams before. In a (formerly) Waterfall-Oriented environment, a developer claimed, "We can't tell you how much effort this is until we have the Specification document!" It's the same question, just in different form.

Environmental influence

There are so many environmental factors in here that contribute to the statement being a problem which needs to be solved that I am tempted to write an entire book about it. Without digging any deeper, here are just a few factors which hint that the initial question is merely the symptom of a more severe problem:

  • Fear. For example, fearing the Unknown, fearing to not deliver, fearing to fail, fearing to disappoint - the stronger the fear element is, the more likely people will demand a reliable plan.
  • Ambiguity intolerance. People or structures with low ambiguity tolerance prefer a bad plan, doing the wrong thing right over no plan and doing the right thing.
  • Priority issues. If we're really working on the most important thing, the question isn't as much how long it takes as what is the best way forward.
  • Alignment issues. An organization which expects teams to create reliable plans upfront, shouldn't be confronting developer teams with completely unknown topics just a few days before visible results are expected. 
  • Slicing issues. There are always opportunities to deliver something based on an upfront plan and show some form of result, although the total amount of work required to get the expected final result doesn't decrease by putting more effort into creating thin slices.
  • Scoping issues. An Epic that takes more than an Iteration can't be planned down to a Sprint. The best thing we can do is deliver a portion of the work.
  • Push process. When stakeholders push work into the team and expect a specific result in a fixed time, we end up with the typical "Iron Triangle problem": Fixed time, fixed budget, fixed scope. What's left is a compromise on quality.
It should be the responsibility of management, ScrumMasters and coaches alike to create an organization where these issues aren't so relevant.

All that said, there's always the chance that something happened and we need a kind of solution quickly. In the first step, it's important to understand which of the above environmental constraints we have, and how strong or weak these are in relation to the team's work.

For example, if the fear factor is high on team side, we need to approach planning and delivery different from how we would if the main issue is unfamiliarity with slicing.

In my next article, I will explore some techniques in complete disregard of these external constraints that can help a team confronted with planning a completely unknown topic.

Friday, April 20, 2018

Want trust? Deal with fear!

"Fear is a bad advisor!" - proverb.
Positive working environments require trust. Trust can be given and earned - it can't be forced or demanded. Team building workshops often focus around building trust. Are they dealing with the symptom of distrust, though?

Here is a causal loop diagram modeling the relationship between trust and fear:

There is a direct relationship between trust and fear: Fearful people don't trust. Trustful people don't fear. Then, how do you get from A to B? It's not as easy as extending trust, although that helps.

The vicious circles

In the model, we see three different vicious circles which need to be broken almost simultaneously before trust can be established. I also hint a way to break these vicious circles.

Blame Games

Starting on the top left, the most visible fear cycle is related to Blame. Nobody likes to be blamed. Being afraid of blame, people hide their mistakes. in consequence either finding someone else to blame ("But you said ..." - "X told me...") or, when caught, receiving blame. Positive management must end blaming peole. Blame helps nobody. Identifying someone responsible should never be aimed at having someone to blame, it should always be aimed at finding a way to change things for the better.
As coach, I have even resorted to the rather ridiculous tactic of saying "Ok, it's my fault. Now, how can you make sure it doesn't happen again?" - of course, it's ridiculous that it's my fault. That's not what matters. What matters is that the discussion about fault ends and we start talking change.


The next vicious circle is related to information hiding. It's much harder to spot, as one can't know what one could know but doesn't know because it's being kept secret.
It takes a lot of sleuth work to put missing pieces together and discover where people are covering up inportant information revealing what is really going on. Why do people do this? Often, they either don't trust what will happen when uncomfortable facts are revealed - in which case it's a trust issue, or they know what will happen and don't like that - in which case it's a fear issue.
People wouldn't be afraid if failure was not perceived as a stigma with negative repercussions. Establishing a positive failure culture, "Hooray for failure" can go a long way. Just make sure that this Hooray is then hooked up with real learning and change - otherwise, a team member's trust in the team can turn into an outsider's distrust in the work of the team.

Choking Control

The third vicious circle is related to controls. Be that meetings, reports, supervision or checklists. While every single of these isn't necessarily bad, in sum, they can devastate people's ability to think, act and change. One control may be no issue, a hundred controls make it impossible to change anything - and simultaneously, often create a self-contradictory system where at least one control is always broken. People are constantly afraid of breaching control and spend more time on meeting control requirements than on doing actual work which helps the organization.
Managers stop trusting their employees when controls are broken, and employees stop trusting their managers when broken controls don't lead to more effective ways of working, but more controls. At worst, managers also stop trusting their controls when these prove ineffective and load yet more controls to control the controls.
Creating transparency what is truly going on and which processes are actually enforced by these controls can go a long way in abolishing their destructive force and minimizing control to truly helpful levels.


"Don't fear" or "We can trust one another" are hollow slogans. These don't help anything. "Building trust" without understanding the vicious circles and loopback dynamics leading to the low levels of trust we often observe in organizations.
The main lever for raising trust isn't simply building trust, but alleviating the fears which constantly chop at any small flower of trust sprouting up.

As coaches, we must understand both the fear dynamics and the fears driving people. Only then can we build the trustful environment needed to succeed.

Monday, April 2, 2018

Top 5 Ways Companies Hamstring their Development Process

Consulting with dozens of companies, I have come up with a list of the most common impediments that damage a company’s ability to generate maximal business value from development.

As profit goes down, companies are looking for ways to improve
- although the search is in vain unless root causes are dealt with!

“Business Value” is the positive business outcome of development (eg., Money earned, customer satisfaction, market share, conversion rate etc.), minus all costs of producing this outcome, including the delay incurred until gaining it, adverse side effects and opportunity cost of not doing something else instead. Or, in simpler terms, Business Value = success.

The following factors are commonplace, yet most companies are so oblivious to the damage these things cause that they might even be unwilling to deal with the issue:

#1 Communication

Regardless of whether it’s top/down, peer-to-peer, internal or customer facing - communication proves to be the #1 challenge in doing the most valuable thing.
Middle management filtering critical information, unsuitable use of media causes misunderstandings, waiting for responses causes unnecessary delay. Even then, not talking and acting upon assumptions often leads to the worst waste.

#2 Trust

Double-checking, approvals and permission processes as well as any other kind of control just keep people from doing that which helps the company most.
While something may always go wrong, a company built on the assumption that employees will purposely damage the business means you’ve lost already.

#3 Processes

Artificial process constraints lead to inefficiency in achieving results, oftentimes impose suboptimal solutions, are often associated with inherent waste, and might enforce unnecessary handovers.
Standardized processes are good for things where you don’t want to invest even a single minute into, yet development and its outcomes aren’t part of those.

#4 Structure

Inflexible organizational structures create indirection and dependencies, result in unavailability, reduce effectiveness, induce delays and limit the opportunities for value creation. Structural issues might reduce a developer's ability to deliver by a good 95%. As Deming said, "a bad system beats a good person 100% of the time".

#5 Saving money

Avoiding to spend money on that essential, "out of budget" component may result in a seemingly more inexpensive solution which may be a hundred times less efficient, potentially to the point where they might eat up the entire value proposal of the development effort.
Bottom line: money spent is irrelevant as long as that spending is below the value obtained. Keen spending goes a much longer way than vigilant budget maintenance.

Bonus: Consequences

#6 Artificial Dependencies

Closely related to communication, structure and trust, when people are forced to synchronize with others on topics they would have under control, the incurred communication overhead tranlates directly into reduced capacity, therefore a multiplicative factor in value reduction.
Such artificial dependencies might include non-value adding functions, such as reporting structures, centralized institutions such as "Enterprise Architecture", "Test Department" etc. As the proverb goes, "Make everything go over your desk and you are important."

#7 Lack of customer interaction

Low trust, bad communication or unsuitable processes, organizational distance etc result in an inability to deliver small increments. Every step taken without involving the customer directly is full risk of delivering zero value. This often produces a vicious circle where more and more risk is pushed downstream until all development happens without customer involvement, who is then usually disappointed to receive a worthless product.


Managers are continuously looking for better ways to get work done which allow them to keep the above things in place. Until we realize that the business relevant outcomes of the work are dependent on dealing with the above factors, all improvement initiatives will at best yield an efficiency increase without offering a better outcome.
Significant improvements in outcome fully depend on doing the right thing in the right way, and that means resolving the key issues around communication, trust, processes, structure and spending.

Sunday, March 25, 2018

The IOWA-Number - a tool for team building

Not every person contributes equal amounts on the team, and that's often okay. But there are some cases, where a conversation is needed. I devised the IOWA Number as a tool to identify these cases.

Applying the tool

The IOWA Number can be used in the "Gather Data" stage of a Retrospective with the question: "How do you feel about your team members?" This does require a certain level of trust within the team to work properly, and be clear that the tool isn't meant to highlight people as problems, but much rather to help the team find itself properly. There is no score that's inherently good or bad, just some scores that will lead to further conversation down the road.
Most importantly, only apply the tool when you have a feeling that there are some outliers, as the tool is merely intended to open up a conversation on becoming better at collaborating!

Extremely low scores

In some, rare cases the team will feel that a person's absence will actually have a positive effect on outcome.
The most notable case of this happening is usually when said person is lacking so much knowledge that their questions disrupt the others' flow of work. A good way to strengthen the team would be to put delivery work a bit on the backburner and work intensely to bring the person back to speed.
Another common case would be that said person doesn't really understand the impact of their own way of working on the team, often due to being unfamiliar with others' self-organized ways of working.

In any case, team members with extremely low IOWA score need the team's support to rise to higher levels and the team should have an open conversation which behaviours are reducing IOWA score and which behaviours would increase it.

Moderate scores

Anything between 3 and 7 is usual. There's not much to discuss, unless there are tendencies towards an extreme. But since IOWA numbers are nothing more than a snapshot in time, it would be better to use the extreme value right away, as it doesn't make sense to defer a conversation.

Extremely high scores

There's no way to sugar-coat it, high IOWA scores are a risk, potentially even a threat to the team's sustainability!
People typically do not choose to have high IOWA score, they receive that score because they have superior understanding of a subject matter and a strong drive for action. Usually, they feel they are helping the team and the organization by working this way, and in fact - when it comes to getting stuff done, they help a lot.
Unfortunately, all of their help us unsustainable, as the team immediately falters when they aren't available and if for some reason, they should be out (e.g. sickness, family issues etc.) their absence could bring the entire team and whatever the team was working on to a standstill or collapse.

As I wrote in my book, "Extreme Agility", my suggested course of action would be to relieve the person from the responsibility of doing whatever they do so well and instead coach and support the rest of the team in this. It should be exceedingly clear that they aren't taken out of the delivering function because anything is wrong with them, but because they are needed as multiplicators in order to grow the team.


IOWA Numbers are a conversation starter when the team is on uneven footing. It's not intended to judge or condemn the work or contribution of any individual, much rather it is intended to bring people to a more equal footing in order to increase the team's sustainability.

In some cases, it may even be worthwhile to create IOWA Numbers for people in the team's close vicintity, such as traditional line managers. If this is done, be sure to include them in the Retrospective (which is rather unusual).

Monday, March 19, 2018

Continuous Deployment - more than a toolchain

A while ago, a prospective client approached me, "We've purchased a Continuous Deployment Toolchain, now we need someone to do the training." I was invited to meet the Head of Administration and an Admin team lead. 

Story Time.

Paying for vaporware

"Here is the toolchain we bought. We paid a six-figure amount for the strategy and a five-digit sum for the implementation. Now we need someone to train our Admins so that we can roll out the new process for all of our 500+ projects in the next Quarter."

I glanced at the Powerpoint slide.
If you think this is worth $100k, well ... I have a bridge to sell.

It's about culture!

I started asking: "Why the Admins? Wouldn't you much rather want to train the developers?"
I learned that this project was spearheaded by the Head of Administration and they didn't want the Head of Development to take credit for their idea. Plus, the introduction of Continuous Deployment (CD) was mainly supposed to relieve the efforts of the Admins.
Taking note, I asked: "So how did you come about this project in the first place?" In painstaking detail, the Admin team lead explained that the process of getting a release through the door often took months - and CD, automating the entire ordeal, would cut it down to minutes and free their time for much more important things.
Nodding, I probed: "So, the developers will check the code into git?" - "At the moment, they either send us the code via email or put it onto a Shared Folder." Remember - this was a good decade into the 21st century! "And then?" - "We manually compile the sources. In some cases, we've created some scripts to ease the job, but those scripts are brittle and fail with every new release." - "Have you considered giving the job of creating maven builds to the developers?" - "That's not their responsibility. We can't guarantee for the correct installation of the software any more if we let them do it."

Next icon. "What's Sonar supposed to do in this construct?" - "Check the code quality." - "Do you have code conventions or unit tests?" - "Neither." - "And who is going to do that job?" - "That would be the Offshore Testing Department."

This was getting more intriguing by the minute. "Are the Developers trained in the use of Ansible and Docker?" Shaking heads, "We will provide standard scripts and containers for others to use." Probing deeper, "How do you know which Ansible Configurations and Docker Images will be needed?" - "We will just create those which replicate our current environments." - "Are your Admins trained with either tool?". A smile, they figured that finally, I was coming to understand them: "That's why we need you."

"Just one last question, how are the tests going to execute?" - "If you look closely, after a Docker Container is created, it will automatically be deployed to the Test Stage for Manual Testing."

This was going to be an interesting ordeal.

Get ready for Continuous Deployment!

I devised a strategy and proposed the following approach:
  1. Basic Leadership training for beginning agile transformations
  2. Process Redesign Workshop to reconsider the current build process and responsibilities
  3. Start a Cross-Functional Team from across all departments to integrate the CD pipeline on one project in the next quarter.
  4. Coach this team in fundamental Software Craftsmanship - including Pairing, Test Automation and CI.
  5. Use the pilot team to set up meaningful quality metrics and create a working build pipeline.
  6. Involve others in the learning and gradually move towards cross-functional teams with e2e responsibility.

I was informed that my offer was probably a misunderstanding. I replied, politely, "If you ever choose to look deeper into this offer, feel free to reach out." They never did.

The toolchain is irrelevant until you have the culture and structure in place. CD isn't something that a single department in a silo organization can do all by themselves. Instead of architecting the entire pipeline upfront, experiment, discover what works - what helps - and what is actually being used!

If you seriously intend to move towards CD, the long journey and steep learning curve really pay off once the peak is climbed.
One disclaimer, though: There's no guarantee that you can keep any of your current processes, structures and mindset.

Sunday, March 11, 2018

Five signs you've got the wrong agile coach

You've set out to begin your organization's "Agile Transformation" and, lacking the expertise, you've brought in external consultants and/or coaches to make the endeavour successful. But since you're not agile yet, how do you know whether you have the right people on board?
Here are a few pointers that will help you identify rotten eggs - i.e. you can be almost certain that after the consultants leave, the show will be over, and best case you've only wasted money for nothing.

#1 - Lack of Battle Scars

Having the seniority to assist another organization in their agile transformation, the coach should have a lot of war stories to tell. Stories of experiments, pitfalls, troubles, joyful moments and cheerful victories. Stories of what they have experienced firsthand (not hearsay!).
What people tried, what they set out and where they landed - the differences between intent and destination, the obstacles and dangers on the journey - the small nudges that made the difference and so on.

If you see that the coach either has little to say from personal experience or is only quoting others ("double-hearsay"), beware!

#2 - A shelf full of solutions

It doesn't matter what your problem is, they already have the bottled solution ready! Just follow their advice, and you will become Agile. NOT!

Especially when they promote solutions as a silver bullet, i.e. universally applicable without concerns for context - you're in for trouble.

#3 - Change without change

Following pre-concocted agendas, outlining the change on fancy slide decks without ever talking to the people doing the actual work or knowing the real struggles they have isn't going to work.
The first three questions I would expect to ask: "Why would you want to become Agile?", "What will be different in a year?" and "What have you tried so far?".
If there are no comprehensible answers to these three questions: what exactly do you expect as a result?

#4 - Not rocking the boat

Many experienced consultants have learned to avoid challenging status quo and messing with people in positions of power. This is a great approach to maximize the amount of billable hours and to please those who decide whether their contract will be renewed.
As attributed to Einstein, "Problems can not be solved with the same mindset that created them.", it's essential to rock the boat - to identify and tell people about the root cause assumptions which lead to the problems that an agile transformation is supposed to solve. And if key decision makers aren't aware how they are contributing to the problem - how would they know what they must change to solve it?

Consultants who only compliments senior management aren't going to make an impact.

#5 - We've got this!

Probably the killer criterion for spotting fake coaches: They can do it by themselves! They have so much experience and expertise that whatever is brought to them, they have the right answer. Senior management doesn't need to involve at all, because the coach knows how to handle everything. Teams don't need to worry, because the coach will teach them everything they need to know.

The coach who offers the solution without teaching you how to find your own solution - doesn't help you learn, and if you don't become a learning organization, you're not going to be agile.


I would like to conclude with my favorite TheraminTrees quote, "People who don't want you to think are never your friends!"

A "coach" who doesn't make you think and challenge how you think - is the wrong coach.

Sour aftertaste? 
Let's fix this: Here are ten signs you might just have found the right coach!

Sunday, March 4, 2018

Eight character traits of good leaders

Many people like to be in a position of leadership - without ever considering what makes the character of a leader. In this article, I propose a list of eight character traits portraying good leaders, regardless of position, rank or role.

"Leadership" - image courtesy of @danielmassoud4 taken from


We acknowledge and respect people who walk the talk, who do what they say, who have and convey a clear purpose and work towards that purpose themselves.
Nobody would waste time with a hypocrite or someone who themselves doesn't know what they want or where they are headed. Good leaders spend a great deal of time considering what they want to accomplish and why - and their very being encourages others to join in.


We natually have a tendency to commend diligent people. Those who are pay the necessary attention to detail while still having a clear direction tend to be successful and a pattern for those around them.
It's often the small things that become the downfall of people in position in power - so great leaders take care not to get stumbled over small rocks.


People who are willing to go the extra mile for what they believe in serve as positive examples. Few can shrug off a setback and march forward with unwavering zeal - so those who do will eventually rake in successes that are the result of harsh failure learning. Like this, they become exemplary even to those who never knew about the troubles along the road.


When you firmly believe in what you do, you're unashamed and unafraid to act and speak. Even when we disagree, we still notice and acknowledge those who are bold to take a step, expose themselves and their ideas to a broader audience and are willing to take the heat and fire of criticism and resistance.


People look for those that do something for everyone, maybe even for others. On the other hand, we disdain those who selfishly try to fill their own coffers and get out of the line of fire. Because of this, we admire those all the more who put themselves out of the center of attention and put the social benefit of their ideas and goals first.


Everyone has different needs and different perspectives. We like to be accepted where we are and how we are. While bad leaders express ruthlessness and recklessness, good leaders spend time to accomodate those around them, making them feel welcome and cherished. Being social creatures, we tend to flock around those who make us feel comfortable.


"Measure twice, cut once" - when dealing with people, we often don't get a second chance, so it's best to spend time pondering how we and our actions affect those around us. We need to be watchful what we say and do - a single careless word can burn bridges. On the other hand, a nice word creates a positive atmosphere, a little support in times of need builds bridges and by moving from basic courtesy to full acknowledgement of others' circumstances, we become people who others enjoy being around.


"We all are where we are" - yet, that's no reason to stay put. Nobody is perfect, but we need to move on. Commendable leaders aren't only good at being who they are, they're continuously improving upon themselves. That character quirk we noticed yesterday is a great opportunity to reflect on how we want to be - and what we can do to be even better people today. By not being stuck either with themselves, their ideas or the world around them, the best leaders continuously adapt themselves, their ideas and their environment to move forward.


Leadership isn't about position. It's about who you are - and no classroom training can make you a leader. Only you yourself can do that, and you must work on your character in order to be one. This is not a one-time act, it's a lifelong process: The day you stop working on your character is the day you have stopped leading.

Saturday, March 3, 2018

What is a Scrum Master?

The question, "What is a Scrum Master?" may sound easy to answer - RTFM, the Scrum Guide has a very concise section. But when looking at what a Scrum Master really does, it becomes a profound topic in and of itself.

The narrow definition

The most narrow definition is that it's the one person on a single Scrum team making sure the Scrum Guide is being followed and the team successfully delivers on their Sprint Plan. Most people work in organizations that think of this narrow definition and also behave likewise.

For people looking to move into such a role, the best starting point is reading the Scrum Guide, getting a few books (such as Geoff Watts: Scrum Mastery) and a certificate or two (PSM-I from or CSM from Scrum Alliance come to mind) then start job hunting and learning on the job.
Sticking with the narrow definition is not a very fulfilling job, as systemic impediments never get addressed.

The broad definition

The most broad definition is that it's a person coaching an organization on becoming more agile, challenging existing paradigms and opening the way to more flexibility, and this means individuals, teams and managers on every level - from intern all the way to senior executive.


When it comes to being a Scrum Master in a broader sense, then Scrum is maybe 5% of the picture. In fact, Scrum itself will become less and less important and - just like the Agile Manifesto states - people and their interactions will become prevalent.

Agile Frameworks

The first thing you will need to explore is the other agile frameworks, starting with the team-level ones such as Extreme Programming and Kanban - and getting yourself familiar with the organization-level ones such as SAFe (Scaled Agile Framework), Nexus, LeSS (Large-Scale Scrum), DAD (Disciplined Agile) and S@S (Scrum at Scale). Of course, that doesn't mean you will be using all of these - but you should have a sufficient understanding to comprehend where they are useful and what their limitations are.


Having a bag of agile theory under your belt, you need to move into organizational design and management by reading publications from authors like Drucker, Deming, Crosby, Taguchi, Taylor etc - and learning to compare and recognize their models.


You will also want to explore the field of psychology to understand how and why people tick the way they do. That's a vast field, where you might want to reach into behaviouristics (Pavlov, Skinner), basic needs (Maslov), negotiation models (Ury), transaction models (Berns), habits (Duhigg) and many others.


To round this off, you may want to gain a deeper understanding of philosophy, which also has a lot to offer, with the most notable things you may want to get being logic (assumptions, fallacies, mental models), axiology and epistymology.

It's not very useful to do all of this upfront, but continuing to learn while you're on the job and working to continuously increase your sphere of influence within the organization.


The Scrum Master is a very deep role which, when taken with a deep, serious learning attitude, has a lot to offer and provides a tremendous field for growth. If you put your heart into it, you will reach tremendous awareness of and influence on your surroundings.
Don't let people tell you that a Scrum Master is "just a team role". Great Scrum Masters can make a massive impact on their organizations.