Do Scrum Masters need to be technical?

There's a neverending debate: "Do Scrum Masters need to be technical?" How would I answer this, based on almost two decades of experience?

My answer is a clear "Yes and No."

Accountability

Let's emphasize: Scrum Masters are "accountable for the effectiveness of their team." (Quote: Scrum Guide)
If a team is technically highly competent, a Scrum Master will focus on other areas such as team organization, collaboration with other teams, interaction with management, and optimizing value creation, for example. In this case, no technical skills are required.

In Practice

Scrum Masters, by virtue of their role, aren't technical experts themselves, but must definitely be able to identify technical problems and provide the team with a way forward.

In practice, many teams are far from being as technically mature as one would wish. Code quality is lacking, test automation is an ongoing issue, and many other small problems. Why? It's due to a lack of understanding of technical practices such as Continuous Integration, Refactoring, or Test Driven Design. Primarily, such teams face the problem: "How do I know what I don't know?" If the team recognizes that there's a technical problem hotspot somewhere, it is sufficient for a Scrum Master to work this out precisely with the team and ensure that they receive competent technical coaching and the necessary time for improvement.

That becomes difficult when neither the team members understand their technical situation and competence - nor does their Scrum Master. Then, the team is running head first, full steam ahead into a brick wall - and that will get really uncomfortable:
For the company, which in the worst case becomes long-term incapacitated and in any case loses millions.
Which, in turn, could lead to layoffs for the developers.
And in the middle of it all is a Scrum Master who is accountable for all of this - but completely clueless.
Very unpleasant.

Closing remarks

I've had good and bad experiences with Scrum Masters who have been in technical roles for years, and the positive ones are more numerous. I particularly want to positively highlight the qualification of QA experts who, by profession, are accustomed to questioning everything, uncovering problems, and, if necessary, confronting management.

Hence, I'm confident that having done technical work that helps a Scrum Master succeed is definitely an asset.

In Scrum we do ...

"How do you do this in Scrum?" - A common question, and still: not a meaningful question. Why? Let's explore.

Scrum has no prescriptions.

Scrum is but a container, and something that works within Scrum should also work without Scrum. If that's not the case, and something only works because of Scrum - you probably misunderstand Scrum.

Does it make sense?

If something makes sense irrespective of Scrum, you may want to try it. If you believe that it has to be done because of Scrum, but your senses are tingling - they may be right.

Does it work for you?

Whatever "this" is - how are you currently doing it, and does it give you the results you're looking for? If so - why would you want to change it?

A better question

We're currently doing this, and those are the issues we're facing. How could we address these?

Whenever you hear or say, "In Scrum, we do ..." - whatever follows next is either complete and utter nonsense, or has very little to do with Scrum. Most likely, the first.

10 signs your Scrum Master doesn't understand Scrum

As an enterprise Coach, I meet a lot of Scrum teams. Despite its widespread adoption Scrum is rarely done well. Many Scrum Masters, the pivotal role responsible for fostering a high-performing team, aren't even prepared to grasp the essence of their job. Being an advocate for continuous improvement and a firm believer in the power of sarcasm to make a point, I'm not here to cast blame or ridicule anyone, but to tigger a discussion. I genuinely believe that most Scrum Masters who find themselves in these situations came there unwittingly, and want to do better. But they may lack the right understanding or guidance to see what's wrong. So - here goes my Top 10 list of common pitfalls and misconceptions how a Scrum Master could get in their own way of fostering an environment of growth, learning, and continuous improvement:

10 Signs that Your Scrum Master Doesn't Understand Scrum

Customer Focus? Maybe Later - For Now, Let's Get Scrum Straight!

A Scrum Master who prioritizes "getting Scrum straight" over customer focus misunderstands the core value of delivering value to the customer. Scrum emphasizes customer collaboration and responding to their changing needs, ensuring that the team builds products that meet their expectations and bring maximum value.

Team Dynamics? We Had a Team Building Workshop at the Kick-off, So We're Good.

Believing that a one-time team building workshop is sufficient for effective team dynamics disregards the continuous effort needed for building and maintaining a high-performing team. In Scrum, fostering a collaborative and self-organizing team is an ongoing process, requiring consistent support and attention from the Scrum Master.

Transparency and Openness? Nah - Nothing Beats a Great Hidden Agenda!

A Scrum Master who drives a hidden agenda undermines the essence of Scrum's core foundation of trust. Transparency allows for honest visibility into the team's progress, challenges, and achievements, fostering trust among stakeholders. Hidden agendas defer problems caused by misalignment into the future, at which point they may have grown significantly.

Facilitation? Servant Leadership? No, They Need Someone Who Gives Them Clear Direction!

While there are reasons for being directive, that should be a last resort. Facilitating collaborative discussions and informed decisions improves understanding, and thereby reduces risk. By taking a directive stance as a default, the Scrum Master introduces themselves as a dependency into the team and hampers their growth and collaboration.

Focus on the Sprint Goal Now - We'll Talk About Impediments in the Retro!

Let's be clear - it's not an impediment unless it significantly impacts the team's ability to deliver value. What would you think about a car mechanic who told you, "Just ignore your flat tire, go to work and come back, you can always fix the tire later." Most likely, you won't be going anywhere with a flat tire - and even if you will, the price, cost and duration required to fix a broken hub will exceed the cost of the flat tire by orders of magnitude. While this could be necessary for survival, it should be an informed Product Owner choice, and definitely not a default strategy.

You Want Time for Learning? Just Look at All That Unfinished Work in the Product Backlog!

The Product Backlog is infinite, as it gets replenished in line with demand. A team deferring necessary learning in favor of Velocity loses their edge, and will eventually lose both. Learning isn't a luxury that competes with unfinished work, it keeps the effectiveness of the team up, and trades a bit of time in the short term for improvements to quality, scope and risk in the long term.

Releasable Product Increment? Once a Quarter - otherwise, it's Too Much Overhead.

Delaying the delivery of a releasable product increment contradicts Scrum's principle of delivering value with minimal delay. Even in settings where releases are scheduled at a low frequency, a failure to keep the Product in a releaseable condition introduces risk into the process: as long as our product isn't in a releasable state, we neither know how much work it is to bring it into this state - nor whether we will have the capacity to do so when we need to.

We Wouldn't Need Feedback if you Just Learn to Write Better User Stories!

Creating a false dichotomy between writing user stories and collecting feedback is a thorough misunderstanding of Scrum's empirical approach. User stories only inform us what we believe a priori about what users need, whereas feedback validates that we did indeed solve their problem. Just think of the last time you went to a restaurant and didn't like the meal: Would you have liked the waiter to blame you for not correctly specifying what you like?

That's the Standard Process. You Can't Change It Just Because It's Stupid.

Scrum is a vehicle for enabling the team to find the process that allows them to perform at their optimum. A broken or ineffective process leads this ad absurdum. Scrum encourages continuous inspection and adaptation to optimize processes and outcomes, fostering a culture of continuous improvement and innovation.

Definition of Done? Yeah, we have one ... somewhere ... Let me find it.

The DoD is one of Scrum's core commitments, as it defines how the team is committing to work. Lacking transparency, clarity or commitment to the Definition of Done is a common source of poor quality and conflict. A good, transparent Definition of Done builds shared understanding both within the team and with stakeholders.

Conclusion

Having a well-informed and capable Scrum Master is essential for a successful Scrum team. I have deliberately phrased the above signs with some sarcasm and hyperbole. In practice, they're often much more subtle. Recognizing them enables you to take proactive steps to improve the effectiveness of the collaboration between Scrum Master, team and stakeholders.

