Zoom Out

Have you heard the expression “context is king”? It’s very true if you work with teams because many of the things that can affect a team negatively can be found outside of the team itself. How good is your understanding of your team’s context?

When the world around our teams is messy, it’s natural to latch onto the smaller and local, team specific, questions and shield ourselves from the complexity that surrounds us. In the worst case, we end up with a powerful “illusion of progress”: we work hard and efficiently in our own bubble, but ultimately we fail anyway.

Obviously, a team should focus on doing its job but if a team focuses too much inwards it looses touch with the reality it exists in. Doing team work well means taking good care both of the internals of the team and the context the team is operating in. The context is what informs about what solution to develop, and why. It also contains the resources and support we need to succeed. So, we’d better understand it well.

Some years ago I learned an exercise we can use to help our teams build situational awareness, but before we dive into the practice of doing this, I want to explore why understanding “the bigger picture” is so important for successful collaboration.

Whenever we try to collaborate in an organization, we experience different kinds of friction. We resist, argue, and misunderstand each other. Without shared understanding it’s very hard to pull in the same direction.

Don’t fall into the trap of believing that others disagree with with you out of stupidity or ill will. That happens of course, but in my experience people are trying to do what makes sense, from their point of view. The question is what their point of view really is? If we knew that, we would understand others better and be better able to collaborate – or intelligently discuss – with them. We may not accept their worldview, but we might be able to understand it better.

So without further ado, here is an exercise I use to rapidly build new insight in groups. I first learned this from Jerry Weinberg who called this technique org mapping. I believe he was inspired by Virginia Satir’s family mapping. The idea is to visualize a bit of the context around a group of people, so that their understanding and empathy can deepen. One caveat: it’s quite easy to do this, but it can shake out uncomfortable truths quickly, so make sure you are ready to handle whatever comes up.

Having gathered a group of people, I begin by handing out blank sheets of paper (larger is often better) and various colored pens, including black ones. I explain that we’ll be doing some doodling in order to better understand their situation.

Participants to begin by writing out a question about the situation that they want to explore – this often creates focus and gives clarifies the motivation for completing this slightly silly exercise.

At this point, I also point out that the aim here is not to create aesthetically pleasing works of art. We’ll be creating visual models of real situations, and as long as we get something to point at and reason about, they are perfect.

I then instruct participants to add the things in the list below. We add one theme at a time with just a few minutes spent on each:

  • Draw yourself (in the middle, and not too large, and a simple stick figure is fine)
  • Add other people (or groups, roles, organizations etc)

Here I ask people to use size and placement so that their pictures seem reasonable. For example, some people might need to be really small and far away, and others larger and close by.

  • Add things (products, documents, hardware, buildings, …)

Again, scale and place things as makes sense. Remember that we don’t need to add everything, just the things that make the model useful to us. I emphasize that it will be useful for participants to zoom out one step more than they usually do, when thinking about this situation. For example: who are the customers of our customers, and what do we really know about them?

  • Draw interactions (information flows, relationships, boundaries, …). For these I explain that arrows of different kinds are useful, as are circles and other lines of various thicknesses and styles.

The pictures are probably getting a bit messy by now. Using different colors can help.

Next, things get a lot more exicting. Now we are ready to start adding opinions about what it is like to actually be in the depicted situation. So, in turn, we add:

  • Problems (everything from a little friction to major crises)
  • Strengths (things we want to keep building on)
  • Other things that need to go in the picture

As you can imagine you can do a lot of interesting variations or changes to this exercise. You could add other categories to help catalyze ideas: who has power, who thinks or says what, which informal alliances exist, and so on.

When I participated in this with Jerry Weinberg some years ago, he ended by asking us to give our drawings a title. I really like how this causes us to externalize and summarize so this is how I usually end the drawing too. Don’t be surprised if the titles of your paintings contain some variant of the word “mess”.

In fact, the word “mess” is the exact term that systems thinker Russell Ackoff used to describe the interacting system of problems that characterize organizations. I love how clearly we see just how complex our workplaces are whenever we draw them like this. Again, we are not assuming that we are looking at reality here, just one quick attempt at sketching out one perspective on it. I call this kind of work “zooming out”.

So what do we do with these drawings? We explore them together in dialogue, with the explicit purpose of better understanding the perspective of others. We explore the interactions that produce the performance of this organization. By combining our various perspectives on a situation, we approximate a more true understanding of the reality we find ourselves in.

A word of caution. Zooming out can awaken feelings of hopelessness. Large organizations in particular always come with an unhealthy serving of institutionalized insanity. Seeing this and realizing how hard it will be to change is tough. Still, we need to do what we can, here and now. We dig where we stand. Understanding the larger picture can help us make meaningful local changes, even we currently lack the formal power to change the system at large. With a better understanding of the larger whole, we might even be able to start to influence it more effectively.

