Tobias Fors

Category: Agile

  • The Value of Recreational Programming

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

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

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

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

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

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

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

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

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

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

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

  • 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

  • Broken Software

    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.