Chronicle of an Agile-Transformation Death Foretold

Based on real life experiences.
Although the names and events in this story are not real, they are based on numerous agile transformations I have encountered. Followed by a remedy – lightweight, simple to understand and difficult to master – just like Scrum.

The hype at the beginning of the agile transformation at Iguazu Mobile Technologies was inspiring. The HR business partner of Mobile Search, the department to pioneer agility at IGT was fully on board, helping with copywriting of cool slogans and treats and fun games at the office space.

Willy, the general manager of the group was very crisp on his message at the All-Hands meeting: “We are embarking on a journey to replace the operating system at IGT, and we are the pioneers of this transformation. We have set goals to improve quality, as measured by fewer bugs and dramatic improvement in automation. Reduction of Time To Market as measured by  under three months releases. We also have a goal of happier people, as measured by honest smiles as we get to work all through going back home”. Willy had that magnetic style that kept everyone engaged and hardly no cynicism was noticed in the room.

Freddy, the chief transformation officer was smiling with everyone, and enjoying the gourmet snacks. But as people emptied the hall, a few wrinkles returned to his forehead. “Look Willy, your talk was awesome, and I enjoyed how you honestly conveyed your view that we will all make mistakes – and correct them. The thing I am still uncomfortable with is our approach to the stabilization period at the end of each release. I fear teams will revert to our old Waterfall ways when most of the work is testing and bug-crunching. We should be explicit on the notion that stabilization is in the same rhythm as any other Scrum sprint”.

“Relax, Freddy, enjoy the beer. This is a day of celebration, not concerns”.

The weeks flew by, and most teams were becoming increasingly happy. The Scrum Masters have set up a Smart-Up – their own brand of a SM community of practice. Two of teams were struggling, and IGT sadly had to part with a few highly experienced engineers, who didn’t fit into the new model.

Towards the designated release date even the two struggling teams began to show signs of improved satisfaction, and, shortly after, their throughput began to modestly increase.

Freddy scheduled a meeting with Willy. Scheduling such meetings was regularly a challenge, and this meeting was no exception.

“What are the current plans for releasing the new version?” Freddy asked after the initial small talk.“We’re not aiming for a 3 months release. We just have too little scope delivered, and we promised much more. We will release in 3 months when the teams finish our Search Reinvented initiative”.

Freddy could feel the rug pulled from under his legs. He knew from the burn-down charts that there is hardly any chance of delivering the entire Search Reinvented in 3 months. He also kept communicating to Willy and his staff that this is hardly likely to happen, and that it’s better to release a smaller version to start getting feedback from early adapters. He also knew that the most prominent Scrum Masters kept delivering this message to Willy’s staff.

“In our last staff meeting we raised concerns that the stabilization period will be too long for such a small scope, and prefer to do it once and good rather than repeat the same mistakes twice”.

Freddy pulled all the agile coaching rabbits from his hat, but he knew this was a losing battle. In 3 months the release will still not be ready, there will be many more features, and more integration and scale issues will get uncovered. Stabilization will be long and teammates motivation will get impaired. 

Four months down the line Willy held an All-Hands meeting, declaring that they will release the two mega-features that are ready for Mobile Search. There will be a single stabilization sprint, after which they will release. The other Work-In-Progress features will be halted, and they will commence a new version for Mobile Dreamweaver.

Freddy was aghast. It didn’t happen to him often, but after all the talk and all the promises and all the tons of empirical data screaming in the face of Willy and his staff, he was damn right disappointed. He could see all this coming from miles away, but in real-time this event overwhelmed him.

Of course, stabilization sprint turned into two, then two into three. At the fourth stabilization sprint some compromises were made on priority of bugs. Out of the window goes quality, together with 3 months release. Needless to say that both quality and time to market lagged behind motivation, which flew out of the window and hit the ground at hyper-terminal speed.

By that time, most teams held some kind of disheartened daily meetings. Half the teams didn’t retrospect once through stabilization period. By stabilization sprint 4 none of the teams held a planning event, and none held any review event.

The Sprint Review Bazaar that everyone raved on early in the transformation seemed like a distant dream from another era.

As the new release commenced, Willy held another All-Hands to kick off the new Mobile Dreamweaver version.

Sprints came back to life, planning events, refinement meetings, Scrum Boards in the rooms. But the spark has gone off the transformation. It’s as if a zombie colony was practicing Scrum.

Agile transformation at Iguazu Mobile Technologies was, by now, dead.

Do yourselves a kind favor – don’t do stabilization sprints. If you must (because you have some sort of an UnDone Department to handle before release), treat them at the same vigilance as any other sprint – Planning Part I+II, Refinement, Sprint Review events, team and overall retrospectives – the works.

We’ve seen that Stabilization Spiral Downfall movie before, and it does not have a heroic Hollywood ending.

Webinar: Stop this Scaling Nonsense / Get Rid of Scrum Masters

Video recording of a webinar, covering two topics:

  • Stop all this scaling agile nonsense and start descaling, by Elad Sofer
    Learn the chain of events that leads an organization, that often starts very lean and agile, into a big, hairy and complex unproductive machine.
  • Get Rid of Scrum Masters, by Ilan Kirschenbaum
    Scrum Master is one of the least understood concepts of Scrum. It’s not a manager, not a team lead, so what is it? If the role is so enigmatic, why keep it?
    Learn what is this role anyway, and what makes it so important.

Recorded on May 28th, 2018

Ten Ways Surgeons and Software Developers Should Be Alike

When I was a child I had an operation on my shoulder. It was a scheduled operation, nothing urgent. And it left me with an ugly scar on my back. Today, it’s still very notable after all those years. Also still painful during season changes.

Roll the clock forward some 40 years, my youngest son had an operation right after birth. He was in a critical condition, and, in order to save his life, the main artery and vein in his neck were bypassed to connect him to an infant life support machine (ECMO). Despite the urgency and complexity, his scar is hardly noticeable. Despite his slim chances of survival, doctors treated him in both operations – connecting and disconnecting from ECMO – such that everything, cosmetic side effects included, will be as professional as they possibly can.

What makes the difference between a top notch surgical unit to a mediocre to a poor one?
What makes the difference between a top notch software team to a mediocre to a poor one?

The books “Better” and “The Checklist Manifesto” by Atul Gawande give us a peek into the characteristics that differentiate a mediocre surgeon practice from a better-and-always-improving one.

The resemblance between a medical team and a software team is so strikingly similar, that I collected ten practices from the Operation Room (OR) that software teams would be wise to adopt.

 No. Operating Room Surgical Unit Software Team
1 If it’s a new OR team (as is many times the case), the teammates introduce one another by name, profession and role in the OR A great software team invests time and effort to improve their teamwork skills. They practice to become better in working with one another: socially, professionally, procedurally, whatever-ally.
2 The team is a cross-functional and feature team: It hosts a surgeon, sometimes more than one, nurses, an anesthetist – all skills and professions to successfully complete the operation A great software team can deliver a feature end to end – from the moment the first test is envisioned, until the feature is successfully deployed. They host programmers of multiple technologies as required, test experts as required, UX experts as required, and so on.
3 The team hosts attending physicians – who completed a specific specialty, residents – graduates who are acquiring a specific specialty, and interns – graduates of medical school who are not yet licensed to practice independently A great software team invests time and effort to improve knowledge and skill sharing among its members. At any point, a master of one skill will guide a journey-person to improve their craft, who will, in turn, guide a novice of that practice. They will increase their Bus Factor in each and every required skill.
4 Before an operation, the OR team prepares itself: what is the required procedure, where is the initial incision, what is the current condition of the patient, known allergies and other relevant information A great software team defines the desired outcome of a feature they are working on. Typically they practice Acceptance Criteria to specify the successful end result. They plan their work frequently and in reaction to unfolding reality.

The specifications they produce are automated so their equipment (test frameworks) will become greener as they progress in the feature development.

5 Before an operation, the OR is prepared: sterilized, required tools prepared and organized, emergency equipment checked and ready, and so on. Before starting to work on an feature, a great software team create a “sterile” work environment: The CI is clear of any red tests, the IDE is clean of old items, required tools for the feature are ready (e.g JMeter, DB profiler, …), the desks are tidy, and so on.
6 Before an operation, the team prepares for typical complications: how many sponges to prepare, how many blood transfusions to order, what extra equipment should be available and ready. Before starting to work on a feature, a great software team specifies and automates negative and edge-case tests to verify that unintended side effects do not occur – or are immediately fixed.
7 During the operation, the circulating nurse is acting outside the sterile area: getting additional equipment ready, answering the phone, calling in additional experts in unexpected situations, updating the family A great software team designates a teammate to attend to all interruptions and escalations while they are working on a feature: pushing back on non urgent interruptions, answering questions that don’t require interrupting the rest of the team, fixing the CI/CD if broken (or calling an expert in), and so on.

Note that this “circulating programmer” is not synonymous with the Scrum Master. It can be a SM’s job, but not necessarily.

8 During the operation, the patient’s vital signs are continually monitored, using visual and auditory queues. If something happens, the team reacts immediately. The team automatically runs all the relevant tests – unit, integration, functional, business-flow, deployment and migration – to validate that they didn’t unintentionally deteriorate other parts of their product. They immediately react and either fix such mishaps or roll their changes back. Tests are run as frequently as possible, implying that tests runtime is fast.

They use modern tools to identify which tests should be run, and they improve their test creation skills, so their CI/CD cycle is as short as necessary and not more.

9 Before finishing, a nurse counts all sponges, surgical tools and so on, to make sure nothing is left inside the patient’s body. Before marking a feature as Done, a great team goes back to the Definition of Done, and validates that they didn’t skip anything that must be completed. Done really means Done for the team.

A great team grows their DoD with time, so they get better at remembering and actioning the important things to check.

10 Professional practitioners of the OR – surgeons, nurses, anesthetist – regularly attend continuing professional development to further their knowledge and skills  A great team dedicates time for professional development, both individually and as a team, on multifaceted range of topics: programming, testing, team development, DevOps, architecture, retrospection, leadership – whatever helps them improve their outcomes and well being.

Ultimately, both OR teams and software teams want to improve the lives and experiences of their clients. I am reminded of a story by Bruce Irvine, following an organizational analysis at a large UK hospital. A team of consultants interviewed 100s of staff at the hospital, and asked about their job. Only one person said something that relates to the primary task of the hospital. It was the cleaning lady, who said: “I am cleaning so patients feel better”.

Not all surgeons and surgical clinics are great, in the same way that not all software developers and software development teams are great.
The important questions to answer are ones that drive teams to greatness. With that in mind, what questions are you asking in your team/s?

What do you do in your own team/s today that makes you a great team?
What would you improve to become one?
What would you add to the list to help other teams become great?

Add your questions and comments in the discussion below.

Image source: https://pixabay.com/en/doctor-physician-surgery-operation-79603/

Bugs as a Metric

bu

We have a bug in our industry: We over glorify bugs. We love them so much, that we use them as a primary metric for quality.
My take is that that is a bad idea. Bad, as in driving undesired behaviors that are misaligned with our desires to improve quality.

Let’s begin with an analogy, and then move to modeling this on software.

A tale of two restaurants

Joe was hungry. He was on a business trip, and it was lunchtime, and he just entered Bologna, an Italian restaurant.
It took almost 3 minutes before a host led him to a table, which was set up simply, yet invitingly. There were some loud voices from the kitchen, and Joe wondered what they are arguing about. When the waitress came back he ordered a pizza, which he noticed was recommended in reviews on TripAdvisor. While he was waiting for his order, he saw the staff going around customers – acting nice, but not overly nice, smiling from time to time, but not overly eager.
Then the pizza landed on his table. It smelled just gorgeous, and tasted even better. The pizza base was perfect, rich in flavor, as if the flour was different from any other he tasted. And the topping – was amazing. It was dead simple – generous slices of mozzarella cheese over a delightfully delicate tomato sauce, and topped by fresh arugula leaves. That pizza reminded him of some long-ago childhood memory that he couldn’t put his finger on, and he wished that pizza will never finish.
As he walked out he noticed that paint was pilling off the door frame, and a couple of tarnished floor tiles.
He was feeling happy, and ready for the rest of his working day.The next day Joe decided try Pizza World down the road from Bologna, which was also recommended on Tripadvisor.He was greeted with a big smile by the host, who immediately showed him to his table, and left an open menu for him to browse. He decided to order a mozzarella pizza, following yesterday’s success. As soon as he put the menu back on the table, a waiter came over, smiling friendlily, and took his order. While he was waiting he couldn’t help noticing the speckless while-tiled walls, and shining counters and the squeaky-clean glass-wall looking over the preparation area in the kitchen.
Shortly after, the pizza arrived, making Joe almost drool with anticipation.
And the pizza was – oh, bland. Regular. Nothing out of the ordinary. Don’t get me wrong – it was made to perfection, just that it tasted good, and that’s it. No childhood memories, no superlatives to offer, no sense of revelation.
A week later his colleague texted him from the same town, asking for a recommendation for lunch. Guess which one Joe recommended?

Don’t get me wrong here – I am not saying – make bugs. Assign X% of your time for bug making, because your customers will love you for that. Of course not!
Still, the first restaurant is more “buggy”, and yet has a superior product compared to the second one. So using a zero-bugs as a metric means next to nothing. Having policies that help us avoid bugs is a healthier approach.

Why not use bugs as a metric?

Our obsession with bugs brings on some really cargo-cult behaviors with it. Instead, I propose to ignore metrics on bugs. Here’s why:

  1. “Life is what you focus on” (I didn’t find the origin of this quote). If we focus on happiness, we get increased happiness; if we focus on strength, we get more strength; if we focus on bugs, we get, well, more bugs!
  2. Let’s focus on what quality is, not what it is not:
    If quality is delivering on time, let’s focus on cycle times, to improve our predictability;
    If quality is happy customers, let’s focus on customer satisfaction, to improve our feedback from them;
    If quality is testing, let’s focus on testing metrics like coverage and testing feedback times and early impact of tests;
    If quality means good software, let’s focus on excellent engineering practices that make good software;
    You get the picture.
  3. Old habits die hard. And changing culture is even harder. Bug worship mentality has been around for many years, and it will take perseverance and intention and discipline to change ourselves and to influence others.
  4. Bugs are not all that bad. Software is a highly complex practice, and it only makes sense that we make mistakes now and then. It happens on roads, it happens on healthcare and there is no reason to think we can get rid of all bugs in software.
    Note, that the Bologna restaurant from the story above has no bugs on its core service – the food, but allows few bugs on the periphery. You must decide what is good enough in your context, and what you are happy not to fix.
  5. Having said that, bugs are not the problem. The real problem is what makes it easy to create new bugs.
    We are much better off creating the conditions in which it is harder to produce bugs, than investing in a detect-fix vicious cycle. The latter would be like blaming all road accidents on drivers. The former will be like investing more in safer roads and cars.
  6. Our worst sin is that the remedy is out there. The knowledge exists, yet many of us are inapt to practice it because we have the wrong assumptions and knowledge and experience.

Let’s stop talking about bugs as if we can make them go away for ever. We can’t. Instead, let’s turn our focus to finding what are the desirable outcomes in our specific context, and then choose the metrics for the specific point in time to get us just enough to be able to choose the next one. My hypothesis is that by measuring the right things in the right time, bugs will stop bothering us that much.

Why we created Practical Agile?

Our_Logo_T_Shaped_People

Our_Logo_T_Shaped_People

Get your paper tissues ready, as this is a love story. Maybe we should make a Hollywood movie of it someday. Well, jokes aside, it really is, albeit not in the romantic sense.

Elad, Lior and I set Practical Agile in 2012. To be precise, the day the company was minted was the day of the first Agile Practitioners conference, and the two organizations go hand in hand. One is a commercial organization, the other non-profit.
But I am ahead of myself. A little bit of background first.

The three of us, Elad, Lior and I, had various experiences of working in organizations. By using two vignettes (Elad loves it when I use this word) I will divide these experiences into two major groups:

Software Development Awesomeness

It is spring of 1994, and the CEO of the company I worked for at the time came back from yet another trip abroad. Nothing exciting about that, yet. But then, a week and a bit later he got a call from the prospect: “remember you promised a week and a half ago that you can deliver our entire system in two weeks? Well, expect us at your office in 5 days time”. An hour and an urgent meeting later, Mr CEO explained what just happened, and what we need to show in just 5 days.

What happened next was one of the most memorable times of my career as a software expert. We worked 4 days straight. I saw the sunrise and the sunset at the office multiple times during that short period. We worked as a team, as if we were on rocket fuel. In less than 5 days, we managed to use the client’s manual regression testing document in order to understand how their system worked, get our system to behave as close as possible to theirs, and develop a PoC for a touch-screen restaurant point of sale, and develop a PoC for running our application on their old proprietary hardware. Of course, we won that deal, and, bar the proprietary hardware thing, the first two artifacts laid the basis for variants of our product that evolved over the next two decades.

Software Development Gloominess

It is now 2007, and I am a team member of software architects for a large software product. I am learning a new piece of software towards creating a high level architecture for an enhancement. To enable myself to learn, I want to install the existing system, or at least to get access to a working one I can play with. I consult my manager, my peers, other teams, and I feel that I am advancing in turtle steps. A handicap turtle, at that. Just to get a UNIX account or a DB account requires multiple signatures and asking people to do me favors, for something that seems so trivial to me. A couple of weeks later, I succumb to this reality. I ask for people to show me on some systems how things work today, and consult on how to make it work for the new features. I already gave up on a playground system of my own. Feedback is slow, as everyone is so busy with other stuff, which makes me busy figuring out how to make the next tiny incremental step, until I get enough clarity to define the next feature. For sure, everyone here has a brain the size of a watermelon or a pumpkin, everyone is really nice. But there is no flow, it’s like sitting in a still swamp, waiting for a current to take you away. But you just slowly drift away with everyone else.

Same person, two greatly different experiences. At the time, I didn’t have the tools and the knowledge how to explain them, and how to influence a change towards that Awesomeness. Then in 2007 I discovered Scrum and Agile, and gradually things started to make sense. I experimented a lot (and failed frequently) and gradually I gained the knowledge and experience to make software development what it should be: both productive and fun.

I first met Elad when we both worked for Retalix, many years ago. Then in 2010 I stumbled upon his name, and saw he was an Agile Coach, and I made contact. Elad introduced me to Lior, and we started to talk about an Agile community in Israel. A body of professionals who are enthusiastic about experiencing that kind of Awesomeness where they work. These talks let to talks about the Agile Practitioners conference, and, while working on the conference we found out that we make a great team, and that we would like to turn this into our day jobs. So we did. That’s how Practical Agile came to be.

It took us another two years to crystalize what get us ticking. But then, with the help of a talented business coach, Hagai Shalev, we succeeded in explaining this to ourselves:

“Practical Agile helps our clients develop products that customers love and employees love to develop.
We do this through Agility, excellence in process, engineering-practices and learning-culture.”

That is why we created Practical Agile. We know – from our experience – that making software should be fun. That it’s a team sport, in which everyone wins. That, just like sports, or playing music, it’s hard work to improve day after day, and that success is such great fun that it’s worth all the failures on the way to success.

Luckily for us, today we are surrounded by a team who shares the same notion (visit our homepage) – through experience and knowledge. We love our work, we love coming to work, and we love helping others fall in love with their work, bringing delight to their customers.

If you want to learn how to end gloominess and achieve awesomeness, or if you want to become even more awesome than you already are – talk to us. Our passion is to help people and organizations like you.

Process is always more important than content

We got this one wrong, us the IT people. We view process through a rather narrow prism, so much that we grew to value “Individuals and Interactions over Processes and Tools”. But process is way more than just a set of activities that get executed in a specific order.
Wikipedia alone has about 40 different disambiguation values when looking up “Process”. But the most concise definition is the following: “A process is a set of activities that interact to achieve a result”.

In many ways when we talk about a process we omit the latter part: “that interact to achieve a result”.

Start with basics

Take chemical processes, as an analogy. Say you want to make mayonnaise. You take an egg, oil, lemon, mustard, seasoning, and combine them in a very specific order. Should you change the order to activities, you might spoil the process, and get something, which might be tasty, but is ultimately not mayonnaise. That’s the set of activities involved in the process.

But the ingredients also interact to cause a certain set of chemical reactions. Without those interactions you will not have a mayonnaise, either. For example, if you used a boiled egg or a stale lemon, you are unlikely to achieve the desired result.
What more, if you get the ingredients and do -nothing-, other unplanned (and undesired) additional chemical processes will interact and prevent you from using those same ingredients for your desired gourmet mayonnaise. Your egg will go off, your lemon will become moldy, well, you get the point.

Content vs. Process

In the mayonnaise example, should you take a 3 months old egg, boiling oil, stale lemon and dried-up mustard, you are very unlikely to get any mayonnaise in the process. Most likely what you’ll get is hospitalized (if you’re lucky). The content was right. The set of activities was right. The conditions were wrong, hence the interactions were wrong too.
Time to bring this back to something resembling software.
Take 3 months old requirements, a group of demotivated individuals, a broken CI system and an angry customer, you are very unlikely to get high quality software in a few short iterations. No matter how good you’ve defined the set of activities to follow. No matter how successful other teams were with a similar set. The conditions are unsuitable, and hence, the interactions won’t yield the expected, or even a predictable, result.

Content

Content – these are the “ingredients” to generate outcomes. In a software organization these are: feature requests (aka backlog), definition of done, strategy and so on.
The quality of the content in itself is a result of a process – activities and interactions.
Healthy interactions with the customer lead to better feature requests.
Intentional interactions with the PO lead to better Definition of Done.
Frequent, intentional interactions between customer, leadership and teams lead to well communicated strategy.

You get the picture.

What you don’t see

“It ain’t what you know that gets you in trouble. It’s what you know for sure that just ain’t so”. Mark Twain.
Content theories are not unfamiliar in the human, interpersonal domain, too.
Take, for example, Theory X, Theory Y. According to Theory X, people always want to avoid effort, and do as little as needed. It is the responsibility of managers to make sure that employees do their work, otherwise, they will prefer to be lazy. According to theory Y, on the other hand, people are internally motivated, enjoy their work, and are the most valuable asset of the company. Manager’s role is to make sure that employees don’t lose their motivation, and to foster the conditions to enhance it.

Of course, both theories are wrong, according to the process view. Both Y people and X people are a result of a process – activities and interactions, that take place, whether intentionally or not. Creating ‘bad’ conditions for motivation (result of process) “generates” X people, whereas fostering ‘good’ conditions for motivation (also result of process) “generates” Y people. Same people, different conditions yielding different “content”.
You may be convinced that person X is lazy, and person Y is god’s gift to companies. When in fact, the behavior of both is a result of processes – some are visible, most are not.

Let’s look deeper into processes.

Process

We tend to look at process as mechanical, reproducible, predictable. Much like a computer process, or program. But most of the important processes are different – interpersonal, intergroup, complex, context sensitive. Most of all, invisible.
Here’s an example (based on a true incident):
A team member, Oscar, was fired, due to his low performance. He was not taking initiative, not eager to pull tasks of work, not contributing to the team’s success. While he was not sabotaging the team’s work, he was also merely reactive at best of times.

Few weeks later the team was recruiting a new teammate. The Scrum Master, Sam, turned to me, and he was puzzled: he proposed that the teammates will interview the new recruit. But none of the other team members wanted to help. This was their opportunity to shape their own future, but no one was willing to help make that happen.
During our conversation I asked Sam: What might you have “fired” from the team when you fired Oscar? What was in his personality that didn’t fit the team?
It was Sam’s turn to suprise me with his answer: Turns out that Oscar regularly plays Soccer in his free time, and he’s quite good at it too. Not only that, he is a keen caver, so he’s into extreme and team sports. How come Oscar, of all teammates, was the one to get fired because he was a low performer?
Here’s a clearly X person – just waiting for the opportunity not to do anything in or for the team, while leading a very active, motivating, Y-person-style personal life outside work.

Next Sam and I discussed what could lead people to lose motivation: cycles of layoffs towards annual reports, lack of clear goals for the product, an absent-present product manager, and numerous others. All are either organizational processes, or outcomes of yet other processes.
So our work turned to nurturing the team’s environment, rather than jumping to get the team to hire a new teammate themselves.
We like to put processes on a flow-chart, or on a value-stream map, hoping that this will reveal what we need to do and be able to replicate it.
However, just like an iceberg, what we see surfacing is the 10% that surfaces above the water. And the most important things are hidden from the eye, in the 90% of the metaphoric iceberg that is submerged beneath water level.

Understanding what’s below the water level

In order to reveal the content and process that operates below the water level, we need to act. We perform a set of activities, that interact with the “iceberg” that is our context (our workplace, a project, a product, choose your relevant context/s), and yields a result.
Sometimes the result will be desirable, and we can continue that activity so long as it’s effective.
Some other times the result will be undesirable, and we can either retry using an improved activity, or pivot and try something completely different.
And then repeat.
That, of course, is a process. It is also the premise of working within complex-adaptive-systems.
Which means that both process and content are the outcomes of more process. Hence process is always more important than content.

QED.

OK, So what?!

Good question. Maybe, after all, this blogpost has no merit. Maybe this is so obvious that everyone understands and acts according to these principles. Alternatively, maybe these “interactions” and “results” part of process is so overlooked, that we tend to forget it all too frequently.

So next time you come up with a feature development process, or a hiring procedure; or come up with the backlog for the next release, or with the agenda for your meeting – look for the 90% of the process that lurks beneath the water level.

What’s next?

For further reading on complex adaptive systems, try one of the following:

Or contact us for more specific reference or concrete advice

Image by Uwe Kils, photomontage of an iceberg.

Demonstrate Self Organization in Less Than 10 Minutes

Here’s a quick exercise to quickly demonstrate the beauty of self organization. 

All you need is a team of people. Any number between 5-30 people works very well with this exercise.
Purpose: The purpose of this exercise is to highlight the power of self organization, compared to managing people; demonstrate that the most important knowledge is within individuals, and mostly hidden from the eye.

Instructions

Ask for a volunteer. Once selected, tell the volunteer that he is the manager for the exercise.
The task for the manager is that each member of the team will pick two people in the room – not the two right next or right opposite to them.
Then the manager’s next task is that each team member will stand at equal distance from the people he or she chose.
The manager can accomplish this task in any way he sees fit.
Ask the manager if he accepts the task.
Time-box this to 5 minutes (it feels like half a lifetime in realtime).
Ask the group to applaud the manager, and ask him to join the team.

Now tell the team that you are going to repeat the exercise:
Ask each team member to pick two new teammates – again not the ones right next or right opposite him or her. This time don’t tell anyone who you chose.
Next ask team members to stand in equal distance to the two persons the chose – but we’ll make it more difficult this time – now without any talking.
Typically this ends within 30-90 seconds.

Debriefing

  • Ask the team what has happened? What was difficult for the manager to get the team organized?
  • What happened in the second round that is worked so quick? Reassure the team that this has been replicated many times
  • If someone says it’s because of the team’s experience ask: What if we switched the order round?
  • Ask the team: where was the most accurate data? With the manager or with the team? How can we apply this kind of thinking to our daily work?

Typically the second round is much quicker then the first. Rarely it will be the opposite. 
Some possible surprises, and suggested ways to deal with them:

  • Sometimes the manager tells the team: Organize yourselves, or just stand in equal distance from the people you chose.
    In that case you can praise the manager that he “ruined” your exercise by doing the right thing.
  • Sometimes there are multiple iterations in the second round spanning several minutes. Maybe people will be talking and giving orders to other team members. 
    Be patient. Remind them to stay silent, and trust the process.
    In the debriefing, ask the team: Indeed it took longer. And in the process, is the knowledge of organizing still with just one manager? Or with the entire team – so the learning is shared.

Feel free to ask me further questions on how to facilitate this.

Ten Tips to Choose A Great Scrum Master

About two weeks ago I published a blogpost on facilitating better daily standups. I called the blog post “Who’s Responsible for the Daily Standup”, and got the following response from Jim Coplien, the person who inspired inventors of Scrum to have the daily standup in the first place:

“The ScrumMaster owns the process. The Daily Scrum is part of the process. if the Development Team is not holding the Daily Scrum the ScrumMaster should intervene and challenge the team to do so. Whether or not the ScrumMaster does so, if the team persists in not holding the daily standup, the ScrumMaster should be fired.”

— Jim Coplien (by whom the Daily Scrum came into Scrum)

So to help you choose Scrum Masters that should not be fired, here are my ten tips for your next recruit:

  1.  A people’s person. This person should communicate easily and create good relationships easily. The kind of person you know you can trust, and you feel comfortable sharing with.
  2. A technically excellent software professional. I am assuming you are part of a software organization. If not, ‘convert’ software to your own business domain. We, software professionals, are a suspicious bunch. Many of us have this notion that only software people can understand software teams, and tend to demean people who attempt to ‘meddle’ with us. A great Scrum Master should be able to pair with programmers, as well as with other experts, and not make a fool of himself. So to gain trust, you want your Scrum Master to be proficient in your domain.
  3. A product expert. An important part of Scrum is getting great requirements. Otherwise, you get garbage-in, garbage out. So a great Scrum Master should be able to sit together with the Product Owner, and assist in getting good-sized, concise, well-communicated, requirements. To do that the Scrum Master should be experienced in working with Agile requirements (for example generating great User Stories) and, preferably, is highly familiar with your business domain, too.
  4. An organizations expert. Organizations are complex. The more we learn about organizations, the more we realize how complex they are. We used to think that division of organizations by components is great; Now we know it is not. We used to think that strategic planning and goals are key; Now we know that “culture eats strategy for breakfast” (H. Ford) and that “Culture follows structure” (C. Lerman). We used to think that Scrum of Scrums is a good scaling technique; Now we know that scaling is highly complex. So you want a Scrum Master that understands and keeps learning how organizations operate.
  5. An organization savvy. Its not enough to understand organizations. Your new Scrum Master should be able to talk to managers, senior managers and other key stakeholders, and get them to a) understand b) operate and c) lead in an agile manner suitable for Scrum.
  6. A keen learner. With Scrum (or any Agile framework for that matter), we want to foster a learning culture. So you want your Scrum Master not only to learn you stuff continuously, but to put learning to practice and set an example as a learner.
  7. Walk the talk person. Following from the above, you want your new Scrum Master recruit to exhibit agility in his or her conduct, so as to set an example as an Agile person, leader and professional. It’s not much help if the Scrum Master tells others what and how to do Scrum if she’s not doing it herself.
  8. Expert working with data. Visualizing effectively where we are is critical. So your new Scrum Master should know which data are good to collect, and then to present these data in a way that will inspire people – teammates, leaders, seniors, to act.
  9. A great facilitator. It’s not enough to know what Scrum is. Your new recruit should have the knowledge and knowhow of how to mobilize discussions, how to get meetings unstuck and how to plan ahead ceremonies such as retrospectives.
  10. A great coach. We live in an uncertain world that is changing all the time. And most people don’t like change very much. So you want your next recruit to be able to coach people – team members, product owners and others through change and through become ever more agile.
  11. A great teacher. Organizations are dynamic. People join in, people leave, people change roles. To keep a proficient practice of Scrum, the Scrum Master should be able to teach new recruits on what Scrum is, what being agile means, how to enact Scrum in a productive manner.
  12. Humble person. It is rarely helpful when your coach, teacher or facilitator is also a show-off. So you want your new Scrum Master to exhibit humility in the way he operates.
  13. An expert in Scrum. Well, it goes without saying that your new Scrum Master must be experienced in being a Scrum team mate, experienced in coaching teams, product owners and managers, experienced in talking and teaching groups, experienced in guiding managers through change to successful Scrum implementations. And beyond.
  14. If possible, your Scrum Master should also know how to count. I am stopping at 14 tips for recruiting, although I am sure you have your own must-have competencies and expected outcomes for the designated Scrum Master.

What we’re looking here is for a Superman. Or a Wonder Woman. Otherwise, we might have to fire her, or him, because the team pushes back on the daily standup.

I say, let’s not fire the person on whom we’ve put all the elements for failure, and little room for success. Instead, let us all exhibit more humility. Let’s propose means for success and not more reasons for firing people.

After all, “A dead Scrum Master is a useless Scrum Master” (K. Schwabber).

Image source: https://pixabay.com/en/superman-lego-egg-hatch-hatched-1367737/