My new article “Prioritizing Effectively as a Team” is up on AgileConnection.com. 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.”

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.

Conversations

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.

Growth

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.

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.

I once observed what was probably the worst daily scrum ever. Just when I thought it was over, something interesting happened.

I once observed what was probably the worst daily scrum ever. Just when I thought it was over, something interesting happened.

Visiting a team in an organization I worked with, I got to see one particular scrum master run a daily scrum – into the ground. This is the story of how he did that – but it’s also the story of how the team miraculously survived this train crash of a meeting.

Every morning, the team would gather around a large whiteboard, where the scope for the sprint and the relevant tasks were posted in the form of a bunch of sticky notes. The meeting would not begin until the scrum master, literally, pointed at a person, and asked:

– “What have you been doing since yesterday?” Upon hearing this, the indicated person would give a very brief account about what tasks had been worked on.

Then, the scrum master proceeded by asking:

– “What will you be doing today?” Again, a short answer, which seemed mostly directed at satisfying the need to say something in response to this direct question.

The third question asked by the scrum master was:

– “Do you have any impediments?” I noticed that the answer to this was always no, for all members of the team. I knew this answer couldn’t be true, because this was a team that struggled mightily every single day.

When I thought it couldn’t possibly become any worse, the scrum master fired off one last and revealing question:

– “Do you have any hours to reduce”

At first, I was surprised by this very direct way of trying to make the burndown point downwards, but it dawned on me that it was perfectly congruent with the scrum master’s unspoken goal: to preserve the illusion of control. The answer to this fourth question would go along these lines:

– “Hours to reduce? No, not really. But, I guess I have been working on this task a bit, so let’s see. Yesterday, the estimate of remaining time was 16 hours. I guess it’s about 14 hours left now. No, 13 and a half.” Hearing this, the scrum master nodded and smiled, and noted the change in his notebook.

Directed by the scrum master, the team continued in this fashion in a round-robin style. Whenever “some hours were reduced”, the scrum master would nod approvingly and take some notes.

I could hear no requests, and no offerings of help. No really valuable information seemed to be surfaced. Energy seemed to be at a rock bottom low.

Then something interesting happened.

The scrum master declared that the meeting was over, and turned his back to the team to work on his notes from the meeting. Because his back was now turned to the team, he never really witnessed what happened next.

With the official part of the meeting over, the team suddenly seemed to come alive. They suddenly huddled together and started a lively exchange about their plans for the day. One person would suggest a course of action, and someone else would fill in with some additional information. Someone asked a question, and others jumped in to answer it.

With the directive scrum master out of the game, the team took the reins and did what needed to be done to lay the groundwork for working together during the day. They performed an effective daily scrum. Energy was high, information flowed, and when needs had been met the meeting was over.

This real scrum went on for just a few minutes, with me watching in amazement. The scrum master never saw what happened. I know, because I asked him afterwards:

– “Did you see what happened after you ended the meeting”?
– “No.”
– “The team came together and sorted out the day.”
– “OK.”
– “Do you think you need to change the way you run the meeting?”
– “No. It works for me.”

How’s your daily scrum? Is it working for you? How about for the rest of the team?

Being a scrum master is more than just reminding a team to perform certain ceremonies, it’s about growing the best possible workplace.

To begin with, let’s clarify this whole thing about the “scrum master”. It’s the name of a role. It’s a relatively new and pretty ridiculous name by intent, because a change was needed in how we lead development work.

Every now and then we shake things up by inventing new names. Just remember that behind the term “scrum master” is the timeless idea of the servant leader. Someone who is there not to exert power over others, but to give power to others. To empower them.

I don’t know how long the term scrum master will hang around. I do know that I want what it represents to stick for the long run. For now, I’ll allow myself the use of the possibly even sillier expression “advanced scrum master”, but bear with me, at least for the length of this post.

After having served as the scrum master for a team some years ago, a newly hired person was assigned to pick up the task after I moved on. We talked often during the transition period, but I really only remember one of those conversations.

We were sitting comfortably and discussing the way we were working, when my new colleague asked me something that surprised me. He said:

“Tobias – I don’t understand how this scrum master thing can possibly be a full time job. I can see how I need to invite people to the meetings, and work a bit with the product owner – but that will hardly take upp all my time. What am I supposed to be doing?”

I was a bit stunned, because that thought had never struck me. From my perspective, the list of things you can choose to work on as a scrum master is endless. After all – how many teams have you met that were as productive, creative, and happy as they could possibly be? There’s always one more thing to address (including pacing the rate of change).

What I’m saying is this: the scrum master role is as challenging and rewarding as you make it. You can definitely improve your ability to create positive results by gaining deeper skill and insight. Here are some things that I can think of that I would expect from a more advanced scrum master. I’m sure you could add many more to my list:

Mindfully asking powerful questions to assist learning

Helping the team find the time for learning

Supporting the team in increasing its skill

Working with the team to grow clear and simple processes and agreements that truly help

Looking far outside the scrum and agile canon to find new things to learn and try in fields such as agile engineering practices, psychology, organizations, testing, change, teams, learning, culture, consulting, systems, problem solving, and design (to name just a few)

Spending a whole lot of time working with the people in the organization surrounding the team, since that’s often the most powerful force shaping the team’s behavior and results

Gradually helping more parts of the organization to understand and make use of the scrum mindset of cross-functional and transparent work

Helping managers understand how to serve better

Constantly working on developing him- or herself, realizing that the most powerful tool you have at your disposal is yourself

