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.