Thursday, February 14, 2019

The 5-minute Retrospective: Try Speedrospectives!

Agility depends on receiving timely feedback and turning it into effective change action. Relentless improvement requires closing feedback cycles wherever possible and whenever possible. 


Why Speedrospectives?

Many new Scrum Masters follow the boring, time-consuming and ineffective "What went well/what didn't go so well" template and can burn hours of precious team time without causing significant change - this model often degrades to a platform for self-adulation and/or ranting.

The Scrum Master -- or any agile coach, for that matter -- should create a self-perpetuating system of Kaizen, "Striving for the better", and do this in the most effective way.

Have you considered a Retrospective after every single meeting in your organization, to improve these meetings themselves and thereby increase the value of communication? How much time should that consume to be worthwhile?
A regular Retrospective is unfeasible in this context - but where, when and how do you address improvement potential then?

An important part of behavioural change is to address the situation as it occurs so that the memory is still fresh and set the stage for a future, more desirable condition.

The 5-minute Retrospective

When you know your audience and the situation is already stable, there's no need to go through the (definitely helpful) 5-stage Retrospective Process, you can just cut straight to the heart of the matter: What should be different next time in order to get more value?

And that's where my handy Speedrospective template comes into play:


The diagram itself is self-explanatory:
"If we do this again, the next time, we should ..."

  • Try: Introduce a new element or modify an existing element. For example, in a Retrospective, it could be: "Try whiteboards instead of sketching on letter-sized paper"
  • Stop: Elements which should not be repeated. For example: "Multiple people talking"
  • More: Elements which are helpful and could use strengthening. For example: "Collaboration on issues"
  • Less:  Elements which, although helpful, are overdosed. For example: "Process explanation".

Schedule of the Speedrospective

Create sketch

If you're fast (which is what this is about), you draw an X and write 4 words. That should just take half a minute - or a minute, while you're explaining what's coming. (1min)


Collect items


Take 2 minutes to collect feedback - more time isn't needed, because if participants don't have anything on their mind, it's probably not important, anyways - and next time around they might prepare a sticky right in the moment when something happens because they know they can bring it up. (2min)


Decide


After issues are collected, vote ONE the group would like to see implemented. (1min)


Debrief


Agree how to make it happen and thank the group. (1min)



Summary

Speedrospectives are a highly effective tool to close feedback loops, initiate change and establish a culture of relentless improvement. The process is significantly more powerful than the "well/not well" template, because it's fully outcome focused.

Other uses

The suggested Speedrospective template can be used in many contexts, such as event closure - as well as in personal and organizational coaching.

Variations

There are many ways to commence a change-driving Retrospective within 5 minutes. The above approach is neither to be considered prescriptive nor the only way. Try experimenting with Speedrospectives and see what works for you.

A note of caution

Speedrospectives may miss fundamental change opportunities - for example, when we're having the daily frontend architecture status meeting, we will find ways of getting the most value out of this meeting without ever crossing the idea that the meeting itself isn't a good idea. They are not a panacea, just a simple power tool to support a continuous change mindset.




Saturday, February 9, 2019

Why organizations use Scream

The Scream framework has struck a nerve. This parody of the Scrum framework isn't just loaded with antipatterns - hundreds of people have already noted how similar Scream is to what they observe in their own organization.

Scream is a parody, and it would seem like nobody in their right mind would do those things - yet people do exactly that. But why?


Scream works!

Scream is effective. It works. The patterns found in the Scream Guide are all ways in which specific problems the organization has encountered have been addressed. And unlike Scrum, there is no rigour to Scream - it works very similar to the ice cream truck in summer. It addresses a need and makes people feel better.

Here's how:


The Scream flow


The Scream flow is easy and intuitive.

On the surface, it works like this:
A problem appears, and there's pressure to act before this becomes a personal issue, such as having an escalation, seeing your performance review drop, and therefore your bonus disappearing or whatever.

