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?


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.


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.


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.


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:

Friday, November 2, 2018

Agile in the Value Stream

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

Fake Agile

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

Being agile without customer contact never worked!

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

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

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

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

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

Genuine agile delivery

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

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

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

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

Fully agile enterprises

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


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

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

Wednesday, October 31, 2018

My discovery journey to FaaS

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


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

Stage 1: The Big Monolith

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

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

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

Stage 2: Large Components

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

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

Stage 3: The first REST API

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

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

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

Stage 4: Multiple Endpoints

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

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

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

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

Stage 5: Separate Use Cases

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

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

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

Stage 6: Decentralization

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

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


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

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

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

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

This was my journey. 
Your mileage may vary.

Monday, September 10, 2018

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

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

This model is an attempt at explaining:

Your context defines your approach!

The domain of Understanding

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


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

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

Dwelling in the Known is about optimizing.


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

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

Dwelling in the Unknown is about exploring.


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

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

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

Dwelling in the Unknown is about discovering.

The domain of  Risk

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


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

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

Dwelling in the Controlled is about simplifying.


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

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

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

Dwelling in the Uncontrolled is about standardizing.


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

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

Dwelling in the Uncontrollable is about stabilizing.

The Domains

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


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

Known & Controlled

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

Known & Uncontrolled

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

Known & Uncontrollable

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

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


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

Unknown & Controlled

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

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

Unknown & Uncontrolled

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

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

Unknown & Uncontrollable

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

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


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

Unknowable & Controlled

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

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

Unknowable & Uncontrolled

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

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

Unknowable & Uncontrollable

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

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


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

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

What does that mean for agility?

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

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

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

And what does that mean for agile practitioners?

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

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

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

Saturday, September 1, 2018

Why "Agile" rarely works

Have you ever wondered why every organization wants to be agile, yet very few managers are? 
In this article, I will explore a highly philosophical model to attempt an answer.

TL;DR: Because it means changing how we see reality - and that's a price few are willing to pay!

Let's explore the model:

Yes, the main terms are German - because I realized that the English language uses the same term for "how we see the world" and "how we think the world is" - a distinction that clearly exists in the German language. Then again, I use the term "world model" - so let's float with English. Let's take a look at the model from right to left. I will just gloss over the deep concepts of these terms, because this is just a quick glance rather than a scientific essay.


Reality does not care for us - it's just us who are affected by it. The better we get at predicting how reality will respond to our interactions, the more we start to believe that we are "right" about reality - while essentially, it's just congruence between our world model and reality around us.
For example, a team might just do what they do - oftentimes, oblivious of their managers' thoughts and without regards to whether any manager is even around.


As we observe or interact with reality, it affects us - what we feel, see, how we classify things, and what we would do next.
Our impressions are strongly filtered: First, we only receive a limited amount of impressions - essential information may exist outside our impressions. Second, we have a strong tendency to only receive those impressions we are looking for.

As a specific example: A traditional manager observes an agile team in action. The manager might get the impression that "this team is working laissez-faire" because nobody is checking on people, and might also get the impression that "this can't work" because there is no visible hierarchy in the team.

To change our ways, it's quite important to discuss the impressions we receive, in order to learn where we lack "the big picture" or we're over-emphasizing details.

World view

Our world view is the main filter of the impressions we receive. Every impression consistent with our world view will be forwarded into our conscious thinking, while impressions that are inconsistent with our world view will either be reinterpreted until they fit - or they will be discarded outright.
In this sense, our world view is the "eye" through which we obtain information. A narrow world view will imply that few impressions will go through unfiltered - while a broad world view will allow us to receive a lot more impressions.

Giving an example again, when an agile team decides to abolish progress reporting in favour of live product reviews, their manager must first be open to the idea that "working software is the (only relevant) measure of progress". As long as the manager's world view does not allow measuring progress in terms of production-ready software, they will discount both the benefits of interacting with users and the additional productivity obtained by not tracking work. Instead, their world view will make them see all the problems encountered by the team as caused by not following "a proper process".

The challenge with our world view is that it is strongly related to our world model (which is why in English, that would be the same term): what we see depends on what we can see. As long as our model does not permit us to process a different perception, our view will be limited to perceptions consistent with our model.

Genuine change, then, requires us to at least permit the possibility that our model is incomplete or even "wrong".


As the German word "perception" is also rendered, "taking as true", we can only take as true that which makes a true claim within our world model - i.e., only that which is both consistent with what we already call "true" and also within a spectrum of what we can classify to be "true".
Problems arise when we have already accepted false claims as "true" - we will discard or re-classify perceptions that are actually based on relevant impressions.

To take this out of the abstract realm, as long as we swallow the idea wholesale that "order is good, chaos is bad", we will never be able to appreciate the shaping and creating power of change - because change means that we change away from that which we consider "ordered" into something that, based on our current understanding, might be "chaos". Specifically, a self-organized team may not have a spokesperson or team leader at all. Such a team appears "totally chaotic" from the perspective of a manager who is used to corresponding only with team leads - and it will be very challenging to accept such a team as mature.

As long as we rely on an immutable world model, it's really difficult to see the benefits of conditions that don't git our model. Our perception of things that others consider "good" might be "bad", and we will classify situations accordingly.

World model

At the core of everything we see and do is our own world model. As hinted above, our world model has already decided whether any impression we receive is "true", "possibly true" or "false". Our world model helps us determine whether reality as we perceive it is "good" or "bad" and what we should then do.
The more static our world model is, the more binary this classification will be - and the simpler we will make decisions. Or, in other terms, "confidence" and "certainty" depend on a rather static world model, while ideas such as "doubt" or "hestitation" are related to a shifting or shaken world model.

Let's talk about me in this example: A few years ago, I was certain that clear process definitions would solve all business problems. Today, I stand on the perspective that clear process definitions in a changing world are the cause of all business problems - we need to be flexible to deal with situations that haven't happened before (and that may never happen again).


"Agility" might have to shake up our world model - as long as we're striving for certainty, we apply perception filters and biases that make situationally right choices invisible and lead us off-track. At the same time, the price of adjusting and softening up our world model may be high: we may need to admit that that which we fought for, sacrificed for, stood for, are no longer valid.

And that's the difficulty with agility: before we can get the benefits of being agile, we ourselves need to adjust our world model to be ready being agile.

Sunday, July 15, 2018

Agility isn't for everyone!

A lot of conflict in the workplace is caused by different expectations regarding the nature of the work. And agilists may not even be helping - they might just make it worse!
Here's why:

The Stacey Matrix - annotated with character traits.

Character traits per domain

Simple work gives confidence to people who excel at tasks that others may consider "chores". Although workplace automation has abolished a lot of simple work, there are still areas where well-defined, routine processes are commonplace. The most important characteristic to success in this domain is diligence - getting stuff done properly.

Complicated work rely on getting multiple pieces of work executed correctly and in proper sequence. This requires good coordination - putting multiple pieces of the puzzle together in the most effective way.

Complex work means that there is no one known best way of doing things, and there is no one specific goal to attain, either. Even though most of today's knowledge work occurs in this domain, people easily get irritated when they "just don't know" and still need to product results. The essential trait here is creativity - coming up with a solution in the face of the unknown.

Chaotic work occurs when there is no clear-cut way of doing things. Many people feel challenged working under such conditions, as the constant barrage of new information often invalidates former achievements. Resilience and a high amount of flexibility helps - changing direction whenever it makes sense!

The problem with "Projects"

The complex and chaotic domain are the places where projects crumble: The base assumptions of the project fall apart as soon as people start doing work. The coordinative ability of the Project Manager are of little help when the tasks to coordinate aren't helping achieve meaningful goals. Likewise, the most diligent worker isn't helping the company when the work isn't even going in the right direction.

It's extremely difficult to run a development project with the premise that project management is merely the meta-task of coordinating development tasks, as nothing would need to be developed if everything was clear to begin with.

A lack of flexibility often causes projects to fail in a sense that the outcome isn't needed when the project is done.
Likewise, a lack of creativity often causes projects to turn Red - objectives can't be met by following the plan. In unfortunate cases, the only creativity on a project team might be the project manager's ability to find excuses for the poor outcome.

Unless projects have people who exhibit the flexibility to deal with new information - and the creativity to do without proper processes or still do something useful when goals become invalid - the project is in trouble.

The problem with "Agile"

"Agile" dogma often seems to presume that all work requires flexbility, and that all workers are flexible.
Both premises are invalid. Not only are flexible, creative workers a rarity rather than a commodity - working in this domain should be an exception rather than the norm.
Creativity is often needed to pull unknown stuff into an area where slices of known work can be coordinated and executed, but that work still needs to get done.
Highly flexible people often enjoy the streaks of chaos that allows them to innovate - and they may not enjoy the grind and routine of doing the base work.

In a healthy team, there has to be a place for people who are diligent, for those who are good at coordinating stuff, for those who are creative - and for those who enjoy the whimsiness of the Unknown. Put together, such a team can be extremely effective.


We need to respect that not everyone is creative and that some prefer routine - and we need to respect those who can't bear routine work and their drive for change. And we are well advised to neither compare nor mix up such work: it's just too different.

Try discovering where people see their favorite work and help them find their place accordingly.

Avoid creating a culture where people enjoying only one type of work feel left behind. It might create a dangerous monoculture!

Order vs. Chaos - a look at the science

Order creates a feeling of safety. Chaos, on the other hand, is a term with negative connotation.
But is order really what we want?

Using an analogy from material sciences, let's take a different look at the struggle of "order versus chaos".

Take a look at this model:

Order is the "frozen state" and Chaos is the "volatile state". I use this example on purpose: Kurt Lewin has proposed a 3-state change model, "Unfreeze-Change-Refreeze". It perfectly correlates to material sciences.

Lewin assumes that organizational structures and/or processes are best kept in a "frozen state". And in many organizations, that's true. Does it need to be true? Let's take a step by step look by examining the states first.

Different states

Frozen = Ordered

A frozen organization is ordered. It doesn't matter how effective or efficient the organization is - things are clear. Well, maybe not so much, but still. There are known structures to uphold, there are known people to address, there's a known protocol to follow and know processes to apply.
This makes things simple: If A, then B.
I go to work in the morning, know what I will be doing - and even when I take a week off, when I come back, I know the exact state where I will resume.

Terms used to describe a frozen state include: "predictable, reliable, convenient". All of these words are positively connotated both with workers and managers.

Hence, the desire to freeze the organizational system.

Along comes a troublemaker. A person who does things different. Who won't accept "That's how we always done it" for a reason. Who breaks rules to get stuff done. Who bypasses hierarchies getting in the way of success. Who messes with people following dysfunctional processes without further ado. Like - me.

In a frozen state, the organization will consider such a person a dangerous foreign body needing to be dealt with. A single person faced with frozen organizations will be forced into one of two choices: adapt - or get out. That's why change initiatives are well-nigh impossible without a strong guiding coalition as proposed by Kotter: It's not about doing things differently, it's about accumulating a critical mass of people with sufficient power to unfreeze the system before even bothering to really go on with the change agenda.

Liquid = Nonlinear

Getting out of a solid, frozen state in physics requires dissolving the bonds between system components. Depending on what you want to change, you may need to un-link structure, people and processes alike - simultaneously!

Dissolving links means that communication structures will no longer work as before, processes will no longer produce the same outcome - and results on any level may change. The bigger the incision, the more likely unpredicted side effects will occur.

People lose the feeling associated with an order state - predictablity wanes, reliability is reduced and people start experiencing the discomfort of needing to think and connecting dots differently. When essential, strong links haven't been dissolved, the system returns back to the former stable state as soon as possible and may even obtain resistance strategies - inoculation to ward off future change.

Going back to our physics analogy, we need to invest energy into an ordered system to unfreeze it. The amount of energy needed to make a permanent change in an ordered structure directly correlates with the strength of the links which need to be broken.

Let's take the example of water:
It takes a rather limited amount of energy to melt an ice cube.
With significantly more energy, we could split the molecular bonds and turn the ice cube into H2 and O2.
Should we desire to reform the very atomic bonds and turn the hydrogen atoms into helium, we need to invest a lot more energy into a much riskier and complicated process.

In either case, the former state will cease to exist - and that's where reactions such as fear, grief (Kübler-Ross) and entitlement come in.

Volatile = Chaotic

Volatile systems do not display the characteristics of an ordered system. The high energy inherent to each particle allows them to move rapidly - making it extremely difficult to predict the next state of even a single component in the system, much less enabling methodic control on the overall system.
In a chaotic state, change doesn't require an investment - it happens continuously and without trigger. Change isn't something that needs to be initiated, much rather, it would need to be channeled to produce something desirable.

In a volatile state, the system's drive to change is bigger than any component's capability to stabilize, hence no change is permanent.

A molecule in a gaseous state would not consider this state "anomalous" - much rather, it would need to be deprived of its energy before entering any other state.

And this is an important part of volatile systems - the components have high amounts of energy!

Like order is produced by draining energy from components, chaos is produced by energizing components.

State transitions

Material state transitions can be measured and predicted with high accuracy - something not quite as simple when dealing with an organizational system combined of a complex structure including many individual people, highly interrelated processes and potentially an innumerable amount of technological dependencies.

State transitions in a frozen organization are often considered undesirable, as people are afraid that something will get broken for good:

As the  "frozen" state of an organization becomes stronger, the more energy will be required to reach the "un-freeze" state which makes state transition possible. Combined with the complexity of the system, the amount of energy required for a successful defreeze might be roughly the same amount required to enter a volatile state - and depending on the size of the desired change, an excursion into a chaotic state may be required.

When being unfamiliar with the chaotic domain, there is both the danger that chaos gets out of hand or that when the system gets into a stable state again, that state is undesirable.

The false Order-Chaos dichotomy

Frozen systems are stable, but they aren't very malleable. The key characteristic of frozen systems is their lack of energy. An organization with stable structures that lack energy is in constant danger of being stuck in the wrong place - and won't be able to make the necessary move to remain sustainable.

On the other end of the spectrum, chaotic systems aren't stable - and equally un-malleable, albeit for a different reason. The key characteristic of volatile system is their high energy - and therefore, the impossibility to ever nail down anything.

It's not so easy to say whether order or chaos is better - that would depend on what you want to achieve. Based on the points above, we should realize that we're not forced to choose between order and chaos. The choice is a false dichotomy.
Just because water isn't ice, it doesn't mean that you'll die from steam burns.
It could equally be a refreshing glass of cool water or a warm cup ready to make some tea.

The idea "If it's not ordered, then it's chaos" is nothing more than a false dichotomy: There's a large spectrum of conditions between frozen and volatile - and while neither of the two extremes is specifically habitable, the range inbetween very well is.

Get used to change

When you look at a glass of water, you can't tell where every single molecule is. Even if you knew where it was five seconds ago, you can hardly tell where it will be in a few seconds. At the same time, you can tell a few things with fairly high confidence:

  • You're looking at a glass of water
  • The molecule in question is within that glass of water
  • That molecule will still be within that glass of water in a few seconds.

You can even make more reliable predictions:

  • If you throw a pebble into the glass, the water will (for the most) remain where it was.
  • The pebble will not significantly affect the way your water behaves.
  • When you take the pebble out, the water will look like it did before.
Interpreting the analogy, the liquid, non-linear state is both more flexible than the ordered and more reliable than the chaotic state. 

If you want to keep your organization robust to outside interference, you need to abolish the idea that everything needs to be in place: The ordered state can't deal with changing circumstances. 

In an ordered state, Lewin's "unfreeze-change-refreeze" process is essential to adapt.
In a non-linear state, there is nothing to unfreeze, and nothing in need of being re-frozen.

The practical interpretation

We talk a lot about "Agile Transformation", and in the minds of people this is unfreezing a non-agile organization, changing it towards an agile organization, then refreezing it in its agile state.
There is no such thing.

The agile organization is like water, constantly in a nonlinear state. Change in an agile organization isn't a project. Instead, everyone and everything within an agile organization is constantly subject to change.

Every person thinks about new, better ways to achieve things every day - every process can be scrutinized and modified at any time. When outward circumstances change, the agile organization doesn't start a massive adaption initiative, they just do what it takes to deal with the new circumstance.

And that's why you can't "buy agile" - to be agile, you must be in that liquid, transient state - at all times!

Thursday, July 5, 2018

"Googlewins Law" - The Google Argument

Maybe you've had an occasion with "The Google Argument" before. I call it "Googlewin's Law". What is it and how does it damage dialogue?

In homage to Godwin's Law, I call for "Googlewin's Law", and would phrase it like this:

"As a technical discussion grows longer, the probability of a comparison involving Google approaches 1"

I have observed an emerging trend that when meaningful arguments run low, someone "pulls a Google" (alternatively Linkedin, Amazon, Facebook) in an attempt to score an intended winning strike. However, most often, the invocation of Google is nothing more than a fallacy.
Here are the three most common uses of the Google Argument:

The positive Google Argument

When developers want to do something which could be called "nerdfest" and run out of meaningful arguments why doing this is a good idea, they invoke the positive Google argument:
"We could become the next Google with this". 
Typical invocations could be: "With this ranking algorithm, we could become the next Google!" - "With this sales platform, we could become the next Amazon!"

Here is why it's a fallacy:

Google never tried to become great, they tried to do something that happened to work, and because they did that exceedingly well, in all domains - from technical implementation over marketing and sales all the way to customer service - they succeeded. Oh, and they happened to have great seed funding.
Google did not become great because of one good technology, they became great because they happened to do a whole lot of other things right as well in a market where one stupid move can cost you everything.

So the next time someone pulls a positive Google on you, just ask: "What makes you so sure we don't become the next Blockbusters with that idea?"

The negative Google argument

The opposite of the positive Google argument, used as a killer argument against any form of innovation or change is the negative Google argument:

"We don't need this. We are not Google".
Typical invocations sound like: "Continuous Integration? We're not Google!" - "Microservices? We're not Google!" - "Virtual Machines? We're not Google!"

Here is why it's a fallacy:

Not everything Google does is only helpful for Google. Google is using a lot of techniques and technologies that help them achieve their mission and goals easier and more effectively.
Google has even created quite a number of useful tools, frameworks and techniques that are available open source (such as Angular) simply because they are useful.
If everything that made Google successful was anathema, you shouldn't even be using computers!

The appeal to Google

When lacking evidence or sound arguments, what's more convenient than invoking the name of a billion-dollar-company to make your case? Who could argue against an appeal to Google:

"Google also does this." - "Google invented this!"
Typical invocations would be: "Of course we need a distributed server farm. Just look at Google, they also do that!" - "Our product search page needs semantic interpretations. Google also does this!"

Here is why it's a fallacy:

First and foremost, unless you're in the business of selling advertisement space on one of the world's most frequented websites, chances are you're not going to make profit the way Google does.
Second, Google can afford a technology infrastructure that costs billions, because that's what generates revenue as well. There's an old latin proverb, "quod licet iove, non licet bove" (lit. "What is suitable for a God is not befitting an ox")
Third, Google has many billions of dollars to invest. It doesn't hurt Google to make sink $100m into a promising, yet ultimately unsuccessful innovation. I mean, yes it hurts, but it's not lethal. Can your business afford sinking $100m for zero returns? If so, you can appeal to Google, otherwise I'd be cautious.


The next time someone invokes Google, Facebook, Amazon, LinkedIn or even companies like Zappos, Spotify or whatever - think of Googlewin's Law.

What worked for others has no guarantee of working for you - and even though you are not them, not everything they do is bad (such as, for example, breathing!).
Google is not a reason either way.

Feel free to ask, "Can you rephrase that statement with a comprehensible reason that has a connection to our business?"