This text is one of the tips you can find in “Tips from the agile trenches – for scrum masters and agile coaches” edited by Yves Hanoulle. In it, you can find lots of shorter and longer tips to inspire your leadershipwork. Check out the table of contents and you’ll soon see why it’s worth reading.

The Value of Recreational Programming

I wasn’t a professional programmer for very long, just a few short years at the beginning of my career. I did a little bit of UI development for a sample preparation robot. I created a bunch of XSLT sheets for a content management system. I fixed up a training and diagnostics software for a DNA analysis machine. Not trivial things, but not too complicated either.

I constantly struggled with how hard and lonely it felt. Mob programming was not yet a thing and neither  was pair programming – in the companies I worked for (even though others where doing it, since this was the early 2000:s). The other developers I worked with, or maybe “worked near” would be a better choice of words, all seemed content with doing their own thing, on their own. I felt constantly incompetent, most likely because I was. Still, I remember those years fondly, because programming can actually be fun. It was just that I hadn’t yet discovered what it takes to make it so.

As a kid I mainly used computers for gaming, even though I typed in my first program ever on my neighbors Texas TI-99 4A. Her father would read a program listing to us, and we took turns typing the letters in. Our neighbors had no means of external storage so once we’d run the program a few times (the results typically weren’t that exciting) we would shut the computer off and it was all gone. This must have been in the early 1980:s.

Also back in the 1900:s, older people used to do something called crosswords. On paper. I’ve always found crosswords way too hard for me. My patience and vocabulary both fail me (unless it’s the New York Times Mini Crossword – those are lovely). Still – I do need a mental challenge in my free time every now and then.

Instead of crosswords, I do something I’ve come to think of as recreational programming. It might seem obvious that programming is a great way to exercise your mind, but for some reason things like crosswords still seem to be a more frequent choice of activity. That’s a pity, especially if you spend your working days in the software business doing something other than programming. I’ll explain why in a bit.

My favorite platform at the moment is the game development tool Unity. It’s a wonderful platform, because it lets me get to results quite quickly. It’s just wonderful to play around with and I build lots and lots of little fun things just for the joy of it. That said, I’ve also dabbled in Python and Ruby, and hacked together some nice backup and PDF-generation scripts in bash. As long as it’s fun, it fits for me.

I spend my working days as a consultant and trainer. I call myself a ”full stack management consultant”, because I help people at all levels in software organizations to get stuff done and collaborate better. I don’t do professional programming any longer though.

Although my recreational programming is primarily for fun I find that it also provides me with an additional benefit: it helps me remember some key things that may be hard to understand for someone who has never programmed. Here are some such things:

  • Programming can be pretty hard. It really does take a lot of concentration. Once you loose your concentration it can take a while to get back into the flow. This is why it’s so important to create a focused working environment for your development teams.
  • Programming can be very fun, and that is why a lot of people choose to do it for a living. It also means that it’s really not that strange if your developers seem to care a bit more about the code than about actual business results some of the time. You can’t be great at everything. Well, some can, but most of us can’t. This is why we have cross-functional teams with an ongoing dialogue that balances business value and technical sustainability.
  • If your software’s internal design (i.e. the source code) isn’t very good, programming isn’t fun any more. Once the software turns into a spaghetti mess the experience of working with it rapidly degrades. If you’ve ever wondered why it takes forever for your team to develop something that seemed simple to do, this could very well be the reason, because messy code is slow to work with. It might also explain why programmers are leaving your organization in search of greener pastures/code bases.
  • Some programmers are really skilled at creating well designed software. Many aren’t, and many aren’t even aware that there’s a difference between good and bad design. Some get stuck in polishing the internals for too long, but that’s probably much less common than the situation where the internals get too little love, and therefore degrade over time.If you’re a manager, an agile coach, team lead or scrum master with no programming background, that might not be a problem. It may even turn out to be something you can use as a strength, but only if you can manage to turn up your curiosity and trust the professional opinions of your more programming-savvy colleagues. If you don’t, you run the risk of causing havoc in both your product and your workplace, simply because you don’t know what is important when it comes to programming. Programming is, after all, still an important part of software development.

Some Pitfalls In Experiential Training

Training classes using an experiential approach has more and more become the norm in agile leadership trainings. Check if some of these pitfalls are something you need to design around as you prepare your next class.

Many trainers in the agile world are really good at using interactive exercises to engage participants. I’ve been a teacher in many different kinds of classes over the years. In the mid nineties I worked extra during my studies teaching evening sessions on how to office software. And photo editing. For a brief period I did some training in a content management suite for a client at various sites.

The last thirteen, fourteen, years or so I have been teaching various agile related classes, the majority of them scrum-related. This opportunity has given me many opportunities to make interesting mistakes”. Some of them I believe I have even learned from.

Here is a batch of tips on how to avoid some common traps that I’ve seen myself and others step into.

Interactivity vs Experiential Learning