So why spend time to identify and isolate the root cause which may be hidden somewhere outside your own sphere of control? Pick a Scream pattern and apply it.

The pressure lifts - or at least, it goes down a few marks on the scale. Scream experts learn to throw Scream patterns at problems before anyone has even noticed there's an issue. Stress levels return to normal, and there's even a reason to celebrate having taken care of an issue.  Instant gratification.

And when the next problem appears? Rinse and repeat. Scream becomes routine quickly.


The rug

There's an insiginificant fly in the ointment. It's so miniscule that most managers and developers are more than happy to just let it go, as the evening is saved and no further meetings are required on the issue:
The problem wasn't solved. A band-aid patch is no cure. The core of the issue has been shoved under the rug, and the Scream "solution" has added another problem to the batch. No matter. Let's call it a day and move on to something completely different while the rizom continues to grow.

And one of these days, it will be harvest time. The problem has grown bigger than the rug and starts to resurface.

No problem - just apply the Scream flow and shove it under the rug again. It feels good to see the issue gone again.


Summary

Scream effectively makes problems disappear in an instant. This feels good. Even though the problems resurface and grow, there's always a solution: More Scream.





Sunday, January 27, 2019

The Agile Fallacy

"That's not Agile!" - does it matter? My claim - no!

"Being Agile" isn't true/false - it's a spectrum from rock to photon. Everyone is somewhere.


When looking behind the "Agile vs. Not Agile" bifurcation fallacy, we can start asking more meaningful questions:

  • Does the organization meet Market and Business Needs properly?
  • Does the Product stay relevant over time?
  • Are the Delivered Outcomes useful?
  • Is the Total Lead Time acceptable?
  • Is the overall Return On Invest of development positive?
  • Does everyone Focus on the most important thing?
  • Does development create up-to-date, Sustainable Solutions?
  • Is Technology Debt under control?
  • Is Improvement Potential leveraged effectively?
  • Do Failures get addressed and corrected openly?
  • Is there Continuous Learning going on?
  • Does the company exhibit Resilience to market changes?
  • Does the organization have a Sustainable Workload?
  • Does the organization attract, grow and Retain Talent?


If all these questions are answered with "Yes", then I could ask "Why do you want to be agile?"
If the answer to some or all is "No", then I would ask, "Then what are you doing about it?"

Taking a closer look, even these questions aren't binary, but gradients which would usually range somewhere from "We need to do something immediately" to "Yeah, we might want to think about it."

All the above questions are merely indicators of whether an organization is sufficiently agile for its own good, so I would leave you, as a reader, with the initial question: If an organization is excelling in all the areas mentioned above, does it matter whether they're agile?

Friday, January 25, 2019

Can you afford to have an IT department?

Many non-digital businesses augment their core business with digitization and automation. IT is "The Thing", and even though every organization want to have the benefits of an IT, few seem to consider the cost of IT. In this article, we will examine a few critical considerations.


Bad IT is just as good as burning cash.


When IT becomes a poor investment

In many organizations, IT is still considered a "feature factory" where business dumps in requirements, gets a cost estimate and upon approval, a piece of software to automate a phrased request, and that's it. Business and management neither wants to think about what is being done, nor how much effort is required to create and maintain the solution.

This approach was okay in the past, when the major cost of IT was in procurement of hardware and licenses and the human factor was neglegible.

Fixed cost procurement


Factoring the cost of a purchased IT product is easy: you have a purchase price for hardware and licenses, sign a support contract with a fixed price, order some training and you're done.
The cost of such an IT can easily be computed as a business case: when the cost is lower than the savings, you're good.

Cost Estimation

Unfortunately, that's not how today's or tomorrow's IT works.
Today, business wants automation for something that they are currently doing either manually or not at all. There is no solution which can be purchased.
Knowledge work is required. Since the optimal solution isn't known, the cost becomes difficult to compute, and therefore, all cost estimates are just that - estimates. There is no reliable way to tell the production costs of a feature until it is done.


Hidden Costs

