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.

Shallow Success, or The Story of The Kidnapped Trophy

Did you know that there was once a project manager that successfully delivered a project on time, on budget, and according to specification? Don’t be surprised if you haven’t heard the story – it turned out quite embarrasing in the end, so it might have been covered up a little bit. Here’s what happened.

After hearing about the project manager’s uncommon feat, the project management community was so astounded that it was decided that an official recognition was in order. The yearly gathering of project managers seemed like a suitable venue, and so plans were made and a suitable trophy was commissioned.

On the night of the ceremony the successful project manager walked on stage in front of the gathered community in order to receive an award from the hands of the king and queen of project management. Unfortunately, just when the project manager was about to grab the delicately ornamented and lavishly gilded “Iron Triangle Trophy”, a small girl jumped up on stage.

– “Stop!”, the girl shouted to the king and queen, with the side effect of also silencing the entire audience very effectively. With a grim look on her little face the intruder turned towards the audience.

– “Yes”, the girl said. “It is true that this project manager delivered a project on time, on budget, and according to the contracted specifications. However, my daddy uses the system when he works and he says it’s terrible. I know, because he comes home angry every night and says bad things about it. In fact, he said that it was a total pile of …”.

Her last words couldn’t be heard, because the king and queen had unplugged the little girl’s microphone. They congratulated each other by nodding their heads ever so slightly and staring deeply into each other’s eyes. That’s why they weren’t prepared to stop the little girl as she ran up to the king and snatched the trophy from his hand and proceeded to run off behind the curtains, never to be seen again.

They say the project manager never understood what happened, and went on to manage many similar successes during a long and fruitful career.

This might end up as the introduction to the chapter called “Shallow Success” in my upcoming book “Pitfalls of Scrum”. If you might be interested in it, sign up here:

Prioritizing Effectively as a Team

My new article “Prioritizing Effectively as a Team” is up on The article starts out like this:

“A common reaction to the product owner role is to see it as too big for a single person. If the idea were that one person should do everything from guiding the vision to writing user stories, I would agree. But that’s not how I see the role; I see it as one component in getting to effective teamwork.”

You can read the full article on (no registration needed).

The Birth, Death, and Rebirth of Ideas

Watching the waxing and waning of software development methodologies made me think about the lifecycle of ideas. Throughout the ages, humans have come up with ideas. Some ideas never become more than a thought. Others spread globally, affecting people for a long time. The life of ideas seems to be an eternal cycle of birth, life, death, and rebirth.

Watching the waxing and waning of software development methodologies made me think about the lifecycle of ideas. Throughout the ages, humans have come up with ideas. Some ideas never become more than a thought. Others spread globally, affecting people for a long time. The life of ideas seems to be an eternal cycle of birth, life, death, and rebirth.

The Spark

Who can tell where ideas come from? Suddenly they appear. Sometimes we can trace their origin, backtracking through threads of thoughts and experiences. Sometimes, they seem to materialize out of thin air. At times, we can clearly see how an idea grew on top of another. At other times, the idea seems to be radically, even inexplicably, groundbreaking. We can be sure of two things: as long as humans exist, ideas will keep coming, and as long as humans exist, we will often look with suspicion at new ideas – or be strangely attracted to them.

Disciples Arrive

While others are still suspicious, some are intuitively and emotionally attracted to a certain new idea. They may not be able to say why, but something draws them in. Maybe the idea seems to be a solution to the challenges they currently have. Maybe the idea just sounds right. Whatever it is, it is drawing some people in more strongly than others. Some of these first comers become disciples – students of the originator of the idea.


In the beginning, there is no written curriculum, no rulebook to follow. The originator and the disciples gather and talk. The idea is still fresh and pliable. As the conversations go on, the idea evolves. Provoked by new insights from both originator and disciples, it mutates from its original form into something new. Because this happens in conversation in the group, the idea is the shared property of those who participate, and there seems to be unity around what the idea is – even though it cannot always be described exactly.

Spreading the Word

The lack of clear rules doesn’t deter the disciples. Eager to let more people see the brilliance of the new idea, they get to work on spreading it. More conversations ensue – in slowly widening circles. Some of the new people who learn about the idea decide to take part in spreading it further.


The new idea has taken root. It now seems to be spreading almost by itself. The originator and the disciples are no longer in control of the spreading. They are happy that the idea is catching on, but a few of them also worry. Some new people seem to misunderstand the idea. Even worse: there are now people who claim that they understand the idea, yet misrepresent it entirely when teaching it. Some of the disciples say that things are spiraling out of control.

A System is Born

Realizing that they are loosing grip of the idea, the originator and the disciples gather to discuss a solution. They that the idea needs to be more clearly described, so that new students can be steered in the right direction. Gradually, some things are clarified. But some things also seem to be lost in the process. Some of the disciples consider this a price worth paying – after all, they all want the idea to spread. Others quietly wonder if the frenzy to specify what the idea is about is making the idea itself disappear.

Rules and Robes

A system of clarifying rules is now in place, but maintaining it is no easy task. To make sure the rules are followed, new roles, ceremonies and symbols are introduced. Those assigned a role in the system play a part that is very different from the disciples. Instead of focusing on the original idea, the perspective of these role-players is that of learning and spreading the rules of the system.