If you spot any of these signs in your team, maybe ... try raising it in the next Retrospective?

Let's Scrum better!

Ten things eerily close to Scrum that you may misunderstand

 There are some ideas around Scrum that sound a whole lot like they're based on the Scrum Guide - when, indeed, they aren't. Even worse: you might be doing them in a way that could cause problems. Let's dig in.

1 - Scrum Roles

If I ask you what the Scrum roles based on the Scrum Guide are, you're probably very quick to answer: "Scrum Master, Product Owner, Developer."

Wrong.

What? How can that be wrong?

Well, because the Scrum Guide doesn't mention any roles. Indeed, it doesn't even use the term, "role" any more. Scrum Master, Product Owner and Developer are merely accountabilities. That means, someone has to be accountable.

2 - Dedicated Scrum Master

The concept of a "dedicated Scrum Master" isn't mandatory based on the Scrum Guide. Neither is the concept that "a Scrum Master shouldn't be technical, so they don't dump their own bias on the team."

These ideas are often marketed in an attempt to provide job safety for the myriads of people who can do nothing else. You can do Scrum very effectively even if Scrum Mastery is an accountability that rotates among developers, for example, on a per-Sprint basis.

Caveat - they need to know what they need to do, and have enough time for doing it.

3 - Product Owners aren't developers

Neither is the concept of a "Product Owner who isn't a developer, so they don't interfere in the work" prescribed by Scrum. It's entirely possible that, for example, a senior developer assumes the PO accountability. As long as the Product Goal is clear, the Product Backlog well-maintained, Sprints deliver high value and stakeholders know what to expect, there's not going to be much of an issue.

4 - Team autonomy

Are Scrum teams really autonomous? Doesn't Scrum rely on team autonomy?

Try searching for the term "autonom" in the current Scrum Guide - you'll be surprised! Team autonomy isn't mandatory for Scrum. In fact, in larger organizations, it can't be - because if you have larger products, multiple teams need to collaborate.

Before proceeding, let that sink in:
Scrum teams are not free radicals.

5 - Each team has their own Product Owner and Product Backlog

Certain "scaling" approaches suggest that each team has their own Product Owner and Backlog. Well - for a Sprint backlog, that's true. But having a separate Product Backlog for each team adds problems rather than solving them. The Scrum Guide states that multiple teams working on the same product, "should share the same Product Goal, Product Backlog, and Product Owner."

Note that this isn't a Scrum rule, only a suggestion. I will leave it as an exercise to the reader to figure out why that is a good suggestion though. And if the answer is too difficult, try the book "Scaling Lean and Agile Development" by Larman and Vodde.

6 - Teams have their own Definition of Done

One of the first exercises Scrum masters typically do with a new team is to draft up their own Definition of Done. That's not necessary in larger organizations, because the organization could already provide a DoD. "But that's not Agile..." - no! On the contrary, it ensures that the term "Done" has a consistent meaning anywhere in the organization. It reduces complexity and misunderstanding. It's quite irritating when a stakeholder has to ask in every Sprint Review, "What ... exactly ... does 'Done' mean, when you say that?" 

Teams are encouraged to add details to the organizational Definition of Done. If they deviate from the organization-wide DoD, though, they invite trouble. Caveat - an organizational DoD should be absolutely minimal, lest it slows down teams with pointless busywork.

7 - Refinement meetings

"In order to prepare for the upcoming Sprint, the Product Owner invites the team for at least one Refinement meeting during the ongoing Sprint." That's a really common practice - but it's not what Refinement is!

Refinement is no Scrum event, for a good reason. Taking a peek at the top couple backlog items, maybe doing a small spike, or creating a wireframe, are all activities that can't really be done very effectively in a centralized meeting. They're better done by brooding over the items from your desk. And sometimes, reaching out to a user has a delay, and we really need the answer before moving forward. The asynchronity of refinement also ensures we don't disrupt the flow of work by having yet another meeting on our calendar.

8 - PO acceptance

During the Review, the team demos their work to the Product Owner, who then accepts it.

Search for anything even remotely resembling this concept in the Scrum Guide. It just isn't there. This sentence contains so many flawed concepts that if you practice this, I wholeheartedly advise a Scrum refresher training. 

The Review is about stakeholder alignment, and it's a working session, not an approval meeting.

The Product Owner also doesn't supervise any work done by developers - together with all the stakeholders, they inspect the outcomes of the Sprint, regardless of how much work was done or not done. 

Nobody "accepts" individual work items of the team. Developers meet their DoD, and that's it. If the DoD isn't adequate or the backlog items not sufficiently valuable, that's not a problem we fix by adding an approval step to the Review. We fix it by improving our DoD, refinement and planning approaches.

9 - One Increment per Sprint

This is probably one of the oldest misunderstandings of Scrum - that at the end of each Sprint, the team delivers one Product Increment which contains all the changes made to the product for the duration of the Sprint.

An increment is produced whenever a modification has been made to the product, and it's in a usable state. Scrum and MinimumCD are not at odds. Scrum teams can - and actually should - produce as many increments as possible during a Sprint, and also deploy and/or release them as early as possible.

During the Sprint Review, the sum of all increments produced since the last Sprint Review is inspected, as these are the outcomes of the Sprint. This sum could be anywhere from zero to infinity. A team which only works towards a single, integrated Increment at the end of a Sprint, will be much more likely to find themselves empty-handed, so that's a bad strategy to begin with.

10 - Backwards-facing Retrospectives

"The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved."

That's a literal quote from the Scrum Guide, so isn't isn't the Retrospective pattern of "What went well, what didn't go well, what we could improve?" - the best way to conduct a Retrospective? No.

"The Scrum Team identifies the most helpful changes to improve its effectiveness." - that's also a quote. Of course, we need to have consider what happened in the last Sprint. The purpose of our Retrospective, however, is looking forward, identifying the most helpful changes. If all you do in your Retrospectives is dwell on the past and make miniscule adjustments so that the same old problems don't constantly haunt you, you're not future-proofing your team.

The most helpful change you can make is that which will make you most successful in the future - which may not necessarily be fixing a problem you had in the past.

Bonus - Ceremonies

It sounds like an innocent mistake, but there's a huge issue hidden behind this label. Scrum events are called "event" instead of "ceremony" for a reason.

An event is, literally, "when something notable happens."
A ceremony is, literally, "doing what we always do in the way we always do it." 

Organizations implementing Scrum "ceremonies" usually find themselves getting very low value from these, not understanding why they're important - and not thinking about better ways to achieve better outcomes. 

As a consequence, we see purely mechanical Scrum which helps nobody, gets on developers' nerves, and the one thing that makes agility tick - Double Loop Learning - is overboarded before it ever started.

The Product Owner Role

What concerns me in regards to the Product Owner role: it's so horribly diluted by many organizations that sometimes, practitioners ask me "What's the meaning of my work, and what should I do in order to my job well?"

There's so much garbage out there on the Internet regarding the Product Owner Role that it's very difficult for someone without significant experience to discern what's a proper definition that would help both companies define proper job descriptions, and provide guidance to PO practitioners how to improve. So - let me give you my perspective.

Great Product Ownership

I would classify great Product Ownership into four key domains:

While one of the core responsibilities of the Product Owner is the Product Backlog, it should be nothing more than the expression of the Product Owner's intent. And this intent should be defined by acting on these four domains.

Product Leadership

The Product Owner should be providing vision and clarity to the team, the product's stakeholders, customers and users alike.

Product Vision