And now we come to the fatal trap which many organizations fall victim to: the accruing cost of IT over time! Business terms like debt, deprecation and amortization are also applicable to IT.

Debt in IT

A financial debt is accrued when spending exceeds available funds. In IT, debt is accrued when technology is being utilized in ways which will result in future problems. Known debt still has the can be controlled, although few organizations measure and control thind kind of debt. Every accountant would cringe if someone told them, "Oh yeah, we're making debt every day, but we're neither keeping books nor make plans for repayment" -  yet this is how IT works in many companies.

Time-saving measures allow the business to get visible results faster, yet increase future cost.

In some organizations, this invisible IT debt is already so high that things which would take minutes on a green field take weeks within the existing infrastructure. Imagine that you're paying a loan shark an interest rate of a couple thousand percent per day - that's uncontrolled IT debt for you!


Deprecation in IT

The good thing about the constantly evolving field of IT is that new technology makes ever more complicated things ever simpler to achieve. On the reverse side of the medal, if you're not familiar with this technology, you're missing out!

While IT specialists are busy maintaining the existing legacy and struggle to integrate the latest feature requests, their technology outdates - and their knowledge, as well!

The company constantly invests into an ever-shrinking asset: status quo. At some point, the existing staff will no longer suffice to maintain status quo, so additional experts are brought in to keep IT running, although the marginal value of the infrastructure is already approaching zero.

Adding insult to injury, re-engineering the legacy based on the legacy processes with a legacy skillset using legacy tools exponentially increases the cost of change and produce a similiarly ineffective outcome.

Take, for example, the company still maintaning an IBM 704 mainframe: the costs of administration, maintenance and electricity are astronomical - yet the computing power of the system dwarfs a $100 smartphone! Yet, many companies still stick to their old systems because core business processes rely on them. Any effort to replace this legacy becomes unfeasible both because nobody has time and the effort is humongous.


Amortization in IT

The financial technique of amortization splits the cost of a finite-life product into a series of installments. and something similar happens in technology.
Danger: The analogy of amortization is highly flawed - your accountant would rip your head off if you tried to explain to them that:
  • You have no idea when the final installment will happen, and there will potentially be an infinite number of them!
  • If the present value of a system is lower than its cost, each installment will have a negative ROI.
  • You're very likely to pay installments long after the marginal value is zero.

Let's say, you your developers need a technical training; If you don't invest, their code is more expensive and less valuable than it could be - but if you do it, in a year, their code will still be outdated. You amortize not to generate profit, but to reduce loss.

IT is a money sink

Running an IT department is not just about having a handful of servers and building some business functionality.
This is how IT costs money:

IT assets are debt-riddled

Quick wins in IT tend to be even faster losses. Without a future-oriented sustainability strategy, you're no longer taking a controlled debt, you're baiting loan sharks!

If you don't (want to - or can) control your technology debt, your IT will eventually kill your business with skyrocketing costs at little to ROI!

Make technology debt visible and keep the interest at a maintainable level.


IT assets deprecate drastically

Any technology should be replaced within 5-7 years, so regardless of whether you're investing $1000 or $100m, be prepared to re-invest a similar amount in less than a decade. The more your IT is worth, the more it will cost you.

Without a deprecation control stratey, your IT will eventually be worthless, yet continue to drain money needed for investments.

Move towards continuous asset migration and decommissioning rather than investing heavily into maintenance and support.

IT assets won't amortize

Any technical or knowledge asset which isn't worth its cost by the time it becomes available, will never be. While cross-subsidization or taking a loss in order to avoid greater losses are both feasible options, throwing good money after the bad isn't a strategy!

The acquisition and maintenance of assets which "might have future value" is an unsound strategy that will most likely result in an economic shipwreck.

Avoid over-engineering, keep as little technology as possible and consider any investment "lost" the minute you signed the check.
Obtain technology only when it is needed, and only as much as needed.



An IT Investment strategy

