Tobias Fors

Tag: agile

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

  • Rolling Out Scrum – How Hard Can It Be?

    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.

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

  • Common Pitfall: Planning Alone

    Many organizations forget that planning is all about the planning. You’ve probably heard the saying: “The plan is nothing, the planning is everything”. For me, that means that the process of planning itself is, to a large degree, what creates belief in and understanding of the plans. The plans will break anyhow (we’ll still do our best to create them), but the more we participate in creating them, the more we believe in them, the more we take ownership for them, and the greater is the chance that we will reach our goals.

    It’s both easy and hard to do this. The easy part is what typically needs to happen. The hard part is gaining acceptance for it, and facilitating the process effectively.

    Gather all the people in a room. Let someone who understands the business side of things start out by explaining what needs to be achieved. Invite everyone else to ask questions. Make it safe to do so. Use your tricks of the trade to make the interactivity happen. Silent brainstorming is one powerful technique; ask participants to silently write down their questions and comments on cards, then work through these together. If you’ve ever presented something to a large group and then asked “any questions”, only to be met by compact silence, you know why a technique like this can be very useful.

    With the high-level goal presented and discussed, and with questions clearly captured on flip charts on the wall where everyone can see that their concerns have been captured, go ahead and work together on the plan.

    By now, there are many techniques in the agile community to make this easier. Collaborative story writing, planning poker, silent sorting, and story mapping are all popular. I’ve just started to learn about system anatomies, which seem to be a powerful way of working together on other views of the work to be done. Whichever techniques you choose, make sure to use them in a collaborative way. Therein lies the key to success.