Last but not least, I would expect to see the advanced scrum master working on helping others learn how to do all of the above, so that the power to lead can spread. After all, we can’t let the organization’s future depend solely on somebody called a “scrum master”, can we now?

How would you know that you had just seen an “advanced scrum master” in action? What would that person be doing, and how would it make things different?

I sometimes hear the agile manifesto being criticized for focusing on “just working software”. It’s said that working software is not enough, that we need to reach further. I agree that we need change, but not in the wording.

If your definition of working software is “if it compiles, ship it”, then the manifesto’s words won’t seem like they change much. For you, the manifesto sounds like business as usual.

Twelve years after first reading it, the agile manifesto still doesn’t sound like business as usual to my ears.

Here’s the thing. I really like software. Really. I always have, ever since I used my first computers as a small kid. I guess computers and software filled a spot for me.

I don’t like all software. I like software that does its job and is a pleasure to use. I’m on a continuous quest to find more software like that, but many of the apps I try suck.

It’s not working software if it doesn’t work for me. Then it’s broken software.

As a user, I’m not content with software that works in the sense that “all functions are there, but that’s about it”. If it does the job, but is a pain to use, I don’t think of it as working software. I may even come to hate it, because now I know that the software could have worked, but its creators didn’t care enough to make it lovely to use.

When developers lack a passion for the user, the result can never be working software. Instead, we get broken software. Broken software is not working software.

For me, the problem is not the expression “working software”. That makes perfect sense. The problem is that some software makers still have a broken definition of what working means.

When I kick off a class or workshop, I want participants to engage as soon as possible after entering the room. I do work through some practical bits first, but after that I quickly hand things over to participants.

For a long time, I’ve been using an opening exercise I learned from Ken Schwaber. In it, I ask participants to sort themselves along a line in the room, according to different criteria.

First, I ask the group to sort itself according to how effective and efficient their current project is (in Swedish, a single word has the connotation of both “effective” and “efficient”). Once sorted, people take turns sharing their situation. Doing this, participants come to see what a wide range of different experiences are present in the room.

After this, participants get to sort themselves again, this time according to the level of energy they perceive in that same project. Really low energy in one end, and high in the other. We talk about it again.

Finally, we do the same thing, this time based on how much experience and knowledge of Scrum the participants feel they have.

Earlier this summer, I participated in a terrific one-week workshop with organizational development pioneers Charles and Edie Seashore. The name of the workshop was “Intentional Use of Self”.

In one part of the workshop, we talked about how check-ins are an important part of helping a workshop group come together. We also did check-ins every morning. One format we used was based on a fishbowl. Charles and Edie would ask one small part of the group to step into the middle, and tell each other about some thing.

Today, I decided to try this format out. I asked people in the class to step into the fishbowl based on how long they had been using Scrum.

First, I asked those with no experience to step in and talk to each other about their current situation and their expectations for the course. After that, those with a few months of experience got to share. Then those with up to a couple of years experience.

Finally, those of us with longer experience (I joined the fishbowl myself here) stepped into the inner circle a told each other about our experiences and expectations.

Here’s what I like about Charles’ and Edie’s check-in:

Participants face each other, not just me

In a circle, it’s easier to speak up

When you do speak, you speak with a smaller group

Everyone else can still hear you

The fishbowl circle puts more emphasis on the likenesses we share, whereas the line creates an exposed situation for those on the ends of a line.

We still get to see the different experiences available in the group

It’s a simple but powerful check-in format. I’m fascinated by the fact that I had to travel half-way around the world to pick it up. I’m glad I did.

Do you facilitate workshops or teach classes? Do you use check-ins? What kinds of check-ins have you tried so far?

Isn’t it really sad that employees in some companies aren’t allowed to solve the customers’ problems? In Sweden, the major telecom operators are notorious in this regard, in my personal experience.

What is it like in your company? Is everyone allowed to and capable of really helping your customers?

“In addition to encouraging creativity, bossless environments also increase efficiency, according to Stephen Courtright, a management professor at Texas A&M’s Mays Business School. He cites the example of Southwest Airlines, which allows baggage clerks the freedom to decide how to solve a customer’s complaint on the spot, without having to say, “‘Wait while I consult my boss.'”

My childhood friend’s mother was a “dagmamma”, literally, a “daytime mother”. In other words, she took care of a bunch of other people’s kids in her own home.

She was a very kind and intelligent person. One of the things she said has stuck with me to this very day.

“There’s always one drop left.”

She would say this when we had had finished our “fika” (for kids in Sweden, this would be strawberry juice and cinnamon buns) and we would start playing with our empty glasses. Or rather: we thought the glasses were empty, but she knew better. That’s why she reminded us.

I think of this every now and then when facilitating a meeting or a workshop. Whenever you ask for comments and questions, there comes a point where the contributions start to taper off. Silence commences. This is where you as the facilitator or convenener should stay quiet, too. Because, to paraphrase the wise dagmamma:

“There’s always one comment left”

Keep quiet. Count to twenty in German *) to focus your attention on something other than the heavy silence, and lo and behold. One more reflection always pours out.

*) Silently, that is. If you experiment with counting loudly in this situation, let me know what happens. I haven’t tried it yet.

Posts navigation

Privacy & Cookies: This site uses cookies.
To find out more, as well as how to remove or block these, see here:
Our Cookie Policy

Who is Tobias Fors?

I'm a full stack management consultant with the Swedish consulting company Citerus. I help other people succeed in leading software development. In my work, I help teams and organizations be more effective and ship software.

Let’s connect!

I find Twitter to be an excellent way of staying in touch with professional colleagues. My posting pattern is "low noise, high signal".