Based on the above, let us now consider a few choices that you need to make with your IT:


  • Are you willing to consistently and scrutinously track and combat technology debt?
    • NO: You will lose cost control of your IT if you haven't already.
    • YES: Lapses cost twice. Be alert!
  • Do you have a sound mechanism for determining the net present and maginal value of your IT?
    • NO: Your ROI will most likely tank.
    • YES: When a processes' cost exceeds its marginal value, eliminate it.
  • Are you willing, able and ready to identify, replace or eliminate ineffective cost drivers?
    • NO: Your IT is a gambit with diminishingly low odds of success.
    • YES: Remember that yesterday's business driver can be tomorrow's cost driver!
  • Will you consistently invest a significant amount of time and money into the continuous learning of your IT workforce?
    • NO: Your IT is dead already, you may just not know it yet.
    • YES: Keep an edge. Avoid tailgating others.
  • Does your organization have the courage to admit and the grace to write off mistakes?
    • NO: Your IT will eventually be the Emperor's New Clothes.
      YES: Turn failure into learning, mishaps into opportunities for change.

If you have answered "NO" to any of the above questions, either re-consider your IT strategy or consider obtaining services from a provider who would answer all of them with "Yes".



Tuesday, January 22, 2019

A brief history of IT

Is your IT future-oriented? 
The nature of IT is changing - if you aren't adapting, chances are that your IT is a liability rather than an asset for your organization. So - what's different?

Yesterday's IT

The era whene IT was nothing more than automation of repetitive data processing is over.  Old IT systems were difficult to use, required scrutinous training, changed slowly were fully defined by static, prescriptive processes which permitted little variation. "IT" was mostly a data dump and retrieval center.

Users had a desktop client software which connected to a central database. The flexibility these systems possessed was in their ignorance of business processes (albeit sometimes with the pain, "We don't have a form field for this").

IT had full control of who had which version of the software and how the data was used - oftentimes, without even understanding what this data actually meant or how it was used.  Business processes were fully part of the business domain and outside of IT scope.

The legacy of this era remains a pool of low quality data and systems which are difficult to understand, maintain and upgrade.

Complexity was on the level of getting servers stable and software to run. Business complexity was neglegible.

Today's IT

IT does data processing more than ever - but the nature has changed.

More and more business logic has been inserted into IT systems, to the point where IT systems are doing actual clerical and administrative work. For example, a modern IT system not only accepts customer data, it might validate the customer's address, credit score, and order. IT systems reject bad contracts, informs the customer when products are out of stock, offers alternatives and even provides discounts, cross-sales, upsales and bargains. And that's just pre-fulfillment.

Such an IT is no longer a dumb data shelf for smart business processes - it becomes more the other way around: IT systems have an even deeper understanding of the business than any human being in the organization.

While many companies still face the complexity of managing their infrastructure, today most complexity resides in automating and managing the business capabilities.

Tomorrow's IT

In the age of "everything-as-a-service", IT infrastructure and processes are mostly automated. "Serverless", client-independent services can be used from anywhere for pretty much anything. Interconnected services route smart, self-correcting requests to achieve their purpose.
Autonomous agents discover and learn rather than blindly act upon pre-defined rulesets.

The IT of the future can do anything we can set our mind on - if we have the right skills and are willing to invest into the right tools. Constraints are either willful ("we don't want to ...") or external (e.g., "we can't afford ...") and no longer technological.

Although the technological complexity of such systems is extremely high, it is self-managed by other technology, allowing IT specialists to focus on creating enabling features and their interconnections.




Where is your IT?

With the above historic summary, you can quickly decide whether your IT is past-, present- or future-oriented.

Many organizations want to have tomorrow's IT, yet they are stuck maintaining and servicing yesterday's IT, so they can't even take the benefits of today's IT.

From an economic perspective such backward-oriented investments are hardly feasible, yet sunken-cost fallacies and fear of the Unknown make them commonplace.

If you're not prepared for the IT of the future, now might be a good time for making some strategic adjustments - improvement doesn't happen by itself, we must work towards it!

