Saturday, August 31, 2019

Agile Academy - McKinsey, you get it all wrong!

In a recent Whitepaper (LINK), McKinsey publised an approach for "growing your own Agile Coaches", i.e. creating an "Agile Academy". While I  may even agree with the general idea and some major points and ideas proposed in the paper, it fosters and relies on a few massive misunderstandings that could plunge your company into disaster.



Executive Summary

With their whitepaper, McKinsey have proven that they themselves are indeed nowhere near what they claim that you need to become an agile organization - so don't take their advice, they've disqualified themselves!

Since the below article is quite extensive, let me provide an abridged version:
McKinsey demonstrated that they have a low understanding of what agility is, what agile coaches actually do, they argue fallaciously to suggest a solution to a problem that you don't even want to have: the need for masters-of-all-trades.
The suggested solution doesn't match the problem statement: They ignore the temporal dimension of the problem and move it into a different domain to make it look like it addresses the proposed challenge. The approach doesn't yield what they claim you need.

By following the McKinsey approach, you will end up with a lot of people with decent, but limited understanding who won't have what it takes to make a breakthrough change.


What McKinsey gets right

Some of the key points that they get right:

  • "Scaling Agile" isn't done by copy+paste. An Agile PMO isn't a solution, either - as agility and PMO are contrary approaches.
  • In a VUCA world, we must move away from consultants who "implement best practices". It's more sustainable to use coaching to help people learn and discover.
  • Without good coaches, your chances of becoming or sustaining an agile organization diminish rapidly.
  • Enterprise agility also requires taking care of processes anchored outside IT, such as budgets or performance reviews.
  • You can't ignore current reality - agility isn't a cloud castle.
You don't become a master by attending a course.
I also agree that a 2-days course doesn't make one a "Scrum Master", especially not an "Agile Coach" and that just the prospect of a higher paycheck inspires people without even the remotest form of qualification will appropriate these titles in their profile.
I'll even concede that people who have little to no understanding of agility will rewrite their CV's to make it look like that their project manager Command and Control role in a classic Waterfall project which gloriously went down the drain was actually an "Enterprise Transformation Agile Coaching" project - and that makes it incredibly difficult for classic HR mechanisms to filter out who is indeed a qualified coach.

Where things get fishy

There are many assumptions in the article that I'll just put into question, as they haven't been backed up.
McKinsey clings to a number of beliefs that are questionable and will not help your agile transition.
  • For what and how many "Agility Coaches" do you really need? Why even introduce yet another role instead of helping Scrum Masters learn to expand their horizon, when self-organized teams need a supportive environment, not even more complexity?
  • How can there be "a clear approach to enterprise agility" when the entire problem is that in the VUCA world, there is no One-Size-Fits-All solution - which is the reason why we need agility to begin with? And if so, how is this approach better than approaches like SAFe or LeSS, which have been around much longer and have been used in a broad spectrum of organizations?
  • Why do they believe that "the role of the Scrum Master is limited when it comes to scaling agile" when all they quote as reason for their beliefs are antipatterns on how not to be a proper Scrum Master? Isn't that like saying that you believe ships are unfeasible because you threw a rock into the river, and it sank?
  • Why define "the vision and scope of the agile transformation, informed by assessment of the organization today"? Is this how you do strategy? Wouldn't it make a lot more sense to define goals by where the organization needs to be than by where you currently stand?
  • How do you define an "Agile Blueprint" if the entire point of agility is that adaptability to circumstance isn't universal, a point they themselves made in the introductory section?
  • Why do they talk about "the agile operating model" rather than about being flexible, responding to change - which isn't a model, but an attitude and capability?
  • How can you change your reality by operating within current reality? Wouldn't establishing a new reality require going beyond current reality? And isn't "reality", as described in the article, merely a perspective held by people without agile experience?
  • If we realize that the problem of Enterprise Agility is that complex system change isn't molecular, but rather molar in nature - how can we succeed by focusing on subsystems within an otherwise static environment? 

Where it gets really problematic

The article creates a false dilemma and then so conveniently proclaims a solution, which isn't even one.
McKinsey sets up a false dilemma to sell their "solution".

Setting unrealistic expectations

A person who can do everything at mastery level won't be interested in a limited role.

The "Agility Coach" as defined in Exhibit 2 has a role complexity that shrinks the amount of people who could meet that responsibility to Zero.
Just ask yourself: How many people do you know in your organizations who have management skills, facilitation skills, developer skills, agile framework skills, technical skills, business skills - and the time to do all of this at a Mastery level? Each of those domains requires focus, otherwise mastery will wane rapidly. Top it off with that person also being creative, innovative thought leader, and you're looking for a Jack-of-all-trades, master-of-all.

Typically, a developer who learns management will lose their technical edge within a few years. The line manager who works strongly to coach and grow their people will not be spending time to learn facilitation techniques. The manager who moves in strategic management will have little time to work on empathy and listening skills, simply because their responsibilities lie elsewhere. The business expert will not be a technology expert - and vice versa. And finally, being innovative and a though leader doesn't combine well with being tied to a single organizational context.

Now imagine that you put up mastery in all of these areas as a mandatory requirement - and answer: Why should such a person work for your organization rather than start their own business?

Basic training

Even a 20 weeks curriculum won't remotely give a person the breadth and depth to be an "Enterprise Agile Coach".
Don't get me wrong. I love the idea of an "Agile Academy" and I have worked with organizations who have one. And I have worked with people who went through Agile Academy curriculums. They're great people to work with, as they do indeed both understand the basic tenets of agility and their specific role within the organization.
But a 12-20 week course (3-6 months, taken generously) in addition to the regular work isn't going to make the cut, either.
A Scrum Master training is just a starter, a teaser, a foretaste. It's nowhere enough to say one has mastered agility. A 12-20-week part-time academy is definitely one step further, but still a far shot from the experience and qualification that professional agile coaches bring.

I have stated in another article that the Scrum Master journey, if taken seriously, over the years, might take a person into the domains of technology, personal and team and systemic coaching, quality, process, general and strategic management, mathematics, psychology, sociology and philosophy. Just two days on each of these subjects, and we haven't covered any business domain yet. There is no way that even a 1-year part-time curriculum will give a person even a remotely viable understanding.

Moving the Goalposts

There is no single curriculum to do what McKinsey claims is required.

Participating in an "Agile Academy" program doesn't produce anything that even remotely resembles the Jack-of-All-Trades proposed by McKinsey's Exhibit 2. An academy program has to set a clear focus and may give teasers on fringe areas. The outcome of participating in an Agile Academy is not a technological mastermind who can innovate, coach teams and management, develop a strategy roadmap and lead enterprises to success. It's simply people who are decently equipped to meet a specific function within an enterprise,
There would be different programs for people who would:
  • support one or multiple agile teams ("Scrum Masters"),
  • professionally coach individuals ("Coaches"), 
  • organize and facilitate larger events ("Facilitators"),
  • train organizational units who are yet unfamiliar with agile approaches ("Trainers"),
  • accompany agile organizational units with methodology advice ("Consultants"),
  • take care of the transition itself ("Organizational Change Managers"),
  • lead program and product development from a business perspective ("Product Owners"),
  • create and innovate ("Developers" / "Designers"),
  • fill day-to-day coordination roles ("Managers"),
  • have people responsibility ("Leaders").
And this isn't even talking about the domain of technical mastery yet, where a decent training program outdates before it's completed.

If we would - for argument's sake - say that a person goes through all of the domains listed above, then each domain gets like a day or two: does that qualify for "mastery"? How much trust would you place in a Change Manager who has taken a single course? Would you put anyone on your Board of Directors whose management experience is limited to one day of training and a week of practice?