As time passes, the players become further and further removed from the idea itself, and more and more attached to the growing set of rules. As the rule set grows, it becomes increasingly difficult to learn for those who cannot spend all their time studying it. This gives the maintainers of the rule set a clear advantage: they can now claim supreme insight – and their deep knowledge of the rules seems to prove it. They are given a title to carry, maybe with some symbolic item (possibly clothing), that make it clear that they and no one else are the keepers of the truth.

These interpreters of the message now make up a formidable layer between the original idea and newcomers. Ask us, they say, because we have the answers. Thinking for yourself will only lead you astray – it is too hard for you. Even dangerous.

Rewards and Punishment

Now far removed from its original form, the original idea is no longer a spark of inspiration. It has mutated into a stagnant rulebook, maintained by those who have made it their task to uphold the rules, whatever the costs may be. As both the number of rules and number of followers keep increasing, the likelihood of rule violations is also bound to grow. To maintain respect for the system, the maintainers devise systems of rewards and punishment and assign themselves the right to dole them out. Many of the new followers appreciate this – after all, they didn’t come for the idea, they came because they were attracted by the structure and order of the rule system.

Splits and Branches

As the burden of what is now a strict system of compliance increases, some followers can no longer accept the situation. They decide to form their own branch of the system, giving them room to adapt the rules to their liking – and to put more deserving people into positions of power. Soon, multiple schools exists, and relations are not friendly between them. There seem to be no limit to the amount of energy and time that can be spent on debating which rules are the best. Some find this entirely satisfactory; debating their adversaries has become their new mission. After all (they say) the One Truth must be defended, or it may become tainted.

Heresy: a New Spark

With multiple schools of thought and multiple rulebooks in play, the system has become all-encompassing. Its controls seem to reach all, but that is only an illusion. As its grip has widened, it has also loosened. Below the surface of polite compliance, free thoughts of resistance are bubbling, provoked into existence by the very system that sought to keep them out. One day, a new idea stands out so powerfully that some people find it irresistible, even given the risk of dire consequences for those who choose to speak about it. A small and still secret group of heretics gathers to talk about the idea. The life of the idea is over, and immediately starts all over again.

Managing as Helping

Are you a manager, or maybe an informal leader with implicit influence and responsibility? Have you considered how you think about your role? Have you considered thinking about yourself as a helper?

If you’re reading this, chances are you’re working in a knowledge-based organization: an enterprise that builds its success on being able to convert human motivation into creative ideas, and then use the best of those ideas to develop useful products and services.

Knowledge-based organizations are hard to manage, because people are hard to manage. Highly educated and creative people might be especially hard to manage, because they have high expectations when it comes to being managed in the right way.

How you see the role of management is going to be a major factor in deciding whether you end up managing in a way that’s helpful to people in your organization or not.

If there’s one thing the modern organization does not have room for, it’s unhelpful people. We may have room for freeloaders (you’ve been one too, at times in your life), assholes (you’ve been there too, especially if you think you’ve never been seen as one), and incompetents (in some things you should be incompetent, otherwise you’re just cruising).

However, I don’t think we have room for unhelpful people. Success as an organizations comes from creating a web of interactions – also known as helping each other. Here are some telltale signs that might indicate that you are currently not as helpful as you could be:

  • When somebody asks for help, you don’t help them. Well. That one’s pretty obvious I guess. Just remember that’s its easy to fool yourself. You may be presenting yourself with solid reasons why not helping is the right thing to do. Look closely at those reasons, and remember that there is more than one way to help. To begin with, helping does not necessarily mean taking on a task someone else should rightfully do – nor does it mean giving direct answers. Which takes us to point number two:
  • You give help by taking over the task completely, thereby robbing your colleague from the opportunity to learn to do the task. In knowledge organizations, eliminating learning is a cardinal sin. Therefore, this kind of helping isn’t very helpful.
  • You consider some tasks to be beneath you. Maybe you think that you no longer have to visit the development teams. After all, you paid your dues long ago, and now you have team leads or scrum masters or agile coaches or whatever working with the teams. They’re doing the floor work and report to you every now and then. But how can you possibly claim to manage work that you are so separated from? Don’t be afraid to go out there. Look at what’s really happening and learn, learn, learn. Then provide help.
  • You listen to people’s requests for help, then say: “I’m sure you can figure out a way to solve it”. Of course they can – but they came to you asking for help. Asking for help is not an easy thing to do. It puts you in a vulnerable position (which is why those who most need help may be least likely to ask for it). When somebody comes to you and asks for your help, you should see that as a sign of trust being extended. This is the moment when you can truly make a difference. Don’t throw that away.
  • You inflict help where help is not asked for. That’s not helpful, and will lead to resentment. You can’t help someone who does not want to be helped. I remember discussing this perspective on helping with a group that included a social worker. She was offended by the suggestion that help must be wanted. In her line of work, she said, help often had to forced upon people who aren’t asking for it, like addicts for example. In the end, someone asked her if she had ever had long-term success in helping an addict that didn’t want to go clean. She looked sad, sighed, and said no.
  • You don’t ask for help. As a manager or informal leader, your behavior sets the tone. You are a role model. If you are not able to ask for help when you really need it, why do you think others should have that ability? But wait, you might be thinking, what if I simply don’t need help? If you think that, then you’re beyond what I can help you with through a text like this. All I can say is this: what on Earth makes you think you don’t need help?

If you want to learn more about managing as helping, my recommendation is that you buy and study Ed Schein’s book “Helping”. It’s written in very plain and understandable language. Don’t be fooled into thinking that makes the topic easy. Helping is really hard work – but it’s also very rewarding.