Wednesday, January 9, 2019

Setting meaningful goals

Tasks, Stories, Features, Sprints, Products, the company strategy - they all have goals, and each of these goals has an impact on overall success. Beyond SMART and INVEST which are focused solely on the definition of a goal, let's look at some important considerations for in the timespan between definition and achievement, i.e. the implementation phase.


The Goal Factors

Here are six factors which will help you define helpful goals:

Clarity

In discussions, people shouldn't be talking at cross purposes. During implementation, we need to know whether an action will be progress or distraction to act accordingly.  Clarity also affects how we determine whether a goal has been achieved or there is residual effort.

Clear goals offer little space for interpretation when the goal is achieved - and partial solutions are likely a step in the right direction. Unclear goals cause people to constantly stab in the dark.

Significance

A goal should always be so important that success as well as failure have a significant impact somewhere. If there is no impact, other things are probably higher on the list. Significance depends on the bigger picture. For example, a task or a feature are only as important as their contribution to the strategy.

Highly significant goals create a sense of urgency and importance and thereby provide a boost to motivaton.

Traceability

Goals exist for a reason. Regardless whether a goal describes a specific customer need or a strategic objective, there should be tracibility of where the goal comes from, what it contributes to and who is involved.

Traceability is a two-way street, so goal definitions need to be traceable downward into implementation as much as they need to be traceable upward into strategy.

Relatability

Every person involved with a goal should be able to relate to this goal. They should be able to figure out their contribution towards success as well as the impact the achievement or failure has on them.

Goals that are highly relatable are much more likely to be achieved than goals which contributors can't relate to.

Constancy

Goals should mean the same thing from the time they are decided until met. In rhetorics, the metaphor of "Moving Goalposts" describes a surefire way to derail any effort to make progress. A goal should not change. If it becomes different, then that is a different goal.

Constancy reduces waste, as detours are evitable. Any shift in goals turns all activity towards meeting the previous definition into waste.

Flexibility

Goals should be as flexible as possible in ways of achieving a favorable outcome. When a plan doesn't work out, alternatives need to be found without compromizing either the goal or its traceable line in the organization.

When circumstances change, flexible goals only require changes to the corresponding action plan, whereas inflexible goals might cause inefficient replanning and adjustment at multiple levels.

The importance for management

Goals which meet these six factors can be monitored effectively in multiple dimensions because of enhanced transparency in the following dimensions:
  • Success - was the goal met?
  • Progress - are we getting somewhere?
  • Blockages - are we moving?
  • Delays - what affects what else?
  • Waste - are we on the right track?
These items are equally important to individuals, self-managing teams and the overarching organization.

The importance for workers

Goals which meet these six factors will help workers in multiple ways. Working on such goals boosts:
  • Motivation - why is our work important?
  • Alignment - are we talking about the same thing?
  • Creativity - which options do we have to contribute?
  • Performance - how far have we gotten?
  • Accomplishment - what have we achieved?


Summary

Regardless of whether you're setting goals for the day, for the Sprint, for a Product or a Project - for a transformation program or for the entire organization, keep in mind that these goals should offer:
  • Clarity
  • Significance
  • Traceability
  • Relatability
  • Constancy
  • Flexibility
Without creating yet another futile metric, goals which are better on these six items will be more likely to contribute more to your overall organizational success  than others.

And most of all, if you miss setting goals - you're losing out both on the factors and on the benefits.


Monday, January 7, 2019

Goal Setting in an agile organization

Is your agile team is on track? Are you making progress? How do you know? Here are some tips to keep in mind.

You will notice in this article that nothing has anything to do with a specific agile framework or even with "agile" in general. Indeed, the remainder of the article will avoid the term "agile" completely. The suggestions are still fundamental to agile transition, because without these things, you're in for a trip to Wonderland!



Take your time and define, step by step, in the order presented in this article, the following items:

Mission