I’ve always had a lot of interactive elements in my trainings even before I first came across the concept of experiential learning. The realization that there was something important missing from the way I taught came when I first attended workshops that were facilitated by a true master in experiential training (this was, of course, Jerry Weinberg, see book reference below). This happened about ten years ago. I came to see that it is not just about the interactivity (which makes the training more fun and engaging than a typical lecture) but about truly making new insights from engaging experiences and skilled reflection.

Experiential learning is based on the idea that knowledge is constructed rather than transferred. An example of trying to transfer knowledge would be a lecturer presenting a prepared set of slides while listeners follow along and take notes. I love a great talk. These days, however, I find that I might as well get them on Youtube. If it’s just the information I’m after, it seems very wasteful to move my body to a new location just to get at it. Let the information come to me, rather than the other way around.

The model I now use to design and facilitate these kinds of sessions looks something like this (and is described in the books referenced by the end of this article). It builds on the concept of the experiential learning cycle as described by Kolb. I learned about it first by watching Jerry Weinberg in action:

  • Exploration: invite participants to a seemingly simple task – that actually turns out to be more challenging than it first seemed
  • Invention: help participants put words on their experience, harvesting insights and constructing new knowledge. Also: add some theory from your domain of expertise that helps complete the picture. More about this “addition of theory below”.
  • Application: let participants figure out how what they’ve learned relates to “life outside the classroom”, so that the learning becomes real and useful. This might also mean that they take what they’ve learned in this particular part of the class and use it in the next part. For example: participants take their insights about the importance about having clear “working agreements” and next attempt to actually use the agreements they just formulated.

Without further ado: some interesting pitfalls that I’ve experienced and hopefully learned a bit from.

Navigating the Context

In experiential workshops and classes, so much is going on all the time. If you do it right, participants are constantly exploring new insights and concepts. The backside of this is that we might lose track of where we are every now and then. Some are more sensitive to this than others.

For myself, I have noticed that I am often quite immune (but not completely) to getting lost, because when I’m deep in learning mode I keep seeing interesting stuff everywhere I look. This means that I have to make a conscious effort when I teach to remember that some participants need to know “where in the agenda we are” is much greater than my own.

A physical agenda on the wall can help a lot for some, especially if you stop every now and then to publicly reflect on what’s been covered and what remains. I personally find this insanely boring, so I keep trying to come up with ways to make it more fun. One way I like is to let participants recap in small groups or pairs. To avoid being overly constrained by the agenda I choose to keep it a high level. This lets me observe and adapt as needed, while still keeping a general direction towards the learning goals people came to the class to satisfy.

Another part of navigating the context is to give some sort of introduction when you open up new topic areas. The more of an expert you are in your field, the more prone you will be to miss this. Why? Because to you it seems so obvious what you are talking about. Others may completely lack the mental models needed to understand just what the heck you’re talking about now. I find that storytelling is one powerful way of setting the scene in the right way.

And speaking of setting the scene. Therein lies another potential challenge when it comes to designing and facilitating experiential training sessions.

Use Just Enough Setup

While the experiential approach rests on letting learners use experience and reflection to construct knowledge, this does not mean that they should be left completely to their own devices.

The desire to let participants step into exploration sometimes makes us act too quickly. We kick participants off into a task that they have had no chance to get their minds around. If the learning goals had to do with learning how to act when the goals are unknown that would be fine, but if that’s not the case, it’s likely that your lack of setup moves the group in the wrong direction. If you notice that participants are struggling to understand something that you thought was very clear, then a lack of proper setup might be a reason.

Just enough setup might include giving participants a clear set of written instructions. It definitely means giving them a seemingly simple and clear task, the complexity of which is only revealed as they start struggling with it.

An example might help. When I teach story mapping I’ve come to realize that while the technique seems simple enough for those who have used it, those who haven’t yet tried it don’t find it quite so obvious. When doing story mapping for real with a client group for the first time, I’ve used Jeff Patton’s excellent advice from his book on the topic: we do a simple story mapping of how we go about our mornings. By using an example from a simple and relatable domain, we get more brain cycles left to focus on understanding the actual approach. Then we can safely start working on the real situation that needs to be mapped out.

With less time available to teach the concept, however, things are a bit trickier. In my product owner classes participants work under some time pressure to explore a product concept they’ve come up with in the class. A part of this is creating a story map for the product. Here is how I prepare participants for this part of the training:

  • First, I explain that I still cannot explain story mapping in a brief and clear way, and that the best way to learn is to actually try it.
  • Second, I still provide a brief explanation of the technique, while emphasizing that I don’t expect anyone to truly get it. It’s just a flyover over what is expected.
  • Third, I ask participants to study a very small example in a handout I provide, just for a few minutes.
  • Finally, groups are invited to create a story map using stories we have previously sketched out.

In this particular class module, since the focus is not on learning about the group dynamics in the situation, but the technique itself, I stay available to coach any team that gets stuck or has questions about how to do the work. Mindfully choosing how to adjust your behavior as a teacher in the different phases of the experiential learning cycle is key, but more about that in a bit.