While it's indeed possible that one individual goes through a series of such academy programs, and while indeed many of us senior agile practitioners on the free market have enhanced capability in multiple of these domains, let's be blunt: You can't have a Master-of-All.
Finally, a person who ran through ten quarter-year programs to gain "mastery" has been in education for a minimum of two and a half years - and that's definitely not something that you will have at the start of a transition.


Limited quality

Part-time focus isn't the same as full-time focus
There's a reason why world thought leaders like Marshall Goldsmith don't excel in all of the domains proposed by McKinsey. To be the best in your field still requires full-time dedication and serious effort. Nobody becomes a thought leader by spending a couple weeks in a training academy. The best people coaches aren't software developers, the best software developers aren't people coaches. Taking the "T-Shape model" - people who have a broad insight into many domains lack depth in at least one of them, worst case - in all.

I like to use the circle illustration. A person has 100% of their time, and it doesn't matter whether we're talking about lifetime, work time or agile coaching time. Let's just talk about 100% of their time. What would you want them to invest this time into - you can choose anything.
You will realize that as you put the items into the circle, each additional item decreases the proportional share available for all the remaining ones. An increase in focus on agility automatically decreases the focus on everything else - and putting four items in there ("Self mastery", "coaching", "agile mastery", "commercial acumen") would mean that at least one gets neglected unless the person spends no more than a quarter of their time on each of these domains.
You will not become a "Master" by spending 25% as much time on a domain as a full-time dedicated expert would - and definitely not a "thought leader!"



McKinsey started with the broad claim that they have a clear solution to the self-created dilemma of finding people who have a large list of qualities, but the solution is setting up a pool of people who, if following their proposed suggestion, will not have any of the qualities on the level they insist are required!

Ignoring the setup

Agility is based on empiricism. You have to start by inspecting and adapting, not by setting up an academy.
Starting your own, internal "Agile Academy" isn't done overnight. To create curriculums that match your need, address your challenges and have a sufficiently high quality of materials is a high-effort process and relies on having the expertise to begin with. This is essential to keep agility flourishing over the years, but if this is your first step, you're not going anywhere in the next couple of years.

As agility is based on empiricism, you need people who can bring both the theoretical and practical experience of empirical ways of working into the organization. These are the people who typically get hired as "Agile Coaches". There is no way to eliminate this step, and you can't copy+paste another organization's curriculum to circumvene it.

You have to run agile development within your organization to learn what works - and what doesn't. After you did this, you can roll this out in whatever way you choose - for example, by seeding multiple teams, pulling in additional units, doing a strategic rollout, setting up an academy or whatever (I have opinions on these approaches, but that would be too big for this article). But the first step of bringing in seasoned practitioners who can shine some light into how agility practically works within your specific organization is inevitable.


The big lie about agile practitioners


"outsourcing these key roles will often lead to an influx of agility coaches who are disconnected from a company’s culture and want to dogmatically apply agile the way they know it rather than the way it needs to be molded to a particular organization" - McKinsey
Basing a core statement of the paper on a lie about agile coaches doesn't further your cause.

Let me call it for what it is: a lie, as if McKinsey had any experience in the field (which I will take for granted, otherwise the entire whitepaper is moot), they would know that the last attribute that can be used to describe proper agile coaches - is dogmatism.
I would therefore disagree with the sweeping statement that agile coaches who do not come from your specific organization are often dogmatic and will insist on pushing their pet framework rather than understanding and working with your current reality.

The first big part of the lie is that a person who pushes a specific agenda isn't a coach to begin with
The second part of the lie is that anyone who has experience with agile enterprises will know that enterprise transition is a long, strenuous process that requires deep understanding of systemic interactions, specific attenuation and oftentimes, compromise

There's even a community of so-called "Agnostic Agile" practitioners, which I would highly recommend looking into, who reject framework dogmatism, because dogmatism isn't agile. 


Not addressing the real problem

If you don't know what qualified external people are, why would you do a better job in selecting internals?
McKinsey proclaims that companies often find themselves hiring external coaches who are, in short, utterly unqualified. I agree. This happens. Organizations who aren't agile often have trouble selecting for the right people and qualified agile coaches are not dime-a-dozen.
They then proceed on the very flawed assumption that organizations who find themselves incapable of identifying who the right externals are would do a significantly better job at identifying the right people internally.

What we see here is a classic bait-and-switch: "You have no way of figuring out who the right external coaches are" [Reason: You don't know what the right mindset is and your HR mechanisms often make it impossible to onboard the right people] "so just identify people internally and grow them" . This doesn't answer the question how to identify what this right mindset is that you couldn't identify when selecting for external agile coaches. It also doesn't answer how to fix the broken HR processes which prevented getting qualified people on board. And to draw a full circle, if you can't even spot the right mindset when recruiting - how are you supposed to teach it?

If you can't find the right people externally (where a few fairly talented people exist) - what makes you think you're better at doing it internally (where definitely nobody with all the requirements from Exhibit 2 exist)?



Closing Remarks

Every company has employee churn, just by statistics. Some people leave, others come in.
Everyone in the company should be familiar with the company's specific ways of working. Agile principles and practices should be understood by everyone.
An Agile Academy, which sets up both starter curriculums and ongoing education in which interested employees can choose to participate is a feasible way of achieving this. Formulating your own curriculums to bring people with overarching responsibility "into the know" is an effective way of moving forward.
I do indeed support agile academies as an ongoing mechanism of sustaining enterprise agility.

However
An agile academy is not strategically viable to start an agile transition - and it is not a replacement for onboarding external expertise in the early phases.
Finding the right external agile coaches in the beginning is essential to get your initial seeds of agility to flourish, and it's important to ensure the curriculums aren't imprinting the Peak of Ignorance as per Dunning-Kruger-Effect, because that would kill enterprise agility before it could ever start. By just following the ideas proposed in the initial whitepaper, this is exactly what would most likely happen.

Even when an "Agile Academy" is set up, there are a number of immense dangers:

  • Curriculums focus too much on specific methods and practices, thereby being limited in usefulness and outdating rapidly
  • Standardization" or "blueprinting" is anti-agile, any curriculum aiming in this direction doesn't go in the right direction
  • Forcing or coercing employees to participate in the Academy invalidates the entire idea
  • Senior managers and HR need to lead by example and go through the curriculums lest the Agile Academy becomes a mockery of itself.


Friday, August 30, 2019

What every Scrum Master needs to understand about Development

Not every Scrum Master is technical. Indeed, some of the best Scrum Masters I know have a sociology or psychology focus - so it's all fair and square to say that they're don't know how to develop code. This may (or may not) pose a problem depending on how advanced the team's engineering practices are: you can't get the team to deliver sustainable value when they don't know how to do that.

At a minimum, the Scrum Master should to realize whether the team is aware of what they're doing - and if they aren't, bring in a technical coach or senior developer who can teach the team the ropes. There are many nuances, and a non-technical person will not see everything. Once developers are on the right track, they can very well figure out where they need further help.


tl;dr: of all the categories below:
Absence of the practice causes delay, incurs cost, reduces stakeholder satisfaction and may kill the product (and in smaller organizations, the business!)

Here's what to look out for:

Automation

Phrased positively: If we do indeed automate everything that can be automated, we gain a much better understanding of what's actually needed to get something to work. Automated activity also frees developer's heads for doing new work rather than repeat activity. Everything automated can be tested, so we can test not only the software but also the meta-processes, bringing quality to another level. We create repeatability, reliability and confidence in the processes.
Plus, we eventually save time.

Dead giveaway? Team members have paper (or electronic) documents for standard activities they do all day.

Constant Refactoring

Refactoring should be a day-to-day activity as part of regular work. Every line of code should be refactored as soon as it becomes necessary.
Deferring refactoring will eventually put product development to a screeching halt, which can be fatal for smaller companies. I have seen products die entirely because one day, developers discovered that new features couldn't be integrated any more without breaking something else.

Dead giveaway? Developers complaining about code quality.

Unit Testing

Over the months/years, code will become more and more difficult to maintain unless there's a decent amount of unit tests. The time it takes to make even minor changes will explode in the absence of good unit tests: What might take seconds with unit test coverage could take weeks in untested code.

Dead giveaway? The "tests" folder in the repository doesn't get updates with every new version.

Continuous Integration

Problems in the codebase are often not visible until the latest version of the build (which must be subject to automated tests) has been validated. In highly complex environments, changes to one part of the code base may break other code, which will become visible only when those pieces play together. The risk of this happening increases with every change made. As developers do multiple things sequentially, the effort of locating the root cause of an issue becomes increasingly difficult to uncover with passing time, and every change ("fix") to an unstable codebase will amplify the problem.

Dead giveaway? Developers call things "Done", and there's no Working Build for it yet.

Code Smells

You don't need to be a developer to discover "code smells" which will eventually become a problem.

 Some of the most obvious code smells are:
  • "Mountain Ranges": The code, rotated 90 degrees left, looks a whole lot like a mountain range. Such code is too complex to be feasibly testable
  • "Copy+Paste": Code that looks eerily similar multiple times over or developers who outright say that they develop by copy+pasting existing code segments, then modifying them, produce code that eventually becomes unsustainable.
  • "The Gigabyte Class": A class that is unusually large will eventually become a problem. As a rule of thumb, a class with more than 5000 Lines of Code is probably fishy. YMMV.
  • "Treasure Hunt": When you see developers moving across myriads of classes all the time to understand what's going on, there's probably a code structure issue.

There's tons more of code smells, but these are the most common to see when developers don't know how to create Clean Code.

Dead giveaway? Developers don't understand code produced by other team members.


Tuesday, August 27, 2019

All Unknowns aren't equal

The Stacey Matrix has invited many agile teams to use the term, "Unknown" as a reason for using an "Agile Approach", i.e. winging it and finding out what's happening.
In some cases, that's the most economical or even the only option. But Unknown isn't unknown, and it makes sense to classify the term a little bit further.




The types of Unknown

Folly

Some things are just common knowledge. For example, everyone who has a smartphone knows that you need a secure password for everything that's on the Internet. To claim that "we didn't know that 'root' doesn't make a good root password for our web server." is just plain foolish. It's not Unknown, and there is no sensible reason to treat it as one.

Unqualified

If you work in a field, for example, software development, a few things can be assumed as standard knowledge. It doesn't take much except reading a few blog articles, a beginner's book or attending a really basic class to know these things. People who don't put the effort to know the very basics of what they're dealing with are sloppy and therefore unqualified. Absence of basic knowledge means you hired the wrong people, not that people should learn by trial and error.

Silly Excuses

Things wouldn't be common knowledge unless they were understood by a majority of the population. Claiming that it's not possible to research what happens when you disconnect a router is just a silly excuse. These also don't qualify as Unknowns for anyone who intends to keep their job - as a company that accepts such unknowns is very unlikely to survive for long.

Knowledge gaps

As soon as we get to field specific knowledge, not everyone can know everything. For example, you might have hired a music PhD for your development team who contributes a lot when it comes to synergizing ideas - but they may be unaware of how to write proper tests. That's an acceptable Unknown, which can be readily covered with available information. Throw in a bit of practice and you're set.
These Unknowns are fairly predictable and can be planned quite well.

Unfeasible

You may encounter areas where nobody on your team has any knowledge, and only a few people on the planet know what they're talking about. Maybe the thing you need to know hasn't even been explored yet or it's just uneconomical to acquire enough information upfront.

Such Unknowns are quite typical when doing innovation work, and are often hard to plan, as nobody knows exactly what the result will be and which steps will lead there.
This is the domain of experimentation, adaptation, trial and error.

Unknowable

The most difficult realm for prediction is knowledge which can't possibly exist, such as information about the future. While we can either research or explore by trial and error how customers use our product, we have no way of knowing whether a policy change in a country somewhere half across the globe will plunge our business into an economic crisis tomorrow.

The Unknowable warrants an entirely different approach. Usually, deliberately ignoring unknowable circumstances until they occur is the best strategy (as trying to know the Unknowable can consume an infinite amount of energy with no return on invest). When something Unknowable pops up, we need to deal with it - and that's being agile.


Dealing with Unknowns

If your development team claims that something is Unknown, first classify why the thing is unknown.
  • Folly, unqualified action and silly excuses should not be tolerated. If it's a people thing, address the behaviour openly.
  • Knowledge gaps should be brought up as early as they become known, so they can be filled effectively.
  • In software development, - acquiring all the knowledge is unfeasible: either too complex, too slow or too expensive. "Experiment, Inspect and Adapt" is the most economical, pro-active strategy.
  • Everything related to the future is unknowable. Accept it. The further you look into the future, the larger the Unknowable becomes. The impact of the Unknowable on your work determines how flexible you'll need to be. 
A plan far into the future should be very crude  ("a roadmap") lest it breaks when all the Unknowns unravel: The further you plan into the future, the more unfeasible knowledge becomes part of the plan and the larger the big ugly blob of the Unknowable becomes.

Sunday, August 25, 2019

The SMF Guide: The world's simplest Agile Framework

Let me introduce to you to an agile framework that's much easier to learn, has a much lower hurdle of adoption, and much higher chances of actually making a impact than Scrum. It's leaner and more flexible and if you start using it today, you'll see results right away!

SMF: The Sense-Making-Framework


By doing this relentlessly and rigorously, you can make things work!

Sense-making theory

Every day, we do a whole lot of things of which we don't understand why, or we even know that the outcome is not optimal. That doesn't make any sense. When we realize that something doesn't make any sense, why do we continue doing it?  And still, that's one of the biggest scourges of companies worldwide: people do things that don't make any sense, and nobody questions this.
The SMF is intended to stop this nonsense.

People act in the most sensible way, given the information they have and the circumstances they are in. When people have the right information and communicate properly, they can quickly realize whether something makes sense. The minute you realize something doesn't make sense, talk with those around you and if others agree that it's nonsense, don't do it.

Sense-Making is incredibly easy to understand, yet incredibly difficult to master. Even with this simple five-step process, it can take years of practice, superhuman patience and strong perseverance to create an environment where everything makes sense.

Making Sense

Sense-Making is concerned with different categories of sense, fully well realizing that this is both a spectrum and shifts over time, both as the system changes and as you gain more understanding of what is going on.

Good Sense

When something makes good sense, just keep doing it. You may occasionally want to reflect whether something else makes more sense, but that's probably not your main problem - so direct your attention elsewhere.

Common Sense

When something contradicts common sense, discuss why this is so.
Be aware that common sense can lead us awry, because it depends on our biases and the culture we're exposed to. When you spot contradictions between what would make the most sense and what common sense dictates, you may want to discuss why this is so.

Nonsense

There's outright nonsense, where everyone knows that this is nonsense, yet you keep seeing and/or doing it. Just stop it and see what happens. Then, replace it with something that does make sense.

No sense

"No sense" is different from "nonsense": there's an information and/or understanding gap and you don't know how and/or why would make sense. This requires further transparency and communication before classifying whether it makes good sense or is nonsense.
When you can't collect information that would help make further classification possible, stop doing things that make no sense and figure out what happens: If nothing happens, it made no sense to do it. If something happens, you have further transparency.




Sense-Making mechanisms

There are a few key mechanisms in making sense. There are no roles, artifacts or special events to sense-making, as that doesn't make any sense. Just do what makes sense.

Communication

When you don't know if something makes sense or are certain that something else makes more sense, communicate. Your environment is usually more complex than you understand, so openly involving others is key to making choices that make sense.

Stopping things

Stop doing whatever is nonsense, and stop doing things that make no sense.
When trying to do something that makes more sense, don't just add it on top, you also need to stop doing the thing you currently do so that you make more sense instead.

Experimentation

When you think something makes more sense than what you do, experiment - try it, and see what happens. Then, you have information to see whether it makes sense. In some cases, you learn that things made more sense before the experiment, and you may want to go back.

Implementing Sense-Making

If you have the courage to start making sense in your organization, start with this simple process:
  1. Get together and ask yourself, "What's the biggest nonsense we're currently doing?"
  2. Stop the nonsense.
  3. Try out something that makes more sense.
  4. Communicate the outcome.
  5. Repeat at infinitum.



Friday, August 9, 2019

The problem with Agile Transformation Programs

Many organizations want to "become Agile", then browse through the catalog of common frameworks, pick their favorite - and run a Transformation Program. While all of these are officially communicated as a massive success, I'd like to cast a bit of light on what is actually going on.



Transformation Input

There are some "givens" that affect a framework-based Agile Transformation program before it has even been conceptualized: expectations, reality and the determined future state as described by the framework.
These are the constraints to the success of the transformation, and depending on how well they overlap, this success can be bigger or smaller. Worst case, this intersect is empty from the beginning - in which case, the transformation program is doomed.

Management Expectation

Typical management expectations from an Agile Transformation include, without being limited to:
  • Faster time-to-market
  • Lower development costs
  • Higher Quality (fewer defects)
  • Improved customer satisfaction
  • Happier employees
The choice of framework often falls to that which promises most of these benefits.
"Good" transformation programs then set targets based on improvment seen on these metrics. 

Unfortunately, to scope a proper project and/or program, the real work is oftentimes measures in amount of departments/projects/employees using the chosen Agile Framework "successfully" (whatever that means).

Real Problems

Usually less visible to management is the entire quagmire of problems the organization has accumulated over the years. Benefits are generated by getting rid of problems, they don't appear from thin air.
The more problems are known and the greater the pain to solve them, the easier it will be to actually get benefits out of a transformation. 

Cultures averse to admitting or taking responsibility of problems will be struggling to gain actual benefits from any "Transformation Program", regardless of whether it's agile or not.

Framework Scope

Frameworks themselves have a very clear scope, mostly concerned with structure - roles and process, events and some artifacts. We can easily determine how much of this structure has been implemented, and that's how success is often measured.

What's significantly more challenging: determining how compatible people's mindset and behaviour is with the intent of the framework, and how significantly the "new ways of working" get impacted by "old ways of thinking and doing".



Transformation Output

To keep this article simple, let's not argue about how well any of the inputs was understood or change was actually realized, and keep to reality - "we are where we are, and we go where we go."
This reality is:
  • some expectations will be met, others don't.
  • some aspects of the framework will be implemented perfectly, other won't.
  • some problems will be solved, others won't.
Another reality is that at the point in time when the program is conceptualized:
  • some expectations are based on known problems, others on unknown problems.
  • some expectations are based on understanding the framework correctly, others on understanding them incorrectly.
  • some program activity will be planned to do things that solve meaningful problems, others will focus on something that's not a root cause.
  • some framework components will lead to beneficial change, others won't.
... and we can't know which is which, until we have done some experimentation. 
For argument's sake, let's just assume that the program is sufficiently flexible to allow such experiments, and that everyone contributes to the best of their understanding and ability.

Programs are still time-bound, and it doesn't matter whether that timespan in 1 month or 5 years. Within this period, a finite amount of activity will happen, and this activity will lead us to wherever it does, and "not everything" will be perfect. And this is what the future reality will look like:

Outright failure

Some aspects of transformation will lead to success, others will fail to provide success - or even distract from success. Let's call things by their name: When you scope a transformation program and don't get something you planned to get, that's failure.

In this section, I want to highlight the failures your program will have.

Unmet expectations

There will be a number of management expectations that haven't been met (blue area outside intersects). Some may have been unrealistic from the outset, others "could have ... should have". Regardless, someone will be disappointed. Managers familiar with diplomacy and negotiation will stomach the ordeal, knowing they got something at least.

Just be careful that the higher your expectations are and the less aligned they are with the framework's actual capability, your organizational reality and the flexibility of the transformation program, the bigger the disappointment will be.

Wasted Investment

Frameworks are frameworks, and when shown an overview of everything that the framework has to offer, managers often decide that "we need all of that". Truth be told, you don't, because a lot of it provides a solution to problems you don't have (yellow area outside intersects). But you can't know what you need until you are in a situation where you do need it.

By deciding upfront to go full-scale into implementing everything a framework has to offer, you're going to load a massive amount of waste into your transformation program - and this waste costs time, money and opportunity.

Unsolved problems

Many of the problems in your organization won't get addressed at all (red area outside intersects) - because they're unkown, too complicated to resolve or simply not relevant enough.

The intent of an agile framework isn't to solve your problems, but to provide you the means of solving them - you still need the heart, the will and the power to actually do this. 
Great transformations focus on tackling meaningful problems, thereby showing by action that resolution is possible and valuable - bad transformations avoid the mess of problem solving and focus on just covering the existing heap of problems under the blanket of a framework.

Unresolved pain points

Managers would prefer to have the perfect organization where everything is smooth and problems don't exist. But we don't live in cockaigne (purple intersect between blue and red on the left), and "Agile" won't create one, either. Problems are still real - and frameworks don't address them directly, they just provide means for addressing them.

The list of pain points is (near) endless, and seems to grow with increasing transparency. and we only have a finite amount of time. There will be un-addressed pain points. Even if the Agile Framework is perfectly implemented, many of the pain points will remain - most likely, more than imagined.

When a transformation program scopes more framework implementation than problem solving, don't be amazed if the outcome is more structural change than solved problems!



Partial Benefits

Transformation programs can and do provide benefits, in different categories:
What you see and feel, what you see but can't feel, what you feel but don't see - and what you neither see nor feel, although the latter is a difficult topic in and of itself.

Illusory benefits

Informed managers will expect the transformation program to implement certain framework elements that will indeed be implemented (full intersect between blue and yellow circle). This is great when these elements actually solve a problem the organization has - but there's no guarantee (greenish intersect between blue and yellow on the right). 
Oftentimes, we create "change for change sake" without getting any better results, because we changed something that's not a problem.
In some cases, the new status quo is even worse than the former state, but it looks better ... because it's new, and compatible with the Agile Framework.

These benefits are not real, they have cost money and kept people from doing the right thing!

Let me warn you right here: Unethical coaches/consultants will focus their efforts on the illusory benefits, to build management rapport and milk the cash cow as long as possible. 
AVOID generating benefits in this category!

Hidden benefits

The framework may actually solve some problems that management isn't even aware of (orange intersect between red and yellow on the bottom), either because the benefits take a long time to become visible or because they do not affect anything of management relevance.

A typical example is the implementation of XP engineering practices - it may actually look like teams are getting slower when they write unit tests and create deployment automation, but the benefits will become visible in the future, as defect rates and stress levels decline. Example: Developers who have worked on Clean Code microservices with Continuous Deployment never want to go back to legacy processes or code, because it's so much easier and faster to work this way - but getting there could take years (and possibly be entirely unfeasible) on legacy systems.

Let me dive in with another note of caution: Ethical coaches/consultants will focus their efforts on solving real problems, many of which managers don't see. Managers must be curious to learn from their teams whether such hidden benefits are being generated, or whether the consultant is just trying to please management.



The success story

Every organization that has invested lots of effort and money on an agile transformation program will eventually produce a success story (brown intersect area of all circles in the center) based on what management expected, how the organization actually beneftted and how the Agile Framework has brought them there.

People are smart enough to not reveal publicly how many of their initial expectations weren't met, how much activity didn't lead the organization in a better direction and how big their problems still are. But depending on how well the Agile Transformation Program was defined and executed, this could easily be some 90% (or more) of the program.

Simply put, it's insane to start an Agile Transformation Program because you read someone else's success story, because the story doesn't tell you what went wrong, how much disappointment and frustration has accrued, how much time and money was wasted - and oftentimes, you don't even see the pointers of what actually made it a success.

Real success happens where the three items intersect, and the size of this intersect is determined by:
  • How well do you focus on solving real problems?
  • How flexible are your expectations?
  • Are you using frameworks where they benefit, rather than making your organization framework-compliant?



Summary

An agile framework transformation program, conceptualized, planned and executed by people who do not exhibit an agile mindset and who do not practice agile organizational development - is going to produce a politically motivated, insignificant success story. 

Stop thinking frameworks, stop thinking programs.
Start thinking agile, and embark the agile journey in an agile way.








Wednesday, August 7, 2019

Five Principles of Organizational Agility

Do we need frameworks to be agile or not? 
Maybe. If we have a problem that frameworks solve. And if they are an appropriate solution.
Here are my five principles for change, which are paramount to the question of frameworks.




If you adhere to these five principles, my question would be: "What do you expect from an organizational framework?"

1 - Frame your problem properly

Learn to understand your problem before implementing a solution.
A poorly framed problem's solution may be worse than the current state.

Go beyond both the symptom and the Obvious and frame the problem correctly. And when you learn that you framed the problem in the wrong way, refine your problem statement rather than "working harder" to make the solution work.

There are great tools, like Ishikawa Diagrams, 5-Why-Analysis and many others which can assist you in getting closer to what your real problem is, in a very short time.

2 - Limit change

Only reduce the bottleneck constraint that causes the problem.
Large-scale changes will have uncontrollable, large-scale impact.

Figure out what the bottleneck is, why things aren't moving smoother.
When you know where the bottleneck is, be uncompromizing on making a change. By accepting the bottleneck and making a change elsewhere, you destroy the change process overall.

Tools like Process Mapping, Flow Diagrams, Lead Time Analysis and many others that will help you discover the single point where a change will be effective.

3 - Simplify change

Do the simplest possible thing to reduce constraints on the current bottleneck.
Change should be so simple that it's effortless - if our idea doesn't work, we just try the next one until we find something that does work, and that's a lot easier when we make small, simple changes rather than implementing grandiose master plans.

Simplicity is an art - "anyone can make things complicated, it takes a genius to come up with something simple". When geniuses are hard to come by, it helps to involve the people who actually face the problem, as they often have a pretty good idea why something doesn't work, and they may just need the permission to do the right thing instead.


4 - Subtract before you add

Eliminate structures, processes or tools that cause problems.
The "simplest possible thing" we can do is usually getting rid of a blockage, not adding something.
Problems don't get solved by adding something on top.

Additions to an existing problem are like band-aids on a cracked pavement: They won't really help, won't last and won't make much of a difference. The existing problem needs to be addressed and removed. Often, this is already enough.

I like to use tools like Marshall Goldsmith's "Wheel of Change" to model the change, and tend to remind people that "For each thing you add, you have to remove one thing", because otherwise we create more problems (oftentimes elsewhere) instead of solving them.

5 - Verify outcomes

Verify your outcomes before calling something a success.
Change is successful when the problem is gone.

Many organizations call change successful when the change is implemented - which often leads to "change for the sake of change", and people getting rewarded for doing things that don't help the company.

We can use methods like OKR to define which outcome we want to see, and if we didn't achieve this outcome, that should at least trigger the question of what the change has done instead.



Closing remarks
These five principles stand together and should be applied together.

A well-defined problem allows us to run a minimal change experiment in the right place, which allows us to verify fast and cheaply whether we're making an impact. And we need to get rid of at least one root cause of the problem to make such an impact.

Monday, August 5, 2019

Sustainability - not just for software

The eight principle of the Manifesto for Agile Software Development encourages sustainability - working in a way that we could "maintain a constant pace indefinitely". Although this blog post is generally about agility, I want to take a detour here: What we do with our planet is definitely not sustainable. We can't continue at this pace for long!


I am currently visiting Ha Long Bay, one of the most beautiful places on earth - if you haven't been here, you will surely enjoy the trip.


The boat tour through the islands is exciting - this is just one of the beautiful tropical islands you can look at. Some can even be explored:
A beautiful tropical island - in danger!

Okay, enough advertising. The beauty of this paradise is already fading - because of things happening somewhere else on this planet: And you and me have a share in this.

The pictures I took from this place look very similar to the picture people a generation ago would have taken - except for one small, almost invisible thing. Almost!

Let me zoom in on this shoreline for you:
The light freckles in the water - everything plastic garbage!

What you see floating in the water here is plastic garbage, brought here from all across the globe: be it America, Europe - or wherever.

The cost of our action reaches far across the globe and into the future.

Every coffee we might enjoy on our way to the office, every instant meal we consume, every snack we grab at the corner of a street, even groceries wrapped in disposable plastic. They all contribute to the problem.

The consequences of our choices are so distant and elusive that we fail to remember that they exist. Our actions create a problem somewhere else on the world, and we do have a responsibility both towards the environment we live in, the people elsewhere who have to put up with the trash we create for them to deal with, and towards our children who may never know the beauty that had been there just a single generation ago.

Here is the suggestion - it's not new, but still a good reminder:

  • Think twice before using disposables. 
  • Use paper or jute bags instead of plastic bags. 
  • Use paper cups instead of plastic cups.
  • Leave that plastic straw where it is - drink from the cup! 
  • If you're in a position of making or calling for choices what your company should use, opt for bio-degradable (e.g., paper, wood) or reusable material.
  • Make your office kitchen and your homes plastic-free.
The bag hanging in that tree - it could be yours!


We can easily work and live at a much more sustainable pace, even without sacrificing comfort.
It just requires some thought.

Let's live at a sustainable pace!

Wednesday, July 31, 2019

Sorry, Agilists - your frameworks are a problem!

It’s 2019, a full generation since the Manifesto for Agile Software Development was compiled - and although “Agile” has become the norm, the Agile Community isn’t really going anywhere: What we see is a horde of trainers and consultants (nowadays called “coaches”) claiming that they have already found this “better way” - which can make us wonder: are the agile frameworks really better, and: compared to what? 



This article is a provocation. When I address “You”, that’s an oversimplification which does not apply to everyone in the agile community, and I am aware that there are indeed a few (unfortunately rare) exceptions that this article doesn’t address. As the old joke goes, “It’s 99.9% of lawyers that give the rest a bad name.” Is the Agile community any different? Should you think that any of my provocations below are made from ignorance or that the claims I have blatantly put in “Your” mouth are indeed true, you’re exacerbating the problem!

I won’t discriminate between the different frameworks out there and simply refer to “Your Agile Framework”. Feel free to insert your favorite flavour - my claims don’t change. The intent of this article is to highlight principles and not specifics of any one framework, otherwise this would be a book rather than a blog post. I have caught some assertions about your Agile Framework and propose a plausible counter hypothesis for each. Think about it!


1 - Your Agile Framework is missing the point

There’s so much more to running a successful business than your Agile Framework accounts for. Your Agile Framework doesn’t change anything in the big picture. Indeed, with increasing popularity, your Agile Framework is becoming a bigger problem!
You’re talking a lot about systems thinking, yet fail to realize that introducing a point-based structural change like your Agile Framework is ineffective. Systems thinking goes much further than structure and process!
Without a deep understanding of complex adaptive systems, you are of no help.

Your Agile Framework is not reliable.

You claim: “The utility of the Agile Framework is proven daily.”

People implement your Agile Framework perfectly and see no difference. Many use your Agile Framework exactly as it is described - and fail!
People who know what they’re doing and not using your Agile Framework will do better than those who don’t know what they’re doing and using your Agile Framework.

You selectively cherry-pick the few cases where people happened to both know what they’re doing and used your Agile Framework, then claim that this is proof that your Agile Framework is useful. This is just a placebo effect.


Your Agile Framework doesn’t lead to success.

You claim: “If you use the Agile Framework correctly, you will succeed” - and: “In all cases where people didn’t succeed, they didn’t use the Agile Framework correctly.”

Smart people working on great products fail miserably while using your Agile Framework exactly as intended. Even if you yourself succeeded repeatedly with your Agile Framework, your next endeavour could be your worst failure ever - and there’s nothing your Agile Framework will change about it!

Your Agile Framework doesn’t even contribute to success.

You claim: “The Agile Framework is being used for all kinds of work on all kinds of products and in all kinds of industries.”

Sorry, this has to be: “Blue shirts are being used for all kinds of work on all kinds of products and in all kinds of industries.” - what a heap of baloney!
There is no causal link between using your Agile Framework and success in any kind of work, in no industry. There’s not even a hint of a correlation. Any suggestion to the contrary relies on wishful thinking and confirmation bias.

Your Agile Framework might improve nothing.

You claim: “People who use the Agile Framework are more likely to succeed.”

Your Agile Framework is not better than what organizations that relentlessly Inspect and Adapt are already doing. While your Agile Framework may be a way to frame your problems differently, if you have no idea how to solve them, you will remain stuck. And if you don’t know how to structure your problems, your Agile Framework won’t even help there!

Your Agile Framework doesn’t deliver more value.

You claim: “The Agile Framework increases the value delivered.”

Any halfway decent Product Manager doesn’t need your Agile Framework to deliver maximum value. If organizations have no competent product management, your Agile Framework doesn’t help, either. What your Agile Framework has to say about determining Value is infantile, ignorant of the vast bodies of knowledge about value determination that are already available.

Your Agile Framework won’t make anything faster.

You claim: “The Agile Framework speeds up the delivery of value.”

It’s possible to streamline delivery without using your Agile Framework, and even people using your Agile Framework as prescribed may have horrible Time-to-Market. Your Agile Framework doesn’t replace a thorough Lead Time Analysis with consequential removal of inventory waste. An organization that has already optimized their delivery process will not become any faster by adopting your Agile Framework.

Your Agile Framework doesn’t increase customer satisfaction.

You claim: “The Agile Framework improves customer satisfaction.”

The standards defined in your Agile Framework you might actually cause a decrease in customer interactions in highly customer-centric environments. Are you even aware that your Agile Framework was explicitly designed to shield developers from customers? Your Agile Framework provides a mantle that can be used to reduce customer transparency and decrease the customer’s trust in your development.

Your Agile Framework itself isn't agile.

You claim: “The Agile Framework enhances the team’s flexibility”

Your Agile Framework relies on dogmatic rules that can’t be bent or violated. You will even go as far as claiming that breaking these rules is the cause for failure, when breaking these rules may indeed be maximizing the odds of succeeding. Those who understand the rules of your Agile Framework don’t need them - and vice versa. Your framework does very little to remedy this situation, so a vast majority of people use your Agile Framework without understanding what they’re even doing.

Your Agile Framework doesn’t reduce IT cost.

You claim: “The Agile Framework reduces costs.”

Unless you plan on firing people, IT cost will not go down. In all likelihood, your Agile Framework will require a significantly increased IT budget!
A developer’s paycheck won’t magically decrease by using your Agile Framework.
Servers and infrastructure cost also won’t go down because of your Agile Framework, either. As agile ways of working spread, additional hardware - and therefore, additional cost, becomes inevitable.
And if there’s no bucket for coaching or training, your Agile Framework will fail.

Your Agile Framework isn’t worth investing into.

You claim: “The Agile Framework investment will pay for itself.”

There are better ways to invest the money than into your Agile Framework. You may say that the investment into training or consulting services will be a positive business case, but wouldn’t be willing to operate on a profit share model. You well know that you’d work for free if you got paid according to the tangible benefits generated by your Agile Framework.

2 - Your Agile Framework is a threat!

The Manifesto for Agile Software Development was written by people who were seeking for “better ways” for software development, yet what people have turned it into is a cultic religion that spreads like rabies across the world. It benefits a select few on top of the food chain, while exploiting and victimizing hordes of noble truth seekers who aren’t in it for the money, but for a better world.
Your Agile Framework damages individuals, endangering organizations and impedes the progress of society!

Your Agile Framework exploits a predicament.

You claim: “The Agile Framework should be introduced enterprise-wide.”

The importance of software in business increases daily. Managers who find themselves missing a way to reliably succeed in this domain will grasp for straws. In their ignorance, they turn to anyone who promises to increase their odds of succeeding. Just like the quacks who sell miracle pills to make a quick buck out of other people’s predicament, you market your Agile Framework as though it solved this problem. Once the special effects show is over, the client lost precious time and money to the quack, while the real problem never got addressed.
Such exploitation is banned in socially advanced societies, because it replaces choices from free will with the imposition of severe harm.

Your Agile Framework equivocates software development and business development.

You claim: “The Agile Framework enables Business Agility.”

Your Agile Framework doesn’t even address any business challenges in a meaningful way. You don’t even realize that your Agile Framework wasn’t designed in an attempt to address business challenges - it was designed to help people develop software better. In management, the idea of “agile enterprise” has an entirely different meaning than in IT, and you play on this equivocation fallacy to increase the audience for your Agile Framework. Assuming that your Agile Framework can be equally used in areas it was never meant for is horrible advice.

Your Agile Framework is a strategic nightmare.

You claim: “The Agile Framework keeps all the work in a prioritized backlog”

Your Agile Framework operates with a myopic and limited understanding of importance. Urgency trumps foresight. Your Agile Framework's focus on short-term product value in the next Increment undermines and damages strategic enterprise development. Your ignorance in dealing with market forces pushes your product - and your company - to the verge of extinction.

Your Agile Framework breeds mediocrity.

You claim: “The Agile Framework treats everyone equal”

Progress isn’t made by making everyone equal - it’s made by bringing forth the talent in bright people. Your Agile Frameworks’ promotion of collaboration has turned into a disdain for individualism. “Swarm Intelligence” is just a euphemism for “groupthink” - where radical, innovative ideas have no place and “vastly different” is considered a threat, not an opportunity.
What really brought society forward were always the people who just didn’t fit in. Outsiders like Alan Turing would have no place in the society you promote. Your Agile Framework would have lost the British World War II - aren’t we glad they didn’t know about it yet?

Your Agile Framework impedes learning.

You claim: “The Agile Framework broadens horizons.”

Your Agile Framework is limiting your horizon. It ignores a vast ocean of available knowledge. You are happy to float in your little bubble where the easy answer for every question is, “You have to find out”, although the research has already been done outside your bubble. Hence, you’re going around in circles, re-inventing the wheel. That’s also why you turn people into celebrities who have just “discovered” things that people outside your Agile Framework Community have already understood, published and applied decades ago.

Your Agile Framework Community is an Echo Chamber.

You claim: “We have a vast community for learning from others.”

You have chosen to put yourself into an echo chamber where you constantly get bombarded with reaffirming messages. You enjoy hearing yet another person affirming what you already know. You limit your professional interactions to supporters of your Agile Framework. People who disagree with your perspective are no longer welcome. You stigmatize and label dissent as “unenlightened” and use terms like, “not teachable” or “not coachable” and attribute this to an “unwillingness to learn”.
You can’t entertaining the thought that you could be wrong, and that makes you totalitarian!

Your Agile Framework exploits problems without fixing them.

You claim: “Certified Practitioners are an advantage for companies”

Hordes of Agile Framework certification holders suggest to companies that the certificates are important. Companies can’t discern whether people who hold that certificate know what they’re talking about. Certificate holders think they know what they’re talking about, although many of them will cause more harm than help. And uncertified practitioners, although highly adept, are coerced to waste time and money on a meaningless certificate to avoid being sorted out by automatic filters.

Your Agile Framework operates on a ponzi scheme.

You claim: “The Agile Framework creates a better world.”

Your Agile Framework exhibits all the signs of a ponzi scheme with an immutable hierarchy that has only one purpose: provide easy money and reputation to those at the top.
You have the founders, you have the trainers, you have a mass of certified people - and uncertified practitioners. Everyone is welcome to become a paying member, but only those who will help those already in the scheme earn more money are welcome to rise in rank. FOMO (Fear Of Missing Out) keeps people paying those subscription fees, although the vast majority of certified people gain no benefit in return. And no, a monthly newsletter doesn’t count - their work, life or understanding doesn’t improve.

Your Agile Framework blocks actual progress.

You claim: “The Agile Framework dissolves hierarchies.”

If you want to make progress in the hierarchy of your Agile Framework, you’d better be a sycophant who praises every word of those whose approval is required for promotion. You won’t make progress by innovating or trying to improve things. It’s not desired, because it would reveal the incompetence of those above you. Improvements must always come from the top. And the longer your Agile Framework hierarchy is established, the less significant the changes within your Agile Framework become. Do you really believe that you have already reached the peak of human potential?




3 - You can’t refute my claims

Agilists don’t seem to get that there is, at best, very weak evidence for their claims. There is no sound chain of reasoning to bring us from what you believe to what is actually happening.
I can hear you crying foul now, because there’s a plethora of success stories, many even written by organizations and/or individuals that adopted your Agile Framework. All of this is fallacious.

Your Agile Framework hurls us back to the Middle Ages

In the Middle Ages, life worked like this: You tried something, and if you observe something even remotely related to a positive result, you could claim that the action caused the effect.
For example, some wise person might claim that by following a certain medical treatment, we can cure some sickness. Since my neighbor did it and got better, I would accept that treatment as the cure. Today, we call this “confirmation bias”, and have long since rejected the notion.

Your Agile Framework hurls us right back to the Middle Ages: People claim that by observing the rules of your Agile Framework strictly, key strategic problems would get solved. And since it allegedly worked for the neighbor, the framework must be the cure. Is that even possible, though?

What brought us out of the Middle Ages is science: the relentless, scrupulous attempt to make sense of the world around us. Science relies on testable, verifiable, evidence. We replace fallacious post hoc, ergo propter hoc reasoning and cognitive biaseses with traceable chains of evidence.

Rational people reject claims contradicted by evidence and have no reason to accept claims without supporting evidence. And your Agile Framework doesn’t meet this standard. It would be irrational to accept your claims.

You don’t have evidence to support your Agile Framework!

Agilists don’t even bother to ponder what constitutes proper evidence. You bask in ignorance and rely on peer pressure to silence dissent. You make bold faced assertions, regurgitate mined quotes, appeal to authorities and spice it up with flawed anecdotes or analogies and think you made your point.
If our legal system would accept such “proof”, you could get convicted of a felony you never committed - fortunately, it doesn’t!

You don’t even use correct syllogisms!

While you see that “When it rains, the street gets wet. The street is wet, therefore it rained” is fallacious, you’re incapable of comprehending why “Performance improved after using our Agile Framework, therefore our Agile Framework improved performance” is a fallacy. And if anyone still doubts, you’ll just follow up with a classic argument from ignorance, "What else should have caused it?" - which isn’t helping your case, either.
You don't know how to make your point with appropriate syllogisms.

You don’t understand how evidence works!

You think that “Company X used this Agile Framework, and Company X is successful” is evidence for the benefits of your Agile Framework, yet you dismiss the idea that “Company Y used the same Agile Framework, Company Y failed miserably” could be evidence that the Agile Framework doesn’t deliver.  “5 is odd, and 5 is a prime number” is not evidence that odd numbers are prime numbers, and “9 is odd, and 9 is not a prime number” is fully sufficient evidence that the claim “odd numbers are prime numbers” is false. Is it a lack of intellectual capacity or integrity that you won’t accept this misuse of evidence?


Your reasoning is terrible!

You propose assertions that you expect others to accept, yet without proof. Indeed - you can’t even prove that the opposite isn’t true and ignore all the evidence pointing elsewhere. If your assertion were true, invalidating my proposed counter hypothesis should be child’s play. Until then, your assertions should be rejected. If you can’t invalidate any of my hypotheses, you’re holding a bottle of snake oil!

You use references that you don’t know!

Your argumentation is spiced up to the brim with fallacious appeals to authority. 

You do not know what Royce actually proposed when you refer to “Waterfall”, you have no idea what vision Taylor had for management. You refer to them in a condescending way,  when indeed they fought on the same side of the battle you claim to be fighting on!

Likewise, you quote Deming without ever having understood which Crisis we have to get out of, you quote Drucker without understanding the Organization of the Future, you quote Senge not even knowing the first four disciplines and you have no qualms to quote Taiichi Ohno without grasping even the main ideas of the Toyota System.


4 - Conclusion

This article is a bombardment of provocations, intended to strongly shake everything you might believe about agility.

I am challenging you for a thorough, profound rebuttal - a task that I believe very few would have the capacity for.

If you don't know how to refute my claims with sound reason and evidence, please go back and reconsider what you are doing.
You may be a part of the problem the Agile Industry is causing.


Tuesday, July 30, 2019

What's a Community of Practice?

Especially since SAFe is on the rise, companies are trying to establish "Communities of Practice" (CoP) and may not even be clear on what that is supposed to be. Some try to shoehorn their old line structure into CoPs, with meager results. Here are some comments from my own experience.


Defining a Community of Practice

A CoP is nothing more or less than a group of people with a shared purpose, as the Manifesto sfor Agile Software Development states, "uncovering better ways (...) by doing and helping others do it".
That means, communities typically consist of subject matter experts and/or those professing to become such.

Shared Purpose

Every Community needs a shared purpose, and that purpose can be whatever the community makes their purpose.
Very common types of communities I see in many organizations include:

  • Testing / Quality
  • Architecture
  • DevOps
  • Data Protection & Compliance
  • User Experience
... you get the gist.

Sometimes, communities form around very specific organizational issues, such as "Customer Complaints" or "Return Shipments" - such communities tend to have the purpose of bringing themselves out of existence. This already hints that a community may also consist of non-technical people as well: Communities are not limited by department boundaries.

Voluntary Participation

Communities live from their members' participation. The best communities consist entirely of members who desire to be part of the community and have a personal interest in making their participation as useful as possible.
With such voluntarism, both attendance and non-attendance in community events are an indicator of the community's success. 
Organizational mechanic (process, decree etc.) mandating community participation will cause results and progress of communities to dwindle.

Openness

Communities are most effective when they are open to people from "outside" to bring in additional helpful ideas and carry their own results for others' benefit as well. Growing communities that have an appeal to a large audience, even many who only participate occasionally, have the biggest impact.
On the other hand, closing the community to an "elite" will limit their learning, impact and organizational acceptance.

Organizational Integration

Communities are workfloor-level organizational constructs. They consist of people who practice (hence their name), they are for people who do the work and they serve no purpose other than making the work better. As such, they do not need to be "managed", "controlled" or "reported".

Accountability

A community is a peer group built on trust, respect and growth. The community as a whole is accountable to the organization in terms of their purpose. Members are accountable to their peers in terms of whatever they decide to commit to. And finally, as community members have a "home" in a team, they are also accountable to their team to use their community time wisely and in the best interests of the team.

Management

A community of experts might have a line manager (e.g., "Head of Quality"), who may or may not be involved in the activities of the community itself.
Here is some personal advice based on my experience with managers and CoPs:

  • the manager may encourage starting a CoP, but should not enlist one, and definitely not "manage" one.
  • the manager should not attend unless invited and only speak once they have clearly understood the impact of their words and actions on the group.
  • the manager can support their community by removing impediments that the community raised.

Reporting

Members who did do experiments may report their learnings back to the community in whatever form they consider appropriate.
The concept of traditional Reporting is out of place in communities. A community "reports" to nobody, as that destroys the entire point of being self-organised and brings in a lot of dangerous power dynamics which could invalidate the entire idea of forming a community.

Team alignment

Members of communities should feel free to do any of the following, at any time, in alignment with their team:
  • Join one or more Communities
  • Invest time and effort into community activity
  • Discuss CoP topics with the team
  • Withdraw from a CoP
  • Participate as guest in other Communities
There is no obligation that every team must have one member in every community. Sometimes, half a team is already half the community - and often, many teams have no members in certain communities.

Leadership

Mature communities are peer groups that operate as a decentralized network. They do not rely on the concept of single person leadership, but rather on the concepts of personal responsibility and ownership.

Practice lead

Many Communities are led by a peer expert to keep the momentum up. Ideally, this is the person who cares most for making beneficial changes. The CoP lead is a "primus inter pares" who leads by competence and through action, not position.
As a note of caution: When "talkers, not doers" lead a Community, others' interest will wane quickly.

Coaching support

A coach can serve as facilitator to the help find out the current practices, discover levers for change, reach agreements on next steps and encouraging members to take action.
When a coach is required to keep the community alive - let it die!


Impermanence

The existence of communities should be linked to their importance. A community trying to improve the organization's biggest problem may need to be quite active, investing a significant portion of their time to make progress. When a community has no significant purpose, community activity is waste. 

Organizational Freedom

The organization should support their members to form communities at any point in time when people feel that they have an important purpose, and likewise encourage people to abandon the community when the purpose is longer important.
The organization itself should foster no form of "attachment" to specific communities.

Friday, July 19, 2019

How Agilists betray the very nature of Agility


Almost two decades ago, a handful of people started a joint journey of "uncovering better ways of developing software and helping others do it". The first value was "People and Interactions over Processes and tools". 
Scrum emphasizes the values of Openness and Respect. Coaches are expected to both exhibit and nurture a Growth Mindset.

And what to we do? The opposite!


Trigger Alert - this post will push a lot of hot buttons!


What have we become?

A large number of agilists get triggered really fast, really strong and really bad as soon as they read or hear certain terms. Why have the very people who proudly bear the labels of openness and respect, become so narrow-minded and show almost hostile reactions as soon as a few trigger words are uttered?

People who even dare to use certain words get stigmatized as "unenlightened" and "anti-agile" and are being told to "defend themselves" or apologize. This is neither open nor respectful towards the individual, much less towards their ideas.  Is this the type of interaction with people that agilists looking for?

When have we stopped thinking or asking, "What does the other person mean?" Why do agilists go into full confrontation mode as soon as these words are uttered? How is that behaviour different from a fascist regime where everyone who thinks different must either be converted or eliminated?

Creating taboos and instituting thought crimes fosters an environment where true agility becomes impossible


Trigger, trigger, trigger ...

It can be that you had bad experiences a hundred times and think you understand the antipatterns, but isn't it exactly what agile practitioners are trying to teach organizations - that past experiences  are not necessarily indicative of what is the most appropriate thing to do in the current situation?

Each person has their own understanding of reality, which is why communication is needed to collaborate better. Presumption doesn't get us anywhere. How about listening, before arguing? Why is it so hard to keep those guns down until the other person made their point? 

Now, let's see how much I can trigger you ...


Agile Project

Where do we start with an agile transformation? Let's start an Agile Project!
Ohh, I hear you shouting immediately, "There's no such thing as Agile Projects! You must do Product Development!" - can you even smell how dogmatic and close-minded this is? You're not inviting a discussion, you're ending it!

When an organization is operating in project mode, you must start somewhere, and starting with a single, decoupled project is significantly easier than starting by changing the entire organization's structure, management and process landscape. Starting with a single Agile Project allows you to separate concerns.


Fixed Scope

We need to fix the scope for our Agile Project.
Your answer is clear: "We're Agile! That's Big Upfront Design, Waterfall!" Proposing to make the scope known upfront is met with arrogance and disdain. You wouldn't even bother to ask,  "what do you mean by fixed scope", because fixed scope indicates that this person just doesn't get it.

Have you ever considered that self-organization happens within a context, and clear boundaries help teams to reach excellence?
Fixed scope doesn't mean writing a Detailed Specification Document. A team's scope is already fixed when the team is supposed to build spacecraft and not washing machines. Scope can be re-negotiated when it becomes a blocker, but operating within a fixed boundary enables teams to focus ... do you remember someplace where focus was acually considered a virtue? What do you focus on, when everything goes?


Milestone Date

Investors want to know when they can see something and want a roadmap with milestone dates. They expect a Return on Invest at some point. Within a corporation, senior management acts as an investor.
I know that you're going ballistic, "We can't know what or when!" - calling the request unreasonable and insisting on a free pass for the team. 
Oddly enough, I have never seen any agilist who would invest their own money into a business unwilling to commit to results, dates or ROI - everyone buys stock from companies that announce fiscal targets and product release dates ahead of time. Where does that hypocrisy come from?

Investors pay all the bills, including the team's salary. The answer, "We do frequent Reviews" is not helpful without a specific date when it's possible to make a decision on whether to pull the plug or to proceed.
Running this decision multiple times per month would put a tremendous amount of stress on the team and promote unsustainable behaviours. Quarterly milestones give the team sufficient room to breathe and allow the business to make wise investment decisions. 
After all, the business also wants to be agile - being able to spend the money on the most important initiatives, and not just let your team locally optimize what they build!


Product Roadmap

Our stakeholders want to know our product roadmap - what they can expect in the next year or two.
A roadmap instills confidence that you know what you're doing and aren't getting tossed about by every wind.
 "That's not Agile", I hear you scream!
We have a product vision and a product backlog. Some items in the backlog are keys to business growth, others are just work. Take the keys and arrange them on a probable timeline. There is your roadmap: Was that so hard?
Being agile doesn't mean you stop caring about where you're going- it means that you're ready to change direction as needed. And guess what - nobody cares whether or how often a roadmap changes, as long as the current version makes sense and points towards valuable goals!


Progress Report

The next "Agile Antipattern" is the Progress Report. "We have Reviews, and thus, progress reports are a waste". The mere suggestion of a progress report obviously means that the individual doesn't understand agility and the organization wants to preserve status quo.

While we can simply assert that it would be best for the team to operate in a vacuum  - they don't. They operate within a context, and that context won't magically go away just because we wish it were so.

An agile progress report generates transparency where teams face systemic impediments and where they are calling for help. An agile progress report allows senior managers to pull levers that teams currently can't pull.

Senior managers are third-row stakeholders for your team who are hardly involved. Their skin isn't within the game, but they can  initiate change, and when they're responsible for dozens of teams, they can't give half an hour to each, every week - because as unthinkable as it sounds, they also do things that have nothing to do with the team's problems.

Can you respect the responsibilities senior managers have and that they are trying to use their own time as effectively as possible?


Returning to Reason

You may still disagree with the explanations I have given, but hopefully you have realized, "Yes, there's some reason behind this, and the person isn't actually so insane that they need to be lobotomized on the spot."

Speaking about our perspective opens the door to a conversation. Reasonable people are willing and able to listen to reasonable arguments. Blame and accusation aren't reasonable. Attacking the individual who speaks their mind and tries to learn closes your own door towards learning and growth and betrays the idea behind agility.


A wise person once said, "We are all where we are. 
A 3-year-old lives the life of a 3-year-old, an 18-year-old that of an 18-year old, and an 80-year-old that of an 80-year old.
We can not expect the 3-year-old to live the life of an 18-year-old with the wisdom of an 80-year-old.
When we look at a 3-year-old, we should enjoy that they can live the life of a 3-year-old. They will be 18 in fifteen years, so give them time.
Can we have this kind of respect towards people who are not where we deem ourselves to be?