Where do you want to go, as an organization? Why does the organization exist, and what will be different because of the work that people do?
"To earn money" or "To pay the bills" won't cut the cake, although that's obviously something a company wants to be able to do. Your mission should discriminate you from the broad mass, giving guidance on things which the company would do and wouldn't do while being simple to remember.

Here are some guidelines when setting up a mission statement:

  1. Length: People need to remember it. Five words - maximum!
  2. Clarity: Provide meaningful guidance and direction.
  3. Breadth: Include everything you really want to - or are already - doing as a company.
  4. Focus: Must allow people to align activity.
  5. Avoid slogans: Must be useful as a yardstick in everyday work - and not just for marketing!

Examples:

  • "Improving work" is a legitimate mission for a consultancy,
  • "Delivered." would be a feasible choice for a logistics company,
  • "Everything covered" might be appropriate for an insurance.

These statements are broad, yet focused - short and clear and can be used as a discussion point when discerning whether an activity is in line with the company's goals or not.

A mission statement isn't immediately actionable. It's guiding in nature and should rarely change.

Strategy

From the mission, a small set of strategies should be derived - how do we plan to make this happen?
A strategy is a mid- to long-term plan for moving into a certain direction and should lead to some relevant outcome that is aligned with the mission.

As odd as it seems, this step is often skipped or neglected. Since a strategy is a clear statement of a direction into which we develop the organization, the presence of a strategy is necessary to determine whether you're still on track.
It isn't even necessary for management to define strategy - in many cases, employees have a good idea what strategies they would pursue, but they don't have any means or transparency to communicate this.

Taking one of our above examples, if we have "Delivered" as our logistics company mission, the following strategies might all be valid options:

  • Enter grocery delivery market.
  • Partner with company X and employ their delivery network.
  • Pivot Drone Delivery.
  • Build a Delivery Hotspot Discovery service to monitor and optimize efficiency.

Some strategies might require just a few months, others many years.
A strategy is good when we can tell clearly which set of activities is part of the strategy, when these activities are achieving the strategy - and how the strategy relates to our mission. Ideally, we can also fathom who could be involced and how long it might approximately take.

Strategies still aren't actionable, but they help people deciding for action determine what to do.
Keep the amount of strategies small, as too many dilutes your resource pool and impairs focus. Also, try having more than one strategy as putting all your eggs in one basket is a significant business risk. Two to five strategies are a decent bundle.

Revisit them about quarterly, abandoning those which are obsolete, reinforcing those which are worthwhile and adding one when needed.
Keep in mind: For every strategy you add, you should axe another, lest you lose focus and mess things up.


Goals

Strategies aren't equal, and the things we actually want to achieve might differ as well. This is where we get into the realm of setting SMART Goals: Specific, Measurable, Ambitious, Realistic, Time-bound.
We must be able to figure out how much of what we want to achieve by when - and that should  likewise be challenging and possible.

Many companies have trouble with this step because the wrong people do it. Ideally, goals are uttered by the people who will be working to achieve them and verified for priority, plausibility and strategic alignment by management, rather than enforced top-down. Only when management realizes that the workforce isn't able to set meaningful and important goals, should they feel the need to intervene by providing more clarity and context.

All goals are not equal.
Strategic goals might take years to achieve in a stepwise process, operative goals may be met fairly quickly and tactical goals could be succeeding each other in rapid succession.

The importance is that depending on their nature, they're frequently revisited and constantly verified against their alignment both with the strategy and mission - as well as with other goals the organization might be pursuing.

Transparency of goals is important to prevent the accidental pursuit of competing goals as well as enabling collaboration between people pursuing synergetic or overlapping goals.

When goals conflict with each other or strategy, everyone should feel free to have a voice and raise their concerns, as working on such goals would result in a loss of time, money and opportunity.

A problem with goal-setting is that when undergoing change, goal-setting isn't a straightforward action. Larger goals need to be achieved incrementally with intermediate checkpoints and feedback loops - another thing many organizations get wrong. Either they forget to feed subgoals back towards overarching goals, or to act upon information that a goal no longer makes sense.

