Tobias Fors

Category: Leadership

  • 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?

  • 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.
  • Prioritizing Effectively as a Team

    Prioritizing Effectively as a Team

    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.”

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

  • 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.

  • The Worst Daily Scrum Ever

    The Worst Daily Scrum Ever

    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?

    If you liked this article, you may also like

  • What Is an Advanced Scrum Master?

    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?

    If you liked this article, you may also like

  • The Freedom to Solve Problems

    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.’”

    Going Boss-free: Utopia or ‘Lord of the Flies’? – Knowledge@Wharton.

  • There’s Always One [Drop|Comment|Question] Left

    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.