Who is better than the Product Owner at understanding what the product is, which problem it solves, why it's needed and where it's going? Great Product Owners build this vision, own it and inspire others to follow them in their pursuit of making it happen.

This vision then needs to be made specific by elaborating long-term, mid-term and short-term objectives - a guiding visionary goal, an actionable product goal and the immediate sprint goal.

Clarity of Purpose

While the Vision is often a bit lofty, developers need substantial clarity on "what happens now, what happens next?" - and customers will want to know "what's in it - for me?" The Product Owner must be crystal clear on where the product currently is, and where it's going next. They must be able to clearly articulate what the next steps are - and what the next steps are not. They need to be able to state at any given point in time what the highest priority is, and why that is so.

The Product Backlog is then the place where the PO maintains and communicates the order of upcoming objectives and content.

Communication

The Product Owner must communicate their product with both internal and external stakeholders. Life is never easy, so they must rally supporters, build rapport with sponsors, and resolve the inevitable conflicts amongst the various groups of interest.

Networking

The product can only be as successful as the support it receives. As such, the Product Owner must build a broad network of supporters, and continuously maintain and grow their influence in their organization - and for the product's market. Keeping a close eye on stakeholder satisfaction and interest, continuously re-kindling the fire of attention drawn to the product is essential in sustaining and fostering the product.

Diplomacy

As soon as multiple people are involved, there tend to be conflicts of interest. Even if there is only one single stakeholder, that stakeholder has choices to make, and may need to resolve between conflicting priorities themselves.

In peace times, the Product Owner builds common ground with stakeholders, so that they are more likely to speak positively of the product.

In times of crisis, the Product Owner understands the sources of conflict, ebbs the waves, reconciles differences, brings people together to work out positive solutions, and mends wounds.

Insight

The Product Owner is the go-to source for both the team and the product's stakeholders when they want to know something about the product's purpose or intent. The Product Owner has both factual knowledge and inspiring stories to share.

Product Knowledge

Caution - the Product Owner isn't a personified Product Instruction Manual, and they don't need to be. Much rather, they should be the people to be able to explain why the product currently is the way it is, and why it's going to be the way it's going to be. They must be able to fully understand the product's capabilities and purpose - and they must be able to convey why these are good choices. 

From a more negative take, the Product Owner must understand the weaknesses of the current product and have ideas how to leverage or compensate these.

And for all of this, the Product Owner should have the domain expertise, market information and hard data to back up their statements.

Storytelling

"Facts tell, stories sell." - the Product Owner's role is to sell the product, both to the team, and to the customers. They should be able to tell a relatable, realistic story of what users want to and/or are doing with the product, what their current pains are, and what their future benefits will be.

"Speaking to pain and pleasure" is the game - touch hearts and minds alike. The Product Owner should be NEAR their users, and bring developers NEAR as well.

Business Acument

The Product Owner's primary responsibility is to maximize the value of the product, by prioritizing the highest value first, and by making economically sensible choices both in terms of obtaining funding and spending.

Value Decisions

There are three key value decisions a Product Owner faces every day:

1. What is our value proposal - and what isn't?
2. What value will we deliver now, and what later?
3. What is not part of our value proposal, and will therefore not be delivered at all?

The question oftentimes isn't whether the customer needs something, but whether they need it so urgently that other things have to be deferred or be ditched.

When anyone, customer or developer alike, asks the Product Owner what is on the agenda today, this week, or this month - the Product Owner must be able to answer in a way that the underlying value statements are clear to all.

Economics

With infinite money and infinite time, you could build everything - but since we don't have that luxury, the Product Owner must make investment decisions - what is a positive business case, what is a negative business case, what can we afford to do - and what can we afford to not do?

The Product Owner should be able to understand the economical impact of any choices they make: More people can do more work, but burn the budget faster. Every feature has an opportunity cost - all other features that get deferred because of it. Fines could be cheaper than implementations, so not everything "mandatory" must be done. These are just a few.

There is often no straightforward answer to "What should we spend our money on this month?" - and considering all of the trade-offs from every potential economic angle before bringing product related decisions to the team or towards stakeholders is quite a complex endeavour.

Economic decisions need to then be transported transparently towards the relevant organizational stakeholders - to team members, who may not understand where priorities come from, to customers who may not understand why they don't get their request served - to managers, who may not understand why yesterday's plan is already invalid.

Given all of these Product Owner responsibilities above, it should be quite clear that the Product Owner must focus and has little time to take care of things that are ...

---

Not the Product Owner's concern

Three domains are often seen as expectations on the Product Owner, which are actually a distraction from their responsibilities, and putting them onto the PO's shoulders actually steals the time they need in order to do the things that make them a good Product Owner:

Project Management

The Product Owner is not responsible for creating a project plan, tracking its progress or reporting status.

Let's briefly describe how this is supposed to happen:

Planning is a collaborative whole-team exercise, and while the Product Owner participates and provides context, a goal and a sorted backlog as input, they are merely contributing as the team creates their plan.

Developers are autonomous in their work, and the Product Owner should rely on being requested for feedback whenever there's visible progress or any impediments hinder the planned outcomes. If the team can't bear the responsibility of their autonomy properly, that would be a problem for the Scrum Master to tackle. The PO should entirely keep out of the work.

Since Sprint Reviews are the perfect opportunity to inspect and adapt both outcomes and progress, no status reporting should be required. A "gemba mindset" would indicate that if stakeholders are concerned about progress, they need to attend the Reviews, and should not rely on hearsay, that is, report documents. 

Team Organization

The Product Owner is not reponsible for how the team works, when they have meetings or who does what.

When Scrum is desired as a way of working, the team should have a Scrum Master. The worst thing a Product Owner can do with their time is bother with introducing, maintaining or optimizing Scrum - they should be able to rely on having proper Scrum in place.

Team events, such as Plannings or Reviews, help the team do their work, and as such, should be organized by the developers themselves, because only they know when and how they need these. The Scrum Master can support, and the Product Owner should attend - but the PO shouldn't be bothered with setting these up, and most definitely shouldn't run the entire show.

If anyone assigns tasks on a Scrum team, it's the team members self-organizing to do this. Having the Product Owner (or Scrum Master) do this job is an antipattern that will hurt the team's performance. The Product Owner should not even need to know who does what, or when.

Development Work

The Product Owner develops the product's position, not a technical solution. They have a team of experts to do this, and these experts (should) know better than the PO how to do this. That means the PO should be able to keep entirely out of design, implementation and testing.

Product Owners actively designing solutions often fall into the "premature optimization" trap, resulting in poor solutions. The best approach is to have the Product Owner collaborate with developers as needed to get sufficient clarity on how developers would proceed, but to focus fully on the "What" and keep entirely out of the "How."

When Product Owners have time for implementation, the product is most likely going to fail: while they're paying attention to the development, they aren't focusing on what's happening to the product and its customers out in the market.

Product Owners have a team of professionals around them who are supposed to deliver a high quality "Done" Increment. If their team has no quality assurance, the solution is to bring testers in, not to delegate testing to the Product Owner.

Strengthen your Daily Events

It doesn't matter whether you use Scrum or Kanban, on a team or program level - Dailies are (or: should be) always part of the package.

In general, it's a good idea to have a fixed slot on the calendar where everyone quickly comes together to keep each other synced. Still, the amount of Dailies can get overwhelming. And tedious, And boring. So what? Here's a suggestion for Dailies that doesn't rely on Scrum's standard "Three Questions":

Brief Information