Goal-setting on different levels should be a frequent exercise, but when a goal hasn't been pursued or seen progress in months, then that goal can be considered obsolete for all practical purposes. Don't bother with these - axe them. The shorter the time between goal-setting and seeing their achievement, the faster the organization can act.

Actions

Goals need to be met somehow, so some action must be initiated. Regardless of whether this action is an initiative, a program, a project or even just a small task - it needs to be clear who is responsible for the action and how we can know whether it was successful.

As one action could contribute to more than one goal, or one goal could require more than one action, creating clarity between the relationship of goal and action is essential, although the only people who can do this in a meaningful way are those who set the goal and who will be executing the action. If these people don't know - nobody will!

Since actions are only required to achieve goals, depending on the complexity of the work, it may or may not be important to make these actions transparent. When people's actions could block each other, these people need to communicate. Other than that, actions and their tracking are irrelevant.


Results

Every action should have an outcome - and that outcome can be as intended, or otherwise. It's a good idea to define the intended outcome right alongside the result, in order to assist the execution of the action.

It's essential for those who complete an action to know the intended results and correlating goals, as this is the yardstick for progress. Performance should move away from amounts of action conducted towards results achieved.

Results are the compass for action:

  • When results are moving away from the intended goal,s the action needs to be revisited immediately. 
  • When results are moving towards the intended goals, the action is on track.
  • If an action proves to be ineffective, it needs to be changed.
  • And when the intended goal is met, it may be time to either complete the action - or set another, maybe more ambitious goal.

Results should be revisited frequently and feed into their goals on at least a weekly basis. While "no result because no action" is an acceptable explanation, this is a clear indicator that something should be done in this context:
  • If the result is important, it needs to be prioritized for action
  • If the result has become obsolete, no further action needs to be taken.




Conclusion

Let's return to Alice and the Cheshire Cat for a minute.
If you don't know where you want to go or why you would want to go there, or how you would know whether you have arrived - it doesn't matter which way you take.

You need to have your mission defined ("where you want to go"), so you can state which strategy you want to pursue ("which way you go") and by defining goals with verifiable results, you can even discover whether you've gotten somewhere.

If you lack these three components, you will still get somewhere, eventually - but whether that "somewhere" is where you'd like to be, is a completely different story.

Just like Alice didn't know Wonderland and she had to explore, we often define goals without knowing the way and discover midway that both the goal and our action was maybe not the best choice. Still, we are where we are and have to move from there, so our process of locating ourselves, and determining the next step are essential.

The more frequent and painlessly we can go through the feedback process of Goal-Intention-Action-Result, the better we become at getting where we want to be.

And to close with the Cheshire Cat:
"You sure do that, if only you walk long enough".


Tuesday, December 25, 2018

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.

Thursday, December 20, 2018

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!




Sunday, December 9, 2018

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.





Sunday, November 25, 2018

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.
  • red arrow represents a negative causation, which means by adding more of the source, you get more of the target.
  • 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.

Sunday, November 18, 2018

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.


Sunday, November 11, 2018

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 helpfulHelpful
Project ManagerHelp management change from moving teams to work towards moving work to teams
Release ManagerAssist Product Owner and Developers in defining and tracking releases
Delivery ManagerRemind the teams of their responsibility to deliver
Process ManagerReflect on the process
Team ManagerRemind people when they break their Working Agreements
Problem solverSupport the team in solving their problems
Scrum EvangelistTeach Scrum in and around the team
Meeting Organizer / ModeratorHelp the team have effective meetings
Technical / Subject Matter ExpertExpert in regards to Scrum, change management, coaching
Jira AdminSupport the team in discovering and using appropriate tools
BouncerHelp people realize which interactions aren't helpful
Enforce ScrumRemind people when they break Scrum
Track team‘s progressSupport the team in making progress transparent
Produce reportsCreate transparency
Threaten, manipulate, coerceEncourage the team to do their best



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


Thursday, November 8, 2018

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: