Agility- a matter of survival

Why would we even want to "be agile"? 
Claims of being faster, cheaper, getting more software done are all based on anecdotal evidence and may not be true for an agile organization. 
Here is a different take.


Before we dig into the key questions, let's start with a few statements that I'm not going to back up here for brevity sake.

Digital Disruption

Digitalization means a lot more than just having a corporate website, having IT systems to support your business or even taking advantage of hyperconnectivity to access business information anywhere.
It means that analogous business models are getting disrupted - and if you don't do it, someone else will do it.

There are two types of disruption which can occur:

1. Business disruption: A player invades your market with faster, cheaper and more reliable processes. By the time you caught on, customers have made their move. The good news: You still have a chance to hang on to some of your business if you're fast enough.
2. Market disruption: A player learns about your business model, then creates a service which renders that model obsolete. Since your business is centered around your current market, the business will die with the market. The bad news: Any attempt at returning to former status quo is futile.

Disruption is inevitable. Just to give a few examples:

• Amazon sends retailers packing (pun intended)
• Digital photography threw Polaroids off the market - and the market for digital cameras caved in to smartphones
• The Internet has removed the need for Pneumatic tubes in offices
• Outlook has eliminated office mail delivery
• How many postcards do you still receive in the age of Instagram, Facebook and Twitter?

Your business model is in danger. If you're not the disruptor, you are going to be disrupted - and when you're not up to speed, you have already lost the game.

Being agile is not about fancy stuff IT is doing. It's about remainng relevant on the market. In terms of the Kano Model, agility isn't an Excitement factor: It's a hygiene requirement. You don't win because you're agile. You will lose because you aren't agile enough.

Here are four questions you can answer yourself to see whether you are sufficiently agile:

How effectively do we meet market needs?

Digital organizations cut out every possible manual activity from the value stream and focus on creating scalable business models. A no-touch automated process can serve a billion users at (pretty much) the same cost as it would serve ten users. Likewise, any activity not helpful in meeting the goal of satisfying customers on the market is up for scrutiny: if it can be eliminated, it will be eliminated.
A digital organization would think twice about having non-essential functions as part of their business operations. Any activity which can be outsourced, automated or purchased as a service with a benefit to the core business model, will be.


Questions:

• Do you spend more time meeting business needs or customer needs?
• How closely are you aligned with the needs of your customers?
• Are you improving existing SOP's or are they creating new capability?
• How intertwined are software services with your way of meeting customer demand?
• Which touchpoints between you and the customer could be digital - and how many are?
• Which means are you using to recognize how in touch you are with your customer's needs?

What are we doing to learn about our market?

Digital organizations don't give tasks to IT after others have discovered what is going on. They mine for information and creates business opportunities in the way a journalist hunts for the next story. Sometimes successful, sometimes unsuccessful, but always in an attempt to be the first and best. Agility is but the necessary means of jumping in early and pulling out fast.

Questions:

• Who in your organization understands how the market is doing? 
• When the market shifts, do you realize this early, when the symptoms arise - or too late?
• Do people understand where to look and what for? How do you cover blind spots?
• What role does IT have in generating and analyzing market knowledge?
• How do the information flows in your organization look like?

How do we sense shifts in markets?

Digital organizations create markets, divert existing markets and take the profit out of current business models. As new options for customers arise, old options become unwanted or obsolete. Consumer needs change with digitalization. Can we be the first to offer options to meet the changing needs, are we trying to get a slice of the cake before it's too late - or are watching the ship leave?

Questions:

• Is your market growing, shrinking, stagnating?
• How do you learn about market shifts?
• How do you know that your information about market shifts is reliable?
• How do you decide where to dig in and where to withdraw?
• What are incumbent players in the same market doing?
• What new players have appeared recently, and how are they operating differently?
• In which ways are you actively working to create market shifts?
• How would you shift the market in your favour?

How much does it cost to change direction?

Digital organizations are aware that markets change. They realize that changing direction early, fast and often is the most effective way of meeting customer demand. Instead of investing heavily into retention programs to keep customers bound to a dying business model, they reshape their business model to be what customer want it to be. They constantly run experiments to find new opportunities and cut off lost opportunies as soon as a ship starts sinking.

Questions:

• What happens when your activity is out of sync with real market needs?
• How much time are you spending on things you could simply buy as a service?
• What happens between the discovery of an opportunity until it is captalized?
• Which factors prevent the immediate removal of an unprofitable capability?
• How much opportunity cost do you tolerate because of late change?

Conclusion

None of the above has any specific relationship with "an agile framework" and the questions aren't even specifically linked to IT. Digital organizations are driven by technology and are inherently agile because of low cost of change and fast response times.

Do not confuse means and ends: Agility isn't a tool to get better at doing what you currently do - you can move, evade and explore new threats and opportunities better when you're agile.

Becoming agile is the active, relentless and uncompromising quest for new and better ways of meeting customer needs.

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.

The self-preservation of Corporate systems

Can we fundamentally change a company culture? If so, how can we approach it lest the self-preservation mechanisms snap the system back into its former status quo? Let us examine the joints and levers within a typical corporate system with a causal loop diagram - and what we would need to tackle to make a lasting change.

A stable corporate system

Before we take a look at the slightly scary diagram, let me explain the basic representation model:

Defining the model

Black rectangles represent organizational artifacts and/or structures.
The colors red and blue represent negatives and positives, so respectively:

• A red circle represents a negative system variable of which you probably want to have as little as possible.
• A blue circle represents a negative system variable of which you may want to have as much as possible.
• A red arrow represents a negative causation, which means by adding more of the source, you get more of the target.
• A blue arrow represents a positive causation, which means that adding more of the source means you'll end up with more of the target.

With this in mind, take look at the model:

Example 1: Titles and hierarchies

Why do organizations assign titles and positions? You may find numerous reasons,such as a way represent responsibility, denote boundaries, indicate paycheck size or soffer prestige as a non-monetary reward or incentive.

Regardless of the initial reason for creating a title, the title or position derives meaning from the privilege it provides. Any such privilege indicates that a hierarchy is formed.
For example, you can't have a Ministry of Silly Walks if there's nobody in charge of Silly Walks - so the organization gets divided into those responsible for Silly Walks and those not.

As long as the position and the title exist, the organizational boundary continues to exist, and as long as the organizational unit exists, it needs someone in charge and some executive function to take strategic responsibility.

As the years go by, it becomes impossible to discern whether the Ministry of Silly Walks exists because the company needs it, but since it has a function, it needs to continue to exist - and when someone from that unit leaves, another person is hired to fill the role: The position exists because the hierarchy has a place for it, and the hierarchy has a place for it because it exists.

As more organizational units are added, the hierarchy becomes stronger - and a strong hierarchy needs clear separation of responsibility to function: a positive reinforcement loop.

Example 2: The mindset of a hierarchical organization

As soon as a hierarchy has been defined, people start to think in terms of that hierarchy. "We need a Silly Walker for the Ministry of Silly Walks".

It doesn't stop at needing someone who meets the requirement of Silly Walking: we wouldn't want to hire just anyone for Silly Walks - we need someone who is good at Silly Walks, who has experience and who is the perfect fit for the position. Rather than consider the myriad of ways in which a person can add value to the organization, the position of Silly Walking would be given to a person with proven track record of Silly Walks, a person with a history in Sales and Marketing wouldn't even be considered.
Likewise, a person who worked in Silly Walks for years is "obviously" best suited for Silly Walks. It becomes ludicrous to entertain the idea to place such a person in IT or customer care. The pervasive mindset becomes that people can only be good at the things they did before - a "fixed mindset":

As titles become more important, people themselves stop entertaining the idea of changing roles - why would a VP of Silly Walks want to take the role of "Developer" or "Scrum Master"? So instead of moving towards a system where people can learn and contribute the highest value to the organization, the system preserves its hierarchy: "Because I have this position, I will fight tooth and nails to preserve its existence."

We end up with a vicious circle where a fixed mindset entrenches itself and becomes a self-fulfilling prophesy.

Example 3: Transitive preservation mechanisms

When an organization would take steps to fix their problems one by one, they could do something about it - for example, let's say the organization would choose to get rid of the hierarchy in an attempt to remove the need for Resume/CV processing:

They will soon discover that the hierarchy isn't what led to the need for CV processing, although by direct causation, the primary construct which made Resumes necessary no longer exists. Even if the entire management layer would leave, people would still think in titles and positions, would still feel a person's value to the organization could be defined by their CV - and would think that CV's are still a good idea. Eventually, people would resort to "fixing the problem" of absence of hierarchy by - reintroducing hierarchy.
The transitive nature of systemic dependencies would rengenerate the system back to former status quo.

The complexity of the system

We just took one small example on three items from the system model - and there's a whole lot more to it. For example, large hierarchies with clear boundaries set people apart: "Those sales peeps" or "That's an IT problem" are just examples of common statements we often hear.
To control this separation, reports are introduced - and reports without consequences are meaningless, so systems of reward and punishment are introducted - which induces fear, both on punishment and reward (Fear of Missing Out) - which leads to shoving problems under the rug, which reduces transparency, which makes it more difficult to trust -- yada yada.

Regardless of where we look, a corporate system makes sense when looking at it from within the system: if we would abolish any single component, there would be more problems, so we need to re-introduce said component.

The real issue behind such a complex system is its tendency to meet the Laws of Irreducible Complexity.

Self-Preservation

A corporate system preserves itself due to a number of closed and transitive feedback loops: for example, even if we would remove the "Reporting" and "Rewards/Punishments" components from the system, there would still be the problem of distance and absence of trust, which seems most logical in the Enterprise world to fix via introducing the abolished mechanisms.

Delayed effect

Change isn't instantaneous. An organization suffering from strong negative system variables or weak positive system variables won't spontanenously fix their problem by changing their components. For example, if we have a high fear factor, stopping extrinsic incentives isn't going to remove the fear - removal of fear takes a long time, and some people might never overcome the specters of the past.
Removing a systemic component and dealing with the systemic variable by introducing a "repair construct" (such as coaching) need to go hand in hand - yet aren't a guarantee for successful change.

Change your mind!

Startups and small companies get by quite well without any of these mechanisms, and many larger organizations (such a volunteer organizations etc.) can also do without such artifacts.
Why does it work there? Because the basis is completely different. Instead of investing into hierarchies and titles, they invest into getting meaningful work done. Instead of introducing reports, they work on creating transparency and trust. Instead of creating a value plaque to hand into HQ, they talk about what matters to them. Instead of hiring for fit, they hire for value - and so on.

You can't reinvent a corporation by abolishing or fixing one mechanism - you have to start with the mind and work on everything at the same time!

Complex, yet simple

This model contains a lot of assumptions and simplifications. Organizations are significantly more complex, and the mechanisms which make people tick could be innumerate. I wouldn't be able to fit all important factors into this model and still let it be readable.

When attempting to make changes to a complex system, we need to understand the important components, variables and levers. What we consider "un-important" and neglect in our modeling might crawl out of the cave and bite us at the most inconvenient moment. Even with the above model, careful consideration needs to be exercised before trying to change a system.

Conclusion

There is no simple way to change an established organization, even when that organization is a dreadful place to work.

It's much simpler to build up a new organization with a blank slate and without all the harmful constructs than fixing an existing system.
Where this is not an option, the process of change relies on constant feedback about the current state of the system and permanent discovery of the hidden systemic factors which would snap the old system back into place.

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:

Agile in the Value Stream

Many organizations claim to be agile without ever having understood what makes a company agile. They bought an "Agile Transformation" - and think that afterwards, agility is achieved. What does this look like, why is it fake - and what is the difference?

Fake Agile

Let's take a look at a typical organization value stream for software delivery:

Being agile without customer contact never worked!

In the beginning, there's Marketing, Presales and Sales, all talking with the customer, discovering what the customer needs and is willing to pay for. Once a contract is signed, the project is planned, requirements are formulated, some code is written, tested and then deployed.  All straightforward.

When the organization realizes that customers aren't getting what they want and/or are getting it too late or expensive, managers are looking for a way out. Enter: "Agile", most notably: Scrum. Scrum uses terminology like "Development team", and since most people equate "Coding" and "Development", Scrum is being introduced as the miracle pill in the Coding stage of the value stream and the organization expects all problems to be solved.

Developers are still not in touch with customers, work off specifications and hand off bulk increments into testing, where then defects are discovered, reworked, launch is delayed - and nothing has improved.
Even though this form of "Agile" might improve the amount of work done by developers and slightly reduce the overhead of getting code finished, in the big picture, even a 100% effort reduction in Coding would still only reduce the overall effort of getting a project to "Done" by a mere 12%.
Since a 100% capacity increase in coding - which is a massive stretch for most organizations - performance is merely a 50% reduction in duration, it's almost impossible to achieve a statistically significant (thereby, visible) improvement in organizational performance across the value stream.

This kind of organization tends to be trimmed for efficiency, where each department tries to both maximize utilization and minimize their own cost.

Even if coders were absolutely perfect, worked in zero time and for free, the overall approach would still be staggeringly slow, ineffective and not satisfying to the customer. This is why such an approach to agility is fake.

Genuine agile delivery

An agile organization is most notably different in one aspect: The customer is at the heart of each activity. Not "fake customers" like sales who, although demanding something, are not those who actually will be using the product - but the real customers who are interested in using the product themselves:

Customer Centricity in everything we do

What makes things slow, unreliable and expensive are the handovers, where delay is introduced and information is lost. We need to drop organizational barriers and let everyone talk with the customer as needed. Departmental priorities need to be replaced by product priorities. Everyone needs to collaborate with each other and the customer in achieving one common goal: maximizing the value delivered while minimizing overall effort.

Coding is no longer the focus of being agile - not even IT as a whole. Indeed, the focus shifts away from activity to outcome. What matters to business success isn't that IT can get their job done, but that the customer gets what they need! Everything else will fall into place accordingly.

In this kind of organization, some things don't appear to be efficient. The same discussion may happen multiple times (which is still better than working against unfounded assumptions) and cost is fixed, irrespective of workload.
Agile organizations optimize for effectiveness, i.e., getting things Done in a way that pleases the customer.
This only makes sense from a system's perspective, not from a departmental perspective. Hence, it's important to include everyone in such a process. Any function not included will end up a bottleneck and could block the flow.

Fully agile enterprises

I omitted "Operation / Maintenance / Customer Service" functions in the above model, even though these are equally (and potentially more) important. This breaks down the final barriers beyond "Done", integrating practical experiences with the product into the feedback loop as well.
In the ultimate stage, every action is aligned with customer needs and every piece of learning harnessed for competitive advantage.

Conclusion

Contrary to popular belief, "being agile" isn't something limited to software development. It's a way of running an enterprise that revolutionizes how we think about value streams and value generation.

While the first hurdle in an agile transition is often rewiring the brains of developers to move away from meeting requirements to understanding customers, it by far isn't the biggest. The biggest hurdle is breaking out of a limited IT setting - and opening the doors for the collaboration of all departments for one common goal: business success.

My discovery journey to FaaS

Moving from monolithic systems to autonomous services is more of a mindset challenge than a technical challenge, although depending on the architecture of a system, the latter can already be tremendous. In this article, I want to describe my own discovery journey which changed how I perceived software systems forever.

Introduction

I was working for a client on an Information Discovery project which gathered and evaluated data from a range of other platforms which were basically a Stovepipe Architecture, so we had brittle, incomplete data objects from a wide range of independent systems which all described the same business object. There were two goals: First, link the data into a common view - and second, highlight inconsistencies for data purification. So to say, it was a fledgling Master Data Management system.

Stage 1: The Big Monolith

Although I knew about services, I never utilized them to their full potential. In stage one, my architecture looked something like this:

The central application ran ETL processes, wrote the data to its own local database, then produced a static HTML report which was sent to users via mail.
The good news is that this monolithic application was already built on Clean Code principles, so although I had a monolith, working the code was easy and the solution flexible.

The solution was well received - indeed, too well. The HTML reports were sent to various managers, who in turn sent them to their employees, who in turn sent them to their colleagues who collaborated on the relevant cleanup tasks. This was both a data protection and consistency nightmare - I couldn't trace where the data went and who was working with which version. So I moved from an HTML report to server-side rendering within the application.

Stage 2: Large Components

My application became two - an ETL and a Rendering component, both built on the same database. I had solved the problem of inconsistent versions and access control:

But there was another issue: Not everyone needed the same data, and not everyone should see everything. There were different users with different needs. The Simplicity principle led me to client-side rendering: I would pass the data to the frontend, then let the user decide what they wanted to see.

Stage 3: The first REST API

I cut in a REST layer which would fetch the requested data from the backend based on URL parameters, then render these to the user on the browser:

This also solved another problem: I wouldn't need to re-create the report in the backend whenever I made changes to layout and arrangement. It enabled true Continuous Delivery - I could implement new representation-based user requests multiple times a day without having to do any changes to any data on the server. The cycle time was three to five relevant features - per day, and so the report grew.

Guess what happened next? People wanted to know what the actual data in the source system was. And that meant - there was more than one view.

Stage 4: Multiple Endpoints

Early attention to separable design and SOLID principles once again saved the day. I moved the Extraction Process out of the ETL application and into autonomous getter services: 

This made my local database asynchronous with the data users might see, but this was a price everyone was willing to pay - it was enough if the report was updated daily, as long as people had access to un-purified raw data in real time. Another side benefit was that I pulled in pagination - increasing both performance and separability of the ETL process as a whole.

Loose coupling allowed me not only to have separate endpoints for each Getter, it allowed me to completely decouple each getter from a central point: I could scale!

As the application grew in business impact, more data sources were added and additional use cases came in. (To keep the picture simple, I'm not going to add these additional sources - just imagine there's many more).

Stage 5: Separate Use Cases

This modification was almost free - when the requirement came, I did it on a whim without even realizing what I had done until I saw the outcome:

Different user groups had different clients for different purposes. Each of the client needed only a subset of data, and that data was a subset of the available data - I could scale clients without even modifying anything in the core architecture!

And finally, we had network security concerns, so we had to pull everything apart. This was a freebie from a software perspective, but not a freebie from an infrastructure perspective: I separated the repositories and deployment process.

Stage 6: Decentralization

In this final stage, it was impossible to still call it "one application": I ended up with a distributed system with multiple servers, each of them hosting only a small set of functions which were fully encapsulated and could be created, provisioned, updated and maintained separately. In effect, each of my functions was a service running independently of its underlying infrastructure:

And yes, this representation omits a few of the infrastructure troubles I had, most notably, availability and discovery. The good news is that once I had this pattern, adding new services became a matter of minutes - Copy+Paste the infrastructure provisioning and write the few lines of code that did what I wanted to achieve. 

Conclusion

As I like to say, "The monolith in people's heads dies last". Although I knew of microservices, I used to build them in a very monolithic way: Single source repository, single database and single deployment process. This monolithic approach kept infrastructure maintenance efforts low and reduced the complexity of maintaining system integrity.

At the same time, this monolithic approach made it difficult to separate concerns, pull in the necessary layers of abstraction to separate use cases, resulted in downtimes and a security nightmare: When you have access to the monolith, everything is fair game: Both availability and confidentiality are fairly easy to compromize. The FaaS approach I discovered for myself would allow me to maximize these two core goals of data security with no additional software complexity.

Thanks to tools like Gitlab, Puppet, Docker and Kubernetes, the infrastructure complexity of migrating from is manageable, and the benefits are worth it. And then, of course, there are clouds like AWS and Azure which make the FaaS transition almost effortless - when the code is ready.

Today, I would rather build 20 autonomous services with a handful of separate clients that I can maintain and update in seconds than a single monolith that causes me headaches on all levels, from infrastructure over testing all the way to fitness for user purpose.

This was my journey. 

Your mileage may vary.

How not to run an agile project

This is an example how an agile approach fails. It's a rather painful lesson of messing up and I write from my own perspective, without any intent to blame anyone - just as a note of caution for those who might be in a similar situation.

Introduction

I was working with a client who needed an important business critical system.
Their IT department was organized with traditional project management and ran on 1-2 months cycles. Because this product would be core of the business for years to come, I suggested to do this with internal staff, who would later maintain and enhance the product. The suggestion included putting up a cross-functional team with six people, one process manager, two analysts who should also produce test scenarios, two coders and a sysop.
I wanted to deliver incrementally using fast feedback cycles to both offer maximum value to the business quickly and close any potential gaps in understanding on the go.
And so it came to pass that I was to be the Project Manager of this team. Due to staffing reasons, I ended up with an external and an internal analyst as well as an external and an internal developer. No problem - or so I thought.

Mishap #1: Autonomy

The first battle my team fought was that of opinions about technology. Microservices were to be used, and the data was mostly complex and weakly structured. The team's choice fell on a document-oriented database, MongoDB. This choice was met with massive resistance from the developers outside the team who weren't familiar with this technology. There was over a month of debate whether this technology was appropriate, and nothing got done because we didn't even have a way to store data. We finally reached a point where senior management had to intervene. Even after that, no developer outside the team would bother to learn about this new technology. Strike #1 against the team, they didn't have the support of other developers.

Problem: The team wasn't empowered to make autonomous decisions to begin with.

Mishap #2: Continuous Delivery

Continuous delivery was the plan, and we had two-week iterations to begin with. Unfortunately, the company was a bit short on infrastructure, so we didn't get an environment for five months. I did let this pass, because it was a problem outside my sphere of control. In retrospect, it was what probably killed the project to begin with, because we couldn't deliver anything of value for a long time - and when we did, it looked staggeringly miniscule. As a team, we were now in the defense already.

Problem: No Continuous Delivery, no feedback learning.

Mishap #3: Mixed Responsibility

No bragging, just describing the role. My role included responsibilities from PO and SM functions, lead business analyst and tester, as well as those of a traditional Project Manager. As you can guess, this cocktail turned really sour. I couldn't be a neutral SM when I was pushing a technology choice, I couldn't be the PO focused on user needs while tracking tasks and making timelines and I couldn't be the team's confidate when pressing for results.

Problem: Scrum roles and traditional project roles don't blend - especially not in one person.

Mishap #4: Culture

From the beginning, we faced resistance from the remaining IT staff, cumulating in seemingly witty remarks such as, "Do developers pick their own work here?" or "Do you seriously want to tell me developers test their own code?" The culture of an agile team made the team an intruder, an outsider for the others. It attacked their very belief system. Combined with #2, we really didn't have anything to show, so the criticism grew louder with no results to counter them.

Problem: Simply working in the same room with people who don't understand what you're doing won't have the conversion effect you expect.

Mishap #5: Clean Code

Getting a small microservice out of the door shouldn't be much of an issue with five people and a couple of weeks on your time. Enter - lack of understanding of the "Simplicity" Principle. You won't be agile when people turn a simple SQL query into a battleship of complexity.
We lost months on un-maintainable legacy code because one developer took private code ownership, hard-coding tons of magic numbers and nesting over twenty loops - only to discover that stuff didn't work properly and nobody could figure out why.

Problem: Before trying to work in an agile manner, developers need at least a rudimentary understanding of software craftsmanship.

Mishap #6: Management

After the line manager saw that I wasn't properly commanding and controlling the team, he started pushing his superiors to "fix this problem". The result was that we ended up with two project managers - one to take care of the project and the line manager, who wouldn't take any responsibility except ensuring that people reported to him (mostly things which neither they nor he even comprehended) and met pre-appointed deadlines that were created in complete disregard of the time required to do the work.
This second manager caused developers to skip writing tests, checking in quick-and-dirty code, skipping on the agreed DoD to avoid punishment. Basically, this second manager invalidated our entire agile approach within weeks.

Problem: Team autonomy is a farce when someone outside the team says what by when. A PO who must accept such externally imposed constraints is a toothless tiger.

Mishap #7: Trust

The absolute elephant in the room was a complete absence of trust which I didn't address in a timely fashion. The more trust there was inside the team, the bigger the distrust of those outside became. The line manager became weary that people started to have opinions contradicting his own and could no longer be commanded and controlled so easily. Trust became an even rarer commodity as defined responsibilities weren't met, professional boundaries were violated and snippish comments about other people's actions proliferated.
I'm not going to exempt myself here, such a mindset is truly contagious and definitely not helpful.

Problem: As long as there are trust issues, doing work is irrelevant. When the trust can't be mended, it's better to end fast than drag on.

Summary

Yes. I messed up. I took a too large portion. I will avoid to take such an "omni responsibility" in the future, simply because I won't have either the time or energy to fix all the fatal problems. The Scrum value of "Focus" can't be maintained when meddling in too many issues at the same time. The biggest problem was trust. It is the root cause of all other problems - and letting trust issues go unchecked is a surefire recipe for disaster.

Lessons for the future

1. The team must be empowered to make decisions about their work autonomously. While input from the outside organization needs to be considered appropriately, the differing opinions from those not even doing the work should never paralyze the team.
2. Forget working in an agile fashion without the necessary support infrastructure. If you can't get it quickly, you might as well scrap the entire project. When it takes four months to get a build environment, your team is toast. For me personally, I will put an exit clause in future agile contracts that I will quit when my teams don't have build infrastructure within a week.
3. When one person thinks of a traditional project manager and another thinks of an agile Product Owner, conflict is pre-programmed. This conflict can't be solved by compromise. A clear role definition upfront goes a long way. As long as the client doesn't understand the difference, it doesn't make sense to start working. If the client is willing to learn, a solution can be found. Otherwise, continuous conflict is pre-programmed.
4. "Culture eats strategy for breakfast". I know this, yet it's so easy to forget in the heat of the battle. Taking on too many roles simultaneously makes it too easy to forget leaning back and see how culture is preparing its next meal. A pure coach can observe and have the right conversations at the right time. A PO/PM caught in delivery mode goes blind. I did. Against better knowledge, so I can better understand those who have the same problem.
5. You will only be as agile as your team, and "Continuous attention to technical excellence" is part of the agile principles for a reason. Working with developers who haven't kept up to date in years is another surefire way of producing an unsustainable product. In future PO roles, I will make sure there's a training budget and developers get proper training so that the best they can do is on top notch level.
6. Two managers doesn't work for the same reason as we don't have two Product owners or two POTUS. One must give the direction. There can't be two winning strategies that aren't the same. Next time someone tries pushes me to share a single management/PO role with someone else, I will resign. Immediately.
7. Trust is paramount. I thought trust would come over time as we would deliver. I was wrong. On so many levels. No Trust - no Done. In future endeavours, I will invest much further into trust building, and when I discover that's impossible, it's better to end fast than drag on.

"A bad system beats a good person every single time". I don't even claim to be a good person, but I do say that I learned a lot about spotting systems which are set up to fail.

And I hope this article is helpful for you, too.

Why one size of "Agile" can't fit all

Have you ever wondered why there isn't one "Agile" approach that works everywhere? After all, being agile is about being flexible - so why not invent a sufficiently flexible method that's suitable in every context?

This model is an attempt at explaining:

Your context defines your approach!

The domain of Understanding

On the horizontal axis, we have the domain of "Understanding". It's what we know and understand about the things we do. Discounting dumb mistakes, we can just assume that we put our understanding to good use.

Known

In the Known, we're very clear what the outcome of our actions is, and therefore, which action is best - for example, what happens when we produce 100000 more of the product we have already produced 1000000 of, that is: mass production, factory work.

Working with Known domain basically centers around doing the same thing as good as we can.
We try to minimize cost and effort in our attempts to maximize productivity.

Dwelling in the Known is about optimizing.

Unknown

In the Unknown, we either lack prerequisite information on the consequence of our actions - or there are simply too many possible outcomes to predict which one we will receive.

Working with the Unknown tends to boil down to eliminating potential undesirable outcomes until the only possible outcomes left are desirable. It means doing variations of things we know until we know what works best - and what doesn't.
We try to maximize the result of doing something successful while systematically evading the things we know to be unsuccessful - we explore.

Dwelling in the Unknown is about exploring.

Unknowable

The Unknowable is the realm where regardless of how much information we had, we still couldn't predict the outcome. The Unknowable is full of opportunities - and that's what makes it attractive. Untapped business opportunities only reside in this domain. A new board of Minesweeper would be a case of the "Unknowable".

An example of the Unknowable would be next week's lottery numbers - a future action has to occur before we have a chance of knowing the result of our action.

Working with the Unknowable is taking best guesses at what might potentially work and hoping that we don't hit on something we can't recoup from. It means trying out something we haven't tried before - and learning from experience.

Dwelling in the Unknown is about discovering.

The domain of  Risk

On the vertical axis, we have the domain of "Risk", or "Control". It's how well we can influence the outcome of our actions, how likely a predicted result can be produced. Again, discounting dumb mistakes, we can just assume that our controls work as designed.

Controlled

Working with controlled processes, we would deterministically get what we bargained for. For example, dropping a needle will always result in a needle on the floor, everything else would be outlandish.

Controlled processes can be fine-tuned. We try to eliminate any activity that doesn't result in the desired outcome and introduce more activity that does get us the desired outcome.

Dwelling in the Controlled is about simplifying.

Uncontrolled

There's a lot of uncontrolled stuff - things that either simply aren't likely enough to warrant a control action or things that are off our radar. A typical example of the Uncontrolled may be the likelihood of a Nuclear Meltdown causing fallout and radiation poisoning our Lead Developer. We might simply choose to keep this risk uncontrolled, because investing into ABC-Suits for our office doesn't sound like the most sensible way of spending money.

Uncontrolled factors in our processes are risky. There are risks we choose to take knowingly - and risks we simply forgot about. While it's haphazard to take high impact risks with simple mitigation plans, we can never eliminate all risks we can think of.

Uncontrolled processes can be improved by reducing the impact of variation.

Dwelling in the Uncontrolled is about standardizing.

Uncontrollable

And finally, there's the uncontrollable stuff. Those are things we couldn't control even if we tried to - for example, flu season. We can get flu shots, but we can't guarantee this year's virus isn't resistant to the vaccine. We have to live with the Uncontrollable and hope it doesn't kill us.

At best, we can try to pull things from the Uncontrollable into the realm of the Controllable. That may work best by changing our strategy to not rely on uncontrollable things.

Dwelling in the Uncontrollable is about stabilizing.

The Domains

Having explained the model, let's take a really short look at each of the quadrants:

Known

Competing in this area, the winner is determined mostly by efficiency.

Known & Controlled

Here, we can reliably plan and trust in the plan's execution. The best way forward is to create the best plan we can think of and follow it through.
Given two competing organizations, the one with the most efficient process wins.

Known & Uncontrolled

Our plan may be disrupted by day-to-day events, slowing us down, leading to extra costs and causing inefficiency. The best way forward is to learn from mistakes, improve and return to the plan.
Given two competing organizations, the one who is best at eliminating errors wins.

Known & Uncontrollable

Our plan can also be disrupted by events outside our sphere of influence and control. This may throw us off track, requiring in major efforts to return to plan. The best stratetgy is to have a watchful eye when something Uncontrollable infringes on our process and design a way to make the process resilient to identified disruptions.

Given two competing organizations, the one with the most resilience wins.

Unknown

Competing in this area, the winner is determined by speed of learning.

Unknown & Controlled

Having a clear way of taking steps to reach something that is either useful or not - and we use simple experiments to determine our path. We make the Unknown Known, then optimize.

Given two competing organizations, the one who can turn experiments into results faster wins.

Unknown & Uncontrolled

There is unpredictability in both process and in the results. Our best strategy forward is one of small steps to minimize the risk of having variance leading to undesirable outcomes. We build upon good results and backtrack from bad results.

Given two competing organizations, the one who is most scrutinous at dealing with problems wins.

Unknown & Uncontrollable

There's a constant danger that we're thrown off-track and we don't even know what the right track is., much less what the "best" track would be. We need to safeguard our path with measurements, as the path might collapse right under our feet. We constantly need to innovate in order just to maintain that which we have.

Given two competing organizations, the one that can adapt to circumstance best wins.

Unknowable

In this area, those who happen not to stumble upon anything of value lose by default. On the other side, there's no guarantee of winning, either.

Unknowable & Controlled

Science is full of the Unknowable. We hypothesize, we explore - and we see if we're right. The most solid guesses lead to something we can build upon. When we discover something of value, we still need to explore the context until we have something workable.

There is no predictable or reproducible winning strategy, but if we have a means of turning discovered value into profit, we're more likely to succeed.

Unknowable & Uncontrolled

Being exposed to an unfamiliar environment requires us to make the best use out of whatever means we have. If we can't manage to get into familiar terrain, we might at least familiarize ourselves with the terrain, then work from there.

Those who lose have no success story to tell, while those who won oftentimes make it look like their success was planned all the time.

Unknowable & Uncontrollable

There is no predictable strategy for anything. We can try something - and if it works, we try more of it to see if it still works. And just because something didn't work, it doesn't mean it was bad. It might have been the right thing turning out wrong.

In this realm, everyone who manages to survive is a winner.

Summary

What does "succeeding with agile" mean? It depends on what you're looking for.
Those who operate in known, controlled circumstances will be much more successful with improved planning - while those who operate in unknowable, uncontrolled circumstances are served best by not wasting time on planning.
Those who try to adapt to external risk in known processes need a different strategy than those who explore in a lab environment.


None of these environments is pure. Oftentimes, we have some things we know and control, while other things are neither known nor controllable. It would depend on what the ratio of these areas is in our work - and where we want that ratio to be.

What does that mean for agility?

We need to determine which circumstances we are in, then tailor our approach to doing that which is most likely to be a winning strategy. And we must know many different approaches, in order to select that which helps us best.

We're not served well by introducing Scrum into a Known/Controlled environment that would perform better with a linear approach - and we're not served well by introducing SAFe into an environment that would have their problems solved by Six Sigma. Likewise, we're not helping anyone by putting Kanban on top of an undetermined, unpredictable process.

What is appropriate where - fully depends on where we are and where we want to go.

And what does that mean for agile practitioners?

There is no universal context that makes any approach valid or invalid. As practitioners, we must:

• Leave our dogmatism
• Tailor "agility" to context
• Understand and remove hindering constraints
• Acknowledge Unknowns and seek help
• Remember that "agility" isn't the end goal
• Recognise that there is more to "agile" than "agile"

And that's why we came up with Agnostic Agile.