Debrief With Powerful Questions

The absolutely biggest and most important insight for me has to do with the importance of debriefings: of helping participants construct their own knowledge. This is sometimes misconstrued as “letting people learn whatever”, but this is not the intention. We do have some learning goals in mind as teachers that we want learners to explore around.

In experiential training, your role as teacher is to help participants make sense of the experiential exercises you’ve created for them. One could argue that all learning is experiential. If this is true, that means that the tools you are using in your debriefings stay useful once participants leave the classroom. The option to learn more from experiences is available to us all the time. This may very well end up being the most important skill you teach.

The pitfall here lies in falling back to the deceptive safety of transfer mode. We know this has happened when we start talking about what we need to “cover”, as if simply mentioning something means that we’ve helped anyone learn about it.

This might happen when an experience has just ended and it’s time for debriefing. Instead of letting participants construct their own learnings, we step in, take over, and start to explain what the takeaways are. As an aside, I always get irrationally annoyed when a conference presenter ends a presentation by stating “the takeaways”. I’ll decide on my own takeaways, thank you very much.

I find that the way to prevent this destructive over-helpfulness is to prepare my debriefing approach as carefully as I prepare the experiential part itself. I prepare a specific set of questions that I will use to facilitate learners construction of new insights. These questions take the form of very open and powerful, or generative, questions. They open up for reflection and further discussion, and thus help learners engage in investigating what they are actually learning.

Control Your Interactions

Speaking of preparing ourselves, it’s helpful to think about how to interact with participants during the different phases of the learning cycle. During the explore part, I find that it works best if I step into the background. The more I intervene in the exercise, the more it seems that I rob participants of their own sense of responsibility for the work to be done – and with that much of the possibility for true learning. The situations turns to be about how well I can help them, as a trainer, rather than about how well they can construct new insights from what just happened, using skilled reflection.

I recently found myself on the other side of the table in this situation as I participated in a training. Just as I was about to grasp what I was expected to do, a trainer stepped in to help accelerate the process. I did learn from this, of course, but probably not what the trainer intended me to learn. My primary takeaway turned into a clear insight about just how disruptive and emotionally challenging it can be to focus on a challenging task, only to have someone else step in and take command. This was, by the way, a world class trainer, so don’t think you’re immune to this particular sort of unhelpful intervention. Often, the more we want others to succeed, the harder it is to step back and let them fail and learn.

Have Ample Time to Debrief

One more tip about debriefing, a short but important one: make sure you plan for ample time for the invention phase. Because we are always pressed for time (the more interesting stuff we have to teach, the more we try to cram in) we always run the risk of short-changing the debriefing. Also, because you as a trainer have already mastered much of the material you are trying to teach, there is always the subtle suspicion that it might be more effective to “just tell them the answer”. There is often an unconscious collusion here between learner and teacher, because most of us have gone through years and years of schooling where the message behind the message was that “the teacher has the answer, and you’re supposed to memorize it”. We need to remember that we all have a part of us that harbors a desire to just be told what to do.

Add Some Helpful Theory

Experiential training does not mean that participants are invited to make up any kind of insights. As a teacher, you have an agenda, some topics and models that you want to convey. You design exercises and debriefings that will help participants internalize these concepts, and often other insights (sometimes very personal realizations). This does not mean that your expertise in the field is not wanted. It fits well into this model of learning. Here’s how you fit it in.

Once participants have gone through an experience and you start debriefing it with them, this opens an interesting door for you to provide some additional theory, concepts, models, and such. Your primary task is to help participants construct new insights from what just happened. However, you can help them in this task by providing support. That support might come in the form of useful theoretical models that help learners make sense of what just happened. You do it with a light touch, however,

At this point, what you add fits right in, because if the experience people just went through has left participants with some ”hooks” to hang the new information you provide on. It has also most likely caused some new burning questions to appear, which you can now help answer. This means that the learning is connected to real experiences and true needs. Learning that satisfies a true and current need is very powerful. It is real in a completely different way; it’s not just adding new information – it’s helping you to make sense of the world around you.

Get Help With Your Congruence

I find it very important for us teachers to reflect regularly on to which extent the way we teach is congruent with what we are teaching. Why? Because if we say one thing and do another, the whole thing falls apart.

For example, if you are teaching the concept of self organization – are you conscious of when you do things that might actually impede self organization in the class? I once arrived late to a conference session on the topic of retrospectives. The presenter was a well known consultant in the agile community. As we entered the room he said something slightly demeaning about how arriving late was a sign of not caring, or something to that effect. He then proceeded to open his presentation about retrospectives by talking about the importance of creating a psychologically safe environment.

The only thing I remember from that session was the glaring mismatch between his actual behavior and his topic of choice. Try not to be that person: remember that your actions speak louder than your words.

A challenge for me (and, I guess, for you) is that it’s quite hard to spot these things in ourselves. We are stuck in our heads looking out at everyone end everything else. Everything can look quite OK from that vantage point, according to the same brain who just made you commit some obvious mistakes. We need a mirror to see better. So, ask someone you trust to spot you in class and give you feedback afterwards. For example, you could ask: “is there anything I am doing that goes against the message I am trying to teach?”

Summary

  • Experiential learning is the art of learning from experience using skilled reflection
  • Navigate the context. Help participants localize themselves in the vast space of situations and concepts that are whirling around.
  • Use just enough setup. Do: Give just enough information to avoid confusion and have enough goal clarity. Don’t: Try to explain exactly what needs to be done.
  • Debrief with powerful questions to help learners construct new insights.
  • Control your interactions. Let people have their experiences on their own. Step in to help make sense of what happened, but don’t do all the work for them. Step back and let people find the connection to their personal needs and situations.
  • Have ample time to debrief. Rule of thumb: use as much time to debrief as you used for the exercise itself.
  • Add some helpful theory when participants are ready to receive it. Before that, help them construct as much of the insights as possible themselves.
  • Get help with your congruence. Ask a trusted friend or colleague to spot you and explicitly tell them what kind of feedback you are looking for.

Learn More

Learning About S3

Sociocracy 3.0, or S3 for short, is a collection of principle-backed patterns for more effective collaboration. It can be seen as an attempt to reduce hierarchy while at the same time providing an alternative type of structure.

This week I’m attending a three day workshop about sociocracy 3.0, or just S3 for short. The idea of sociocracy has apparently been around for a very long time. The class I’m attending is focused on “S3”, created by James Priest and others as a continuation of the idea of sociocracy.

Patterns, here, can be explained as previously observed behaviors that have been collected and described for future use. They are linked together in various ways, so that they can complement each other.

I find sociocracy and S3 interesting because it might hold some clues for how to answer some currently important questions, like:

  • “We like self-organizing teams – but how could we get self-organization on a larger, organizational, scale?”
  • “If we remove the traditional organizational power pyramid, what should we replace it with?”
  • “I like the principle of self organization, but I can’t see how.”
  • “How can we be more agile outside of software development – maybe in the whole organization?”

I like the idea of a collection of patterns backed by principles. This is how Scrum started out, and while too many have only experienced Scrum in it’s most ossified form (blindly following a subset of the practices, with none or little focus on the principles) – Scrum is still most interesting when seen as patterns on top of princples. I would actually be very happy if the official description of Scrum could evolve more in the direction of more open patterns, building on the same principles as now – but more about that in a future post, maybe.

In general, I would love to see less discussion about which framework a given organization is using, and more about which patterns they have chosen to adopt and how they are tying them together. S3 fits perfectly into this desired reality, and I look forward to learning more over the coming months and years.

What are you doing to spread the principle of self-organization in your organization?

Learn More About S3

Rolling Out Scrum – How Hard Can It Be?

The belief that an idea like Scrum can be easily and predictably rolled out in an organization is still wide spread. It’s a tempting fantasy and a potent recipe for problems. Scrum is not about installing best practices – it is about activating curiosity, using all of the brains we do have, and giving experience and reflection some room to work their magic.

– ”This shouldn’t be too hard”, said more than one of my prospective clients. You’ve probably heard it too. After all, how hard can it be to ”roll out Scrum”? Isn’t it just about having regular planning sessions, a backlog, and maybe a retrospective every now and then?

Well, to begin with, Scrum is much more than meets the eye. Beyond the seemingly simple practices hide lots of challenges. Take the idea of having a single prioritized backlog. Sounds like common sense, right? Now imagine succeeding with this when you have five different managers who all want to have their stuff done first.

So, before you proudly proclaim that you’re rolling out Scrum across the organization, my advice would be to think of Scrum not just as a way of working, but as a idea virus. Embedded in the practices of Scrum are values of openness, partnership, mastery, service to others, self organization, and much more. Once released into the open, these ideas will affect your organization.

In a way, starting with Scrum is more like starting up the engine of your car. You still have to decide where to go, and how to get there. Then you have to keep driving and navigating, constantly staying aware of what is happening around you and in you. And you absolutely can not fall asleep at the wheel. Or to be more precise, you can, but since you don’t want to crash and die, you really shouldn’t.

If the people in your organization are secretly longing for the values hiding behind the Scrum practices, those ideas will start to take hold. When this happens, changes start to foment in more places than you might have first imagined. What started out looking like just another development process for the software people turns out to affect everyone from CEO to coder. Better to be prepared for this than be caught be surprise.

This is an excerpt from a book I’m very slowly working on, called Pitfalls of Scrum. In it, I hope to capture some of the common misunderstandings and mistakes I’ve seen in organizations aiming to use Scrum. Maybe even some practical advice. If it sounds interesting, take a look and sign up for notifications on the book’s Leanpub page.

Efficiency Is Not the Only Value

Not too long ago I was teaching a class at a client company. During the morning of the second day of the class, I had reserved a block of time for diving into some of their specific challenges. I usually do this, because while I have an agenda I’m supposed to cover, I know that one of the most important parts of learning new things is discussing how to apply the new knowledge and skills in your own unique context.

To kick off the discussion I asked everyone to write one or two sticky notes with the questions or topics of greatest interest to them. Once the time was up everyone got to take turns presenting their selected topics. Something interesting happened as this was going on.

During the posting of topics, one of the managers approached me and asked if we ”hadn’t already done this”. I asked him what he mean. He explained that as he signed up for the class, he had already been asked to provide some information about which topics were of most interest to him.

For some reason his question annoyed me. This was surprising to me because I seldom get annoyed with participants in my classes. I explained to him that I thought the activity would be time well spent. He clearly wasn’t satisfied with my answer, so I asked him a very direct question. I said: “Tell me what your real question is”. As that request came out, I could hear how threatening it might have sounded. He wasn’t fazed however and so could explain his thinking to me.

The manager’s answer shed some light on his concern – and simultaneously on my irritation: he thought that I was being very inefficient by asking participants to provide the same information twice. He thought I should have been able to use the information from the class signup as the basis for the discussion, rather than generating it all over again.

As I reflected upon this after the class, I realized why his question annoyed me. It annoyed me because his question (regardless of his intent) seemed to me to come from a completely different world view than my own. It annoyed me because it reminded me of some of the previous attempts of managers I’ve worked with to make things more efficient, and how I saw those attempts as a lack of respect for my leadership skill. Of course, none of these thoughts came to me in the moment all this happened. Then, I was just annoyed.

I was annoyed that this manager seemed to believe that he could improve on my class by making it more efficient. My focus is always on making a class effective (reach the intended learning outcomes) even if that means it can sometimes be a bit inefficient (some rework, for example).

You might wonder why an attempt at making things more efficienty would be so annoying? Isn’t efficiency important? Well, the topic of the class was the agile product owner. The major part of being successful in that role comes from the insight that it’s more important to be effective (develop the right things), than to be efficient (develop things in the most optimized way). At least if you want your product to sell and actually provide value when used.

Efficiency is a deeply held value in many organizations. That annoys me, because a lot of the time the focus on efficiency seems to cause more problems than it solves.

There are many other values we can choose to focus on, besides efficiency, if we can manage to stop worrying about being so darn efficient all the time (gasp!). Here are some other values that I suspect will bring you more benefit, should you choose to make them come to life in your organization:

  • Be effective – do what counts (in the class, for example, we collaboratively chose the topics of most value to the group as a whole)
  • Value learning (in this case, participants got a chance to reframe their key question based on what they had learned during the first day of class)
  • Value invitation and participation (by asking everyone to participate, I got input from all participants, even those who didn’t provide any when signing up)
  • Experiment (by trying new ways of doing this exercise almost every time I do it, I’ve come to learn many things about how I can make it work well)

With all this said, I do love being efficient. It’s just that I can’t fool myself: some of the time when I’m being efficient, I’m just really good at doing the wrong thing. Efficiency brings me joy, and that’s important. But: it doesn’t necessarily bring others value. Might the same thing be said for the work you do?

Introducing: a Software Development Canvas

Software Development Canvas - Thumbnail

Those who know me know me or have taken one of my classes know of my keen interest in helping people go beyond method – towards a deeper understanding of why we are getting the results we are getting. Lately, I’ve been working on a thinking tool that might help in that regard.

First, a little background. While most of the world is still struggling with doing basic-effective-thermostat-Scrum, we more and more often find organizations that have come to a state where the choice of framework is not that interesting any longer. Much of the agile mindset is there, but as always many challenges remain. In that situation, trying to “do better Scrum or Kanban” isn’t really that fun. It feels like going backwards (even wouldn’t be for many). Anyways, I like options, and this is one attempt to create one more option for how to approach the discussion around how we work.

I still find that most people need some kind of support in their thinking about tricky situations.

A couple of years ago I came across something that was truly helpful for me: the business model canvas. Not coming from a business background, it’s been a great help for me. I’ve been a partner in our consulting firm for 15 years, but I’m not a born and raised business person like some of the people I’ve worked with over the years.

The business model canvas was an eye opener for me. Turns out that at a business level, most businesses struggle with the exact same kinds of problems that we have around the software development. For example: that someone has “written down the business plan”, but unfortunately nobody else has read that document. With the canvas, we can work faster, more visually, and most importantly: invite people to explore with us. Sounds pretty agile, right?

Not only does the business model canvas teach some basic building blocks of a profitable business, but it also does so in a way that strikes a deep chord with me: it tries to show the bigger picture. We get to visualize the business model in its entirety, albeit it a high level.

I’m a systems thinker by heart (and brain, I guess). Seeing the whole and trying to understand it has intrinsic value for me. I just need to understand. It also turns out to be pretty useful to have that kind of overview and understanding, because performance in a business comes from how well all the parts work together, not from how well the individual parts work individually.

So, I’ve been thinking. Why can’t we do the same for the software development part of the business? While the business model canvas is great for exploring the overall value creation process, it doesn’t really help us with the operational aspect of things, nor is it intended to. That’s fine. All we have to do is steal the idea and apply it to said operational concerns.

Results in software development is truly a holistic concern, so the canvas concept should work well here. I recently created a first version of such a canvas, and I’ve started to try it out both in client work and with fellow consultants at Citerus. Initial feedback has been good, so I’ll keep working on it. I’m putting it up here for you to explore, and I’ll be back with more when I have it.

In creating this first version, I’ve taken cues from agile and Scrum, of course, but also from a paper by Thomas J. Allen which I read many years ago and has followed me since. In it, he discusses how knowledge need and market needs – and, importantly, their rate of change – must affect how we organize.

Instruction for use, in short:

  1. Draw the canvas on a big whiteboard
  2. Put on your facilitator hat
  3. Choose an aspect of your software development work to explore
  4. Explore away, together. Obviously, use post-its.

Just to give some examples: you might want to explore what an idealized design might look like for your way of working. Or, you could put on your SWOT-cap and explore your internal strengths and weaknesses and the external opportunities and threats, guided by the canvas. Maybe you could do a values based inspection of how you’re faring, by asking questions like “how are we living up to our values of courage and transparency in each of these areas”?

My favorite idea though (which I have yet to try myself): you could use de Bonos six thinking hats – complemented by the seventh hat which my kids invented – the silly hat.

Think of the canvas as a pre-designed overall agenda. Use it to avoid missing important pieces of the puzzle. Give it a shot and let me know how it turned out.

Caution: this is a first version. I don’t expect it to be complete, and neither should you. I expect to keep exploring this, and revising the canvas as I go. Feel free to get in touch if you have ideas or questions.

Here’s the download link: Software Development Canvas, PDF.

Why Task Assignment Sucks

You may be like me. Some things at work suck the life out of me. I can’t always explain why. Most of the time I can learn to live with it, and therein lies the crux. I accommodate things that I really should refuse outright. Here’s one such thing: task assignment. See if you agree.

Assigning tasks. Also known as the age old habit of telling others what to do. Try to go a day without doing it. It’s pretty hard, especially if you have kids. Probably also hard if your title includes the word manager.

SO what’s so bad about assigning someone a task? After all, it can’t be that bad – there’s even support built in for doing it our planning software. Assign to person X, that’s what the buttons say.

Here’s why this bothers me. I’d much rather pick my own tasks. After all, I was hired to do what I do. Or at least I haven’t been fired yet. However it is: I’ve come to trust myself (at least some of the time) to choose which tasks will best take me towards the goals we’ve agreed upon. If we haven’t agreed on goals yet, I definitely can’t see why you would tell what to do. We should talk about goals before we do anything else.

Being assigned or picking. It might seem like a meaningless play with words, but I believe that the words we choose reveal something about our world view.

In one world view, people are resources to which we assign tasks. Worker threads that waste cycles when idling.

In another world view, people are people. Fully capable of filling their own work day with the right stuff, given a little bit of wise guidance.

You might think: ”sure, letting people pick their tasks would work with an experienced and motivated team – but you haven’t met my team. If I don’t tell them what to do, nothing at all gets done”.

To this I could reply: ”OK, your team sounds like it’s struggling. Have you tried giving them a juicy goal, and then letting them figure out how to reach it?”.

You in turn might just reply that you have indeed tried that, and that it didn’t work at all. Nothing did get done, as you knew it wouldn’t. Or maybe the wrong things were done.

Then I’ll ask you what you did next. If you now say that you stepped in and assigned tasks to people, then you might be able to see where the problem is.

Assigning tasks robs people of the ability to learn how to figure out the way to the goal themselves. It’s a learning stopper, and if there’s something we need more of in today’s organizations it’s learning.

In the end I don’t care if your buttons in JIRA still say ”Assign”. JIRA is a tool. You’re not. You know better.

Bringing In an Agile Coach

Agile coaches are everywhere these days. The nice thing about that is that agile has become so popular. The sad thing is that there is now a greater risk that you end up a with an agile coach that doesn’t really make things better for your company. Here’s what you need to think about before you bring in an agile coach.

There are so many different ways of defining what an agile coach does that to hire one, you need to be really clear about what kind of help you’re looking for.

One very fundamental distinction to consider is if you’re looking for an extra pair of hands or if you’re looking for someone to truly challenge you to grow and develop.

In my consulting work I do mainly the latter. My clients hire me not to run their project for them, but to support them in clarifying and understanding their organizations, their way of working, the motivations of themselves and their colleagues and so on.

Of course, I also bring a certain level of expertise that I can share where it fits. That said, I’m always amazed (but not surprised anymore) at how all the knowledge needed to perform better is already available inside my client companies. Often it’s not a bunch of new ideas that’s needed but better ways of really discovering and using what is already there.

If you’re considering an agile coach, I would advise you to consider making it a consulting type of role more than a pair-of-hands role. Let me explain why.

Everyone in your organization is busy working inside their sometimes very specific areas of responsibility. However, how well an organization performs isn’t decided by how well everyone is doing their jobs in isolation. Total performance comes from how well the individual performers play together.

Here’s the thing. An organization can fail from everyone doing their job as well as they can. What you need for success is that eternal management consultant buzzword: synergy. Synergy simply means that individual performances blend together into beautiful music. That music is what you should ask your agile coach to help you find.

So what? So far, nothing new here. Well, if you believe me when I say that coaching for performance needs to be about finding the synergy that creates beautiful music, then you should also consider the consequences of this.

What are the consequences of focusing on synergy? The consequences for the agile coach is that the coach needs to to work with your entire organization as a system, not just with parts of it in isolation. In practice, the coach you choose for this needs both the skill and the freedom to:

  • Explore all parts of the organization that need to be explored if performance increases are to be found
  • Ask all the questions that need to be asked
  • Work with all the people in the organization that need to be worked with

The coach’s part in this it to have the skill, confidence, curiosity, and experience needed to undertake such a systemic exploration. Your part as client is to make sure the coach really can do this, and then help your coach gain access to as much of the system as is needed to get to the performance you are looking for. This does not mean you should give the coach a carte blanche—it means that you should clearly define what you are aiming for, and then make sure to contract in a way that actually supports reaching this goal as effectively as possible, and in a way that makes the results stick.

In other words your agile coach will need to do much more than hands-on work with one or several teams. Your coach will need to actually coach, and coach in all directions. Working only inwards with your teams will not be enough simply because many forces that determine team performance are best dealt with outside of the teams.

To state it more bluntly: if the team is performing badly because you as a manager did a bad job creating the supporting circumstances for effective team work – then you need help too, if things are to improve.

Summing up: performance in organizations is about making sure all the parts work well together. Therefore the agile coach needs to work with all the parts of the organization.

Here’s the tricky part. Coaching while inside the hierarchical organizational pyramid is really difficult. As soon as you are part of the power pyramid, you become influenced by it. After all that’s the point of the hierarchy: to influence people to do their assigned job and report back upwards. It’s not impossible to coach from the inside, just a lot more difficult.

It is always hard to see an intricate system such as an organization clearly. It is harder by a magnitude when you are inside of it, being pressured by both seen and unseen forces to look at it in a specific way. This is why it may be wise to bring in help from the outside from time to time. Someone who sees things with fresh (and preferably kind) eyes.

If you tell your agile coach to “just make this team improve” while kindly asking for you to be left alone, I wouldn’t bet my money on your success. If, on the other hand, you sit down and have an explicit conversation with your coach about how to safely approach and engage with all those who need to be part of your journey to higher performance, then I’d say you’re off to a promising start.

By explicitly starting out by discussing what agile coaching means to you, you stand a better chance of discovering whether the candidate you’re talking to is up to the challenge of engaging with the whole organizational system. Or vice versa, if you’re looking for a pair of hands for a limited time and the candidate believes you want coaching.

If you do want coaching and it turns out that your candidate’s definition of agile coaching is “just enforce my favorite method and drop the rest in your lap”—then you’ll be very happy you caught that earlier rather than later. If you don’t, you might just discover that you’ve just used “agile coaching” to lower the performance of your organization rather than elevate it.

  • For more on the different ways we can hire help, read Johanna Rothman’s article about contracting versus consulting.
  • For more about clear and effective contracting, but also about working in an internal coaching role, see Peter Block’s “Flawless Consulting”.
  • For about ways to work with a systemic approach to agile performance, check out Bas Voddes and Craig Larmans two great books about scaling agile.

Copy-Paste Management

Developers sometimes engage in copy-paste development. If you’ve never written code, this is when a developer copies, pastes and possibly slightly modifies some existing code – instead of following the cleaner practice of reusing the code by (for example) turning it into a single function that can be called from multiple places.

Copying and pasting is very seductive. Developers know that it’s not a good long term solution, but in the short term it’s just so quick. It worked there, so it should work here.

Not just developers engage in copying and pasting. Managers and change artists do it too, and in a way, the behavior is a part of Scrum, as it is with any other packaged approach. What does copy-and-paste management look like? It looks like people trying to imitate what worked at another company, at another time, with different people – in the hope that it will work here too.

You can suspect that you have a case of copy-paste management on your hands the moment you hear someone in your organization say: “We should use Scrum”. You will know you have a case of copy-paste-management if you discover that no one seems able to give a reasonable explanation as to why you should use Scrum.

This text is short part of chapter 1 – “No Purpose Beyond Scrum” – in my upcoming book “Pitfalls of Scrum”. If you want to receive an email when it’s done, use this small form.