Dailies are not the time for discussion.  They're for brief information exchange.
Be as concise as possible, provide only relevant information.
If there is something to discuss, focus on what it is, and keep the content discussion for later. Meet after with the people who find value in the conversation itself, so that those who aren't involved are free to do something that matters to them.

Don't mention Business as Usual

Nobody cares that you were "busy" or "working on", because everyone is!
And as long as you're following the agreed plan, that's not news, either.

Should you mention that you have finished one work item, and started another?
If you're using visual indicators of progress and your board is up to date, everyone can see what you're working on. And as long as that's doing just fine - that should suffice.

Cover the four areas

Instead of focusing on activity, try refocusing on things that were not agreed beforehand:

Changes

Did anything "outside-in" happen that makes further pursuit of the current plan suboptimal?
Did you have any learnings that make a different way forward better
Do you need to change the work, or the goals?

Exceptions

Did something unusual occur, for instance: does something take unusually long, are you running out of work, do you need unplanned support? Are there any execution signals that imply there could be an issue somewhere?

Whatever comes up that may need further investigation or wasn't part of your initial assumptions should be mentioned, because it will distract from your original plan.

Problems

Does something block your pursuit of your current goal, be it technical, organizational or procedural.

Which work item is blocked, and what is the impact of the blockage?

I like to prepare red stickies and just plaster them across the blocked item(s), so that everyone is aware that this item doesn't make progress.

Solutions

The opposite of problems - what is now unblocked, and can proceed as normal again?

Don't get into any form of detail how exactly the problem was addressed, unless multiple items were blocked and you need to be clear how far the unblocking reaches.

Be prepared!

Many Dailies are entirely "ad hoc", people just show up, and mention whatever is on their head.

Instead, try to be prepared for the Daily: do you have any BICEPS to share, and what's the best way to get the message across?

But ... I have nothing!

Yes, that's great. It means that you don't need to communicate anything in the Daily, because everything is on track.

And what if we all have nothing?

Then - cancel the meeting and continue whatever you were on to. You have more important things to do than interrupt your work to communicate trivialities.

And the social aspect?

If you want to use the Daily as a water cooler event, to decompress or whatever - you can do that. With the people who are interested. That should be part of the regular work, and not of a Daily, which is a cyclical Inspect+Adapt event to help you maximize your odds of succeeding.

Should we even have a Daily then?

That depends. In another article, I discussed that closely collaborating teams may not need a Daily. For all other teams, it's actually good if you don't need Dailies, yet still keep the fixed time slot just in case. The mechanism could change from routine daily to "on-demand" daily.

You could measure how often you need to have Dailies, which becomes a metric of how well you can predict your next steps, then use that to have a discussion of whether that's appropriate to your team situation or not.

10 Bad reasons to choose Kanban over Scrum

"We're using Kanban instead of Scrum" - a common sentence, Especially since I do SAFe consulting, I hear this one quite frequently. Most reasons provided for this are anywhere between highly and extremely doubtful, and in many cases reveal ignorance both of Kanban and Scrum alike.

So here are my top 10 bad reasons for using Kanban instead of Scrum:

#1 - Our Consultant told us so

There's so much wrong with this sentence that it can't be fit into a single sentence.
First and foremost, if your consultant - after some short observations - knows your process better than you do, then you should seriously question what you're doing.
Also, a team should strive to be autonomous in decision making, and if your best reason for a decision is because someone else told you so, then you have absolutely no valid reason: you haven't understood what is best for your own good!

#2 - We had to choose

"Scrum or Kanban" is a false dichotomy. It's like saying, "Do you want a beverage or lunch?" - why not combine?
You can easily and very well combine Scrum with Kanban, as they address different problem domains. Whereas Scrum's primary concern is the nature of teamwork, Kanban focuses mainly on the flow of work. Especially Scrum.org has been investing significant effort in recent years to put together a "Professional Scrum with Kanban" curriculum which makes exactly this point.

#3 - 1 month is too short

A common argument I hear is that "we can't get anything Done in 4 weeks." 

Sorry to say, if you're not getting anything Done in 4 weeks, chances are you're not doing Kanban either. Kanban is flow optimization, and if you sit back content with a cycle time of more than 30 days when other development professionals can easily do 1 week (or less), you're just being lazy. 

While some organizations are indeed so impedited that everything is moving slowly, working relentlessly to make the problems visible and finding creative solutions to make progress is essential to succeed in the long term.

#4 - Our work is too complex

"We do really complex stuff here, much more complex than anyone else!" - Every team which has ever mentioned this argument to me was applying a "special pleading" fallacy, usually oblivious of what other problem domains look like. 

I will admit that Logistics is complex. As is social media, telco, fintech and science. Scrum is specifically made for complex problem solving, so that's simply not a valid reason.

#5 - Our stories are too big

This argument translates to: "We set up a board and put a sticky on that won't be moving for a month and call this Kanban," Well, I hate to break the news: it isn't. Kanban is about managing the flow of work, and a Kanban board where nothing is moving hides transparency and makes optimization impossible.

I remember working with a corporation where team members adamantly insisted that stories estimated to take 4-6 months were already atomic and impossible to split any further. We took a few items from their backlog into a workshop and a 6-month user story was decomposed into almost 70 workable, individual slices of value. The biggest could be delivered in a few days, some within hours. Unsurprisingly, the entire package of all relevant items estimated to less than one month!

#6 - Requirements from all sides

If this is your reason for not using Scrum, you're defaulting! One of the main reasons for having a Product Owner in Scrum is to solve the problem that everyone thinks their specific problem is Priority 1. Where a requirement comes from doesn't matter - there's always one thing that is the best thing to do right now. Even in Kanban, an understanding of what is the most important thing is extremely helpful in order to "stop starting, start finishing". 

#7 - Maintenance is unplannable

Teams which operate on a live system oftentimes get exposed to unplanned work - bug fixes, support tickets, maintenance and whatever. My first question here is: "Why is maintenance so high?" Could taking time off the busywork treadmill help fix systemic issues reduce the amount of maintenance? I have seen such teams who purposely shifted towards Scrum and taking just a fraction of their capacity to address fundamental issues - they benefitted greatly!

#8 - Requirements change too fast

To me, this begs the question: "Are you getting things finished before the requirements change?"

Usually teams answer, "No", and then I seriously question why you're doing what you're doing. Scrum might help you sort out what's worth taking into account, trashing all whimsical ideas that are forgotten faster than they were proposed.
Just as an added side note, Scrum's sprint plan isn't immutable: There is nothing in Scrum which prevents you from integrating new information and opportunities as they arise.

#9 - Too many meetings

Scrum's events all serve a purpose of inspecting and adapting - not losing focus or track in a changing environment. There is no reason for Scrum events to fill their entire timebox and there's no need to do them in a specific way.
As long as you know why you're doing what, get frequent user feedback, improve your process and outcomes and keep the team synchronized, you're quite compatible with Scrum. If you are missing out on any of these items, your problem isn't the amount of meetings!

#10 - We don't do User Stories

I have no idea where the idea originates that Scrum teams must use User Stories, estimate in Story Points, create Burndown charts or whatnotever. When your reason against Scrum is a practice such as these, the short answer is that Scrum is neutral to practice. Scrum is merely mentioning "backlog items". These can be stories, requirements, bugs, defects, ideas or whatever else floats your boat.
Some teams find value in the User Story approach, others don't. Some estimate in Story Points, others in ideal days, yet others in amount of backlog items. All of these are valid from a Scrum perspective, although some may be more helpful than others.

Wrapping up

The discussion "Scrum or Kanban (or both)" is quite valuable for teams to determine how they want to organize themselves. Unfortunately, the discussion is often not factual and highly biased. It is often led with huge understanding deficits both regarding Kanban and Scrum.

There are a lot more bad reasons for preferring Kanban over Scrum than mentioned in this article, and there are also some good reasons for doing so. When your team mentions any of the items in this post, it's good to be suspicious and ask probing questions. Most likely you will uncover that Scrum is just a pretext and there is something else going on.

Expose the root cause and deal with it, because otherwise, critical problems might linger unaddressed.

When not to scale Scrum

Typically the first question I hear after a company decided that Scrum may be the way to go forward in their IT organization, the next question I hear: "But how do we scale it?"

As mentioned in a previous post, there are reasons why you shouldn't even try to scale. Aside from that, you may simply not be ready to scale.

Before you attempt to scale your Scrum, maybe you want to go through this non-exhaustive check list. It only exists to give you an idea of what to improve on before plunging into Scale.
Maybe you want to answer these on a scale of "Definitely not (1), Unlikely (2), Somehow (3), Usually (4), Definitely yes (5)" - then decide areas for improvement based on feasibility and value.

So, here is your checklist:

1 - Delivery

• We are able to deploy the last merge to Master to a productive system within less than 15 minutes.
• We can release partial work at any time, because we use Feature Toggles to disable unfinished features.
• There is no more work to do when we call a story "Done".

2 - Teams

• We have stable teams that have a routine of working together.
• Our teams autonomously get stories "Done". They do not depend on anything from anyone outside the team. This includes activities (such as testing or deployment) as well as sign off.
• Our teams have what they need to succeed. They do not require permission to use applicable tools to get their job done.

3 - Scrum Masters

• Scrum discipline within the team works without having the Scrum masters say or do anything.
• Scrum Masters act as mentors and supporters, not as managers.
• Scrum Masters are seasoned experts in Scrum. They have seen Scrum in multiple contexts and are aware of the difference between avoiding pain and healing the pain. They avoid going the easy, wrong way.

4 - Product Owners

• The "someone who calls the shots" is the Product Owner. Not other stakeholders.
• The PO is not a business analyst detailing features to become implementable, this can safely be left in the domain of the team.
• Product decisions are based on Net Present Value, Opportunity Cost, Customer Retention, Market Share etc. - as opposed to politics.

5 - Outside Organization

• Company priorities and objectives are aligned across all areas, including IT as well as Marketing, sales, finance. Conflict of interests is resolved on top management level.
• External stakeholders fully understand their responsibility in enabling successful delivery.
• Managers enable the team and do not require non-value adding activity, such as reports

6 - Continuous Improvement

• We know our 3 top pressing impediments
• The most pressing impediment is actively being resolved
• Minor changes which help increase productivity are readily implemented without further mention.

7 - Technical Debt

• It is widely accepted that technical debt must be controlled
• We measure and are aware of our technical debt
• We don't release any code with significant technical debt

 Summary

The model of Shu-Ha-Ri applies to Scaling more than anything.

An organization in the SHU stage of Scrum multiplies their problems, not their solutions, at scale. When you can't frequently and reliably deliver value with 1 team, you won't be doing that with 5 or more teams, either!
Successful scaling requires coaching by RI stage Scrum experts and an organization that is at least on the HA level.

As long as you don't have a working implementation of Scrum within individual teams, don't even think about scaling!

The preconditions of Scrum

Every team can use Scrum - true or false?
The answer isn't just as simple. In this article, I will spell out some of the preconditions required to be successful as a Scrum team.

Let's make this article a little more fun by adding a quiz onto each section.
Each section has a brief explanation and number of questions. Rate your organization on a scale between 0 (really bad) and 10 (extraordinary). Let's check the results later.

Psychological safety

The Scrum values aren't optional. Commitment, courage, focus, openness and respect are essential in three different ways: Producing results, addressing problems and improving things which matter.

The team must operate in an environment where:

• Commitments are honored rather than weaponized
• Courage is a virtue rather than a stigma
• Focus is appreciated rather than demeaned
• Openness is reciprocated rather than exploited
• Respect is offered rather than demanded

When these preconditions aren't met, the team can't develop the necessary level of trust. Scrum teams are most effective when they can eliminate all kinds of CYA behaviours and fully dedicate themselves to delivery of value.

The Scrum values are a two-way street. If you see any of these signs, Scrum is up for a rough start:

• When the surrounding organization can't commit to let people reach their goal before changing direction again
• When people courageously taking the first step find themselves standing alone against adversity
• When management can't define where the focus should be
• When managers filter communication and openness is considered a one-way street
• When the hierarchy makes respect a directed process

Questions:

1. How well can the organization grant consistency?
2. How positively does the organization deal with unpopular ideas?
3. How likely do things get done before something else becomes important?
4. How transparent does management behave and communicate?
5. How directed would a respect map (who respects whom) of the organization look?

Aptitude

Scrum can be used in many contexts, hence the Scrum Guide isn't specific on any kind of skill required by the Development team. What the Scrum Guide is specific about, though, is that "The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of Done product"

The team absolutely must consist of people who possess the aptitude to get something to "Done" rather than to a certain stage where problems within the product persist.

On a technical level, Scrum teams need a foundation of:

• Domain expertise: Delivering a great product means you need to understand your domain: You're not going to build a great web platform with people who don't know what the Internet is.
• Technical expertise: While learning is possible, the team must be sufficiently firm with the tools of their trade to get to Done in a short timespan.
• Quality expertise: The team must have ways of knowing what quality is and also the necessary means to achieve sustainable high quality.

Questions:

1. How well do team members understand the product?
2. How high would you rate the technical skills of developers in your organization?
3. How effectively do you deal with quality issues?

Ways and means

No organization is perfect, and if we had already achieved perfection, why would we bother with Scrum? At a minimum, the organization must have a willingness to let the Scrum team succeed. When severe impediments become visible, they need to be resolved in a short period of time, otherwise Sprint Goals will become un-achievable, leading Scrum itself ad absurdum.

Successful Scrum team need strong support from the organization in:

• Processes: Many organizations have accumulated so much ballast in their process that getting even simple things done becomes impossible. There's no change without change. If processes can't change, you will fail with or without Scrum.
• Tools: One agile principle is "maximizing the amount of Work not Done": Surely, we can chisel away a mountain with a fork and spoon, but when the team needs dynamite to get stuff Done, Give them Dynamite!
• Information: There's nothing worse than developing the wrong product because important facts were missing. Provide the team with whatever they need to know to succeed.
• Learning: Learning is always a natural part of development. This includes both individual and organizational learning.

Questions:

1. How easily can the organization make unbeauraucratic changes?
2. How fast can a person obtain new tools within the organization?
3. How transparent are communication streams within the organization?
4. How good is your track record as a learning organization?

Team purpose

Scrum teams are intended to deliver a valuable product rather than just work off tasks. The team needs to know what they do why, and be able to identify with this.

Successful Scrum teams need:

• Meaningful purpose: Scrum teams should form around a specific purpose, and that purpose should be sufficiently important to warrant dedicating a team to it.
• Clarity of purpose: The team should be able to answer how their work contributes to something greater than getting a task moved into the "Done" column.
• Constancy of purpose: The team needs to be working towards short-term goals ("Sprint Goals") which align with mid-term goals ("Milestones") which align with strategic goals ("Product Vision").

Questions:

1. How important is the reason for having a Scrum team to begin with?
2. How well can you state the intended outcome of the team's work?
3. How closely aligned is the team with a relevant strategy?
4. How clearly can you draw the roadmap upon which the team is operating?

Mindset

Scrum teams deliver in an incremental, iterative way. Increments allow us to backtrack to anchored successes whereas iterations allow us to maximize feedback learning. Working with increments and iterations can be challenging for organizations not used to this approach.

Successful Scrum teams need to:

• Be user-centric: Technology is fascinating, but not to everyone. The team needs to get out of the technical domain and learn to understand users, their needs and problems.
• Get meaningful feedback: Stakeholders and/or users should offer important feedback to the team frequently, promptly and in ways which help do things better.
• Deliver small increments: The more work is done between feedback loops, the more likely the cost of change will be too high to undo and do the right thing instead.
• Focus on value: The amount of work is infinite - it's up to us to decide how much we do. Therefore, we should focus on valuable things instead of just getting work done.

Questions:

1. How well can technical people in your organization understand the users?
2. How important is user feedback for technical teams?
3. How much time passes between idea until a first version is visible?
4. How strongly is value of the outcome emphasized in doing work?

Quiz score

Your score should be anywhere between 0 and 200. You may get a more accurate representation by asking others, averaging the score and having conversations about outliers.

0-20

Don't expect much except a bloody nose by starting Scrum. The problems you will face have nothing to do with Scrum. They are caused by the organization itself! 

Please do some groundwork before getting started. You may want to reconsider how and where your organization is stepping on its own feet. In all likelihood, you can't do this by yourself, otherwise you would have scored better. 

Simply training some Scrum Masters won't cut the cake. We're talking serious Organizational Change Management.

21-50

Your Scrum team will face serious challenges and even a very good and seasoned Scrum Master won't be enough to deal with the impediments the team will face. Don't count on the Scrum team to succeed. 

Doing more groundwork in terms of creating a proper culture and a bit more flexibility will go a long way before throwing a Scrum team into the ring. Probably the most sensible thing you can do is get an experienced agile coach to work with managers and see how the score improves. 

51-100

You're in the range of most companies who are still unfamiliar with agile processes. Challenges are what makes life interesting. Be prepared for innumerable smaller and bigger frustrations which need to be overcome, and work strongly on setting the right tracks.

Always be aware that the Scrum team is influenced by the surrounding organization as well, and that the team's success depends on both strengthening positive and dampening negative external influences. 

101-140
There is a solid basis for teams to build upon on when starting Scrum. Many things can still be improved, but since Kaizen is a neverending journey, that's nothing to worry about. With a good Scrum Master, an astute Product Owner and a motivated team, the rest can be worked out over time. Beware the Unknown, however!

141-180

It's like you've already prepared the car and the Scrum team just needs to get in and win the race. 

Get the right people and get going!

181-200

Are you sure you accurately see your organization? 

Just get started and see what happens!

Scrum team - interactions with investors

There's quite a bit of talk about the Scrum Master "protecting the team from outside influence" and many developers consider any meddling with how or what they do within the Sprint to be such undue influence which needs to be stopped. This is often myopic. Here is what you need to see:

What Scrum is all about

If I had to describe Scrum in one sentence, it would be "Done in less than a month.", and if I had only three words, it would be "Getting things Done." Being a bit more voluminous on words, "The team gets a clear goal which they set out to achieve in one Sprint. Their success is measured by how well they meet this goal."

The limits of team autonomy

A Scrum team does not have complete and utter freedom to do whatever they please: their freedom is limited to doing whatever is necessary to meet the Definition of Done on the agreed Goal, and their activity needs to focus first and foremost on that.
Encountered impediments need to be made transparent fast and dealt with in the most effective manner.

The Scrum team does not have the freedom to squander funds, gold-plate features or mess with stakeholders.

Scrum and Trust

Trust is the development team's capital. It's what they must build upon.

The organization and the Product Owner place trust in the team to deliver the agreed outcomes. By delivering a useful increment in the Review, this trust grows.
When agreed outcomes aren't delivered, the trust in the team diminishes rapidly, and with that trust, the team's right to autonomy decreases proportionally.

Scrum and investors

Let's be honest. Investors don't care about Scrum. They don't care about how your team works, what you do all day - or even how long you're at work. They care only about one thing: "Am I getting my money's worth?" With initial funding, the investor provides a level of trust in advance. You better use it wisely!

Why investors like Scrum

Still, investors often prefer Scrum organizations over Waterfall organizations, because the very nature of Scrum provides frequent control points at a pace at least the same speed the investor would want to see progress. As long as a Scrum team is able to create growing Product Increments at a rate at least acceptable to the investor, there's a high chance that the investment is wisely spent.
Likewise, when a Scrum team fails to deliver what the investor considers a good return on investment, the investor can quickly pull the plug.

The double-edged sword of investment

Every investment is a risk. Nobody likes to lose their hard-earned money, but when investing into product development, the risk of total loss is always there. As mentioned initially, investors neither care about Scrum, the team nor their work, only about ROI.
Investors will do anything to protect their investment, that is - maximize ROI and minimize losses. If a product looks irredeemable, the investor will cut funding.

Scrum, a non-argument

When a product looks promising, but the team doesn't deliver as expected, the investor might have suggestions about changing the way the product is being produced: That's their right, bcause it's their money.
The investor might simply suggest to stop using Scrum and try something else. The "But that's not Scrum" line won't make an investor flinch, because they're not paying for Scrum, they're investing for ROI.
Likewise, they might not care what the Scrum Master considers their role and responsibility, they will reduce a discussion with the Scrum Master to one question: "What have you done to ensure we're getting our ROI?" There won't be a long discussion whether it's appropriate for outsiders to tell the team how to work, because when investors are unhappy, there won't be a team anymore to do any work!

Dealing with investors

Depending on how attached/detached they are to the product, investors tend to ignore the team and focus solely on economic outcomes: market impact, bottom line revenue. Everything else is just a means to these ends.
They tend to be easy-going on high performance teams and don't even want to think about what teams do all day, after all, that's their job and not the investor's business.
When you see investors getting dissettled with the team's work, your question shouldn't be whether they understand Scrum properly - but whether your team has understood Scrum properly!

Scrum Master interactions with investors

Investors obviously want to maximize ROI and might become pushy. Good may not be good enough. This might create a kind of adversary relationship between developers and investors. In such a situation, the Scrum Master may be invaluable to clear up the situation.

Protecting the team

As mentioned above, when investors get unhappy, they might cut funding - and that's end of story for the team. So, when the Scrum Master is working with investors, diplomacy is your friend, and "protecting the team" won't mean taking out the big guns and letting investors know what they do wrong. It first and foremost means finding out how investors can be brought to see the value of the team's work.

Transparency over Sheltering

If the team feels that investors would exercise undue influence on the team, then it is fully their responsibility to create a sufficient level of transparency to provide the necessary information that intervention is unneeded.  When they worry that leaving things untouched means wasting a lot of precious money, they might intervene - otherwise, they won't. It's not like investors have too much time on their hands, anyways.

Creating confidence

The Scrum Master won't need to coach investors on Scrum - if anything, the Scrum Master should convey that they themselves are representing what creates good Scrum: Getting things Done, being  trustworthy and transparent, consequently and effectively dealing with impediments - and valuing product increments over being busy.

Product Owner interactions with investors

The Product Owner is the sole owner of the Product Vision and the Product Backlog. At the same time investors provide the necessary funding to make this vision reality - so it's appropriate to communicate strongly in both directions with investors. "He who has the money chooses which tune is played".

Sharing the vision

The Product Owner must constantly remind stakeholders both inside and outside the organization about the current vision as this can both change and be forgotten. As an investor, when the vision moves off my priority list, I might decide to take my money elsewhere.

Sharing progress

Investors may or may not show up for Reviews. Still, they have important investment milestones and need to be updated to make decisions for further funding. Product progress is important before launch, but as soon as you launched, more important are metrics such as customer base, campaign progress, market acceptance etc.
These may look like distractions from delivering on the product vision - but they aren't. They are reality checks.
The terms "un-agile" or "not Scrum" aren't suitable for any activity related to progress sharing. Give the investors what they need, how they need it: Being agile is about having sufficient flexibility to meet u to circumstance.

Accepting input

Investors might suggest tweaks to the product, the product vision and even changes to the Product Backlog or ways of working. Even when these suggestions look like overstepping the autonomy of the PO and/or team, the PO is well advised to take them seriously, because such input wouldn't be provided without the intention of maximizing product success in order to secure continued funding.

Again, terms like "not Agile" are unsuitable in this context, because investors seriously don't give a hoot about what you consider "Agile" or not - they care about securing their investment.
And what's wrong with "Waterfall-ish" or "Command and Control" actions if the outcome is increased success?

Summary

tl;dr: When dealing with investors, humility is a great virtue. Lose your jargon, drop your beliefs about "proper Scrum" or what "proper Agile" is, forget how the team likes to work and focus on the important things: Creating tangible outcomes, securing investments and producing revenue. Anything the team does which isn't aimed these things is completely irrelevant for investors.

Finding the right Product Owner

An important question to answer, especially when launching your first Scrum team: "Should we choose of our own employees as Product Owner, and if so: whom - or should we find a contractor?" The answer is a clear: "It depends". And here's why:

Value Optimization

The most important function of the Product Owner is to optimize the value of the delivered product. Everything else is subject to that. Especially the first couple of Sprints should have a visible impact and give stakeholders the impression that the team is doing things which matter.

And here is the first splitting point:
A member of the existing staff is already familiar with the business, knows the important stakeholders and understands the work done by the organization within the product domain so far. This put them at a real advantage over a newly hired contractor.
A long-term employee might approach Product Ownership with a "Yeah, I know this" mindset, whereas a contracted PO will actively seek out what they don't know - and thereby explore important areas a current member of the staff could have skipped.

Value Organization

To build the best possible product, the backlog must be in shape. The backlog is an itemized and prioritized list of what you know. Split, slice and sort, extract value and prioritize by need. A good analyst should be familiar with most of these activities, so the PO should be able to get some support with that as needed without even being an expert in the product domain.

The second splitting point:
People who are suitable for the PO role can separate essentials from nice-to-have and need to be pretty harsh to descope even things they themselves might consider necessary. Employees of an organization who for some reason need to play favorites with specific stakeholders in disfavor of the product aren't a good fit.
Another plus for a contractor: They might not have to please one specific audience and can descope anything which has only career-political, but no business value. A note of caution though: This becomes dangerous when their paycheck hinges on a single stakeholder!

Taking Risks

Many organizations are inherently risk-averse, and so are their staff. Especially conservative enterprises where employees have learned over the years to avoid taking risks at all costs will be challenged to suddenly find people within their organization who are happy to go completely new ways, work with uncertainty and prioritize things where success or failure can only be known after the fact.
A PO who shies away from taking risks will be highly unlikely to build anything exciting and most likely will end up building something as close as possible to something which already exists.

This is the third splitting point:
The PO role isn't for perfectionists. The proverb "Perfect is the enemy of the good" comes in at this point. Most highly qualified people in organizations default on the PO role because they try to build a product based on what they know and shy away from building a product based on what they don't know.
A contractor who knows very well that they can't know everything may be much more open to explore feasible options others might never consider with their organizational shutters.

Role Assignment

Rather than start with the question "Who should be PO", we need to look at the activities which are required to be effective as a PO, then determine how we plan to make them happen. While skills can be acquired, the challenge is more in un-learning the things one has always done than it is in learning that which is now required.

By picking a member of your existing staff, there's a risk that the PO role isn't filled adequately.
Here are a few common choices for internal PO:

• Analyst as PO
  Analysts are great at supporting a PO, yet they tend to struggle with independent splitting and value-ordering. Especially if your Scrum Master is also inexperienced, such a setup has massive challenges to begin with. Try to avoid this scenario and let the analysts do what they do best: analyze the prioritized items for the team.
• Project Manager as PO
  This scenario is extremely dangerous, as PM and PO have completely different job descriptions. A PM will have to un-learn so many things in order to be effective as a PO that a new hire is probably the better fit. PM skills are still valuable, although a PM is better suited as a team member than as PO.
• Line Manager as PO
  An almost surefire road to disaster, as the Line Manager's responsibility is oriented in a different direction. This will most likely end up with either line management or PO duties being dangerously neglected. Likewise, line managers often tend to be challenged at creating, maintaining and communicating a Product Vision.
• Marketing/Sales as PO
  In some cases, this works like a charm. The danger is that Marketing mioght have very little contact with real users, risking to build the wrong thing - and Sales might be too focused on delivery and neglects strategy. Both are important stakeholders with valuable perspectives, yet they may not have what it takes to be a PO.
• Senior Manager as PO
  The worst part about the Senior Manager being PO is that they often don't have enough time to spend with stakeholders and team members to ensure the right product is being built and that the most valuable things are being done. A better setup is that the Senior Manager backs and supports a PO who is fully focused on Product Ownership.
• PO as a title
  The worst choice organizations often make is assign the PO role via "appeasement politics", i.e. give this important role to someone who would otherwise begrudge the transition to Scrum. Just don't. Instead, find out what their gripe is and coach them to find their place in the new organization.

Then - who's suitable to be a PO? 

A PO is a PO, and while any member of existing staff can learn Product Ownership, they weren't born as PO. The role of the PO must be learned, and this learning process takes time. A lot of failure learning is involved, so the main question isn't "Whom should we choose as PO?" than a series of questions about the goal of Scrum in context:

1. How fast do we need to produce something?
2. How is our organization prepare to identify value?
3. How do we know we build the most valuable thing?
4. How do we know we are building the right thing?
5. What happens when we built the wrong thing?
6. Which challenges will the product itself face?

After discussing the organizational constraints, we need to discuss the context of the Product Owner:

1. Which support can we give to the PO to learn their role?
2. Which support can we give to the PO to be effective?
3. Can our PO be politically neutral, i.e. unbiased from departmental priorities?

Finally, I would shortlist a list of candidates who might be suitable to take on the role:

1. How close are they to the required skills of a successful PO?
2. Can they formulate and communicate a Product Vision?
3. Do they have a standing of high respect within the organization?
4. Do they have an entrepreneureal mindset?
5. Will they act in the best interests of the product?
6. Do they understand business?
7. Are we willing to relieve them of other responsibilites?

While there's no "perfect PO", there are some people who are more or less suitable to fill the role. Any available person who comes sufficiently close to a good fit should be considered.

Assigning the Product Owner

Based on all the above, consider the following question:

How likely can we get an internal PO prepared for the role? 

If there's a decent likelihood, find one and give them the necessary support to succeed.

This "necessary support" will require a set of decisions and changes within the organization as well as training and coaching. It might require contracting an experienced PO to "teach the ropes" and potentially onboarding a PO coach to keep the ship afloat during the turmoils which will come.

If odds look dim, you might prefer contracting a PO.

While they are around, you should be working on resolving the organizational impediments which necessitate an external expert in this position. As soon as possible, find a staff member who can fill the role and let them learn on the job by working with the contracted PO.

Summary

The key challenges for finding the right PO include:

• Freedom from organizational structures and politics
• Entrepreneurial thinking

Most staff members would have issues with either or both of these challenges, but they're more suitable because they will be more likely to stick around for a major portion of the product's lifetime.

A contracted PO is a workaround for problems that might not be tackled on a short notice. Finding and enabling the right person within an organization to be PO is a major challenge, so a contractor buys time here without solving the issue. 

In the long term, a PO should always be a permanent ember of your organization - although supporting them with a contracted Product Owner Coach might be a great idea to maximize the value of the product they're building.

The Scrum Master role

What's a Scrum Master - what do they do all day?
Many companies seem to have trouble identifying the proper role for the Scrum Master, their job descriptions already hint that they're looking for something other than a Scrum Master, which implies that a successful hire is unlikely going to help the team succeed with Scrum.

What's not a Scrum Master?

A Scrum Master is definitely not a rebranded management role in any form or fashion. They are not available to help managers retain command or control of the Scrum team. Their role is not intended to do any work either on the product or on the process. They also are not a secretary or a kind of errand person for the team.
Also, contrary to popular belief, the Scrum Master is in no way responsible for the delivery - neither in terms of quality, nor quantity.

Even terms like "Evangelist" or "Enforcer" might hint at behaviours a that could cause potentially detrimential behaviour.

A Scrum Master's power, as odd as that sounds, comes from not having any power. By empowering the Scrum Master in any regard, they lose this superpower.

Then what is a Scrum Master?

As hinted in another post, a Scrum Master's responsibility is primarily the people and their interactions - helping the team focus on their goal, deliver effectively and support the resolution of impediments towards higher performance.

Most notably, a Scrum Master would create transparency, visibility and thereby awareness of key impediments more than they would actively resolve them. Why? Everything the Scrum Master does reduces the learning effect of the team or the surrounding organization.
In knowledge work, learning leads to understanding, which then becomes the baseline for performance. Therefore, the main responsibility of the Scrum Master is to make learning happen.

In one sentence, the Scrum Master is a "Learning Maximizer".


To support you, here is a list of traits that you might want to be on the look out either in being or in choosing a Scrum Master:

Not helpful	Helpful
Project Manager	Help management change from moving teams to work towards moving work to teams
Release Manager	Assist Product Owner and Developers in defining and tracking releases
Delivery Manager	Remind the teams of their responsibility to deliver
Process Manager	Reflect on the process
Team Manager	Remind people when they break their Working Agreements
Problem solver	Support the team in solving their problems
Scrum Evangelist	Teach Scrum in and around the team
Meeting Organizer / Moderator	Help the team have effective meetings
Technical / Subject Matter Expert	Expert in regards to Scrum, change management, coaching
Jira Admin	Support the team in discovering and using appropriate tools
Bouncer	Help people realize which interactions aren't helpful
Enforce Scrum	Remind people when they break Scrum
Track team‘s progress	Support the team in making progress transparent
Produce reports	Create transparency
Threaten, manipulate, coerce	Encourage the team to do their best

To wrap it up, here's an illustration of what a Scrum Master does or doesn't:

The Product Owner role

What's a Product Owner - and what do they do?
There are a lot of opinons out there, so let me just throw mine into the ring as well.

What's not a Product Owner?

The Scrum Guide is quite clear that a Product Owner and a Business Analyst are not the same roles. Neither is a requirements engineer or a project manager a Product Owner. A Product Owner is not responsible for "writing user stories". Neither proposing solutions, architecture or design. Nor for tracking developers' progress, the quality of their work or the approach they use in generating results.

Likewise, there's a huge misunderstanding that the PO is a kind of go-between, mediator, between stakeholders and developers. Oddly enough, the Scrum Guide doesn't say any of that.

Indeed, a PO who acts in any way as above is more likely to negatively impact the outcome than to add value.

Then what is a Product Owner?

When taking a close look at the Guide, the Product Owner can delegate almost everything to the Development team. They only need to make sure that transparency on a product level exists, that developers know what is important and why. How they do this - no constraints.

In one sentence, the PO can be called "value maximizer". How do they do that? They learn and understand customer needs, problem statements and expected benefits from having such a need met by solving said problem. To be most effective, it helps if they have an understanding of what their development team is capable of, have a knack on linking the solutions of the team back to the problems that exist and can make clear business-oriented decisions based on cost and ROI.

Like customers own the "problem space", developers own the "solution space". The Product Owner brings these two spaces together by linking them via value and priority. No more, no less. The more the development team can contribute here, the more the Product Owner can focus on exploring further needs that can be met to make the product more valuable.


So here's a short infographic as a summary:

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.

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.

Being a Product Owner

I am a Product Owner. I'm on a mission to create great products.

I don't have a title

Some clients call me "Agile Product Manager", "Agile Project Manager" or even "Agile Architect".
To be honest, I don't give a hoot what you call me. I'm not in it for title games. Titles don't matter.
Those who know me call me "Michael". That's me, and that matters.

I am the product

When I get up in the morning, I think about what the product needs. When I drive to work, I consider the challenges my product faces. While I am at work, I discuss the product with others. My discussions are centered around the product. While I eat, while I walk, while I dream - the product is there. I am the Product - you do something for my product, you make me happy. You mess with my product, you hurt me.

I am narcissistic

I identify with the product. I want the product to be great. I feel with my product. When my product suffers, I suffer. When my product succeeds, I succeed. I don't take criticism on my product lightly. If it's justified, I will do everything I can to improve. If it's unjustified, I will give you a chance to correct your opinion before you get a problem.

I don't accept "requirements"

I dedicate myself to making the product rock. You are allowed to explain to me why you think that the product should offer a certain ability, but you can't make me build it. If you manage to convince me how the product will be more desirable with your idea, I will place it in the backlog. Otherwise, you're short on luck. And no, I don't care for your job title. I care for the merit of your idea.

I don't work for you

I work to build a great product. If you have a need for which I have a vision, and you are willing to fund me to find excellent ways of turning your need into results, we can have a talk. I will dedicate my time, energy and every brain cell to making the product happen in a way that meets your needs and expectations, in terms of the product's content, price tag and its value. We will work together as long as I can bring the product forward and the product brings you forward. When either is no longer the case, we will part ways.

I protect my team

I need my team to make the product rock. I invest my time into instilling the vision into them and I enable them to do what they need to. I respect my team members, because I know they do the best they can. Without them, the product vision would remain a mental blob. When someone messes with my team, they have a problem with me. And I don't care what title or role that someone has.

I don't follow Scrum

Judge me or condemn me if you want for not living up to whatever agile bible you follow. I don't give a hoot, either. I'm not in it for a methodology. I'm in it for building a great product with a great team. I don't follow Scrum - nor anyone or anything else, for that matter. When rules and regulations become impediments to doing what needs to be done in order to succeed, I will stomp over them. As long as Scrum follows me, I'm fine. When it no longer does, it better get out of my way.

I am an extremist

I understand moderation, but I also understand that there will be no change without change. I am the PO because I want to make a difference - and since I can't get everything, I need to deal with extremes. From there, we will explore together how far we can go and what it takes to get there. If I didn't have radical ideas, my product would suck.

I don't insist

I am actually quite easy to convince that I need to reconsider my choices, except that I need evidence: Experiments that prove otherwise, business figures that point in a different direction, systemic causes which make other approaches more favorable. "I don't like it" doesn't cut it, I want hard facts. Solid, reliable information. In fact, as new information becomes available, I constantly reconsider my next steps.