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.

Is Thinking Allowed?

When I was still working as a contract programmer, I was on an assignment where the boss was from the United States. I didn’t meet him very often, but he seemed like a nice enough guy. One day, he surprised me though.

I was sitting in my chair, leaning back for a while with my hands behind my back. I was thinking about how to handle some little challenge with an XML schema I was struggling with. While sitting like that I heard (faintly at first) the sound of my American manager approaching. I could tell it was him, because his shoes made a specific and quite powerful clicking sounds on the hardwood floor.  Suddenly, he passed behind me. He never stopped, but he did shout at me:

”Hey Tobias, you’re not programming! Hands on the keyboard!”

When we sit and think, it looks like we’re doing nothing. This makes it hard to think in many organizations.

Doing is what it takes to change the world, but if we don’t think a little first, how can we know if we’re about to change it for the better or the worse?

Is thinking allowed in your organization?

This Week Online – Saturday, May 14, 2011

This week I managed to squeeze in three days of consulting and two days of public teaching. Side effect: less time over for reading. Still, here’s some of the stuff that piqued my interest online this week.

Bright and Terrible

Jay Yarow of Business Insider published a short post about what’s it like to fail at Apple. Not sure how fact based it is, but it makes you think about the challenges of managing risk and failure.

If you’re making too many mistakes, your company might not be around in a year. On the other hand, if you aren’t making any mistakes, you probably won’t be around in five. Why? Because making no mistakes means you’re avoiding risks entirely. Why is that so bad? Because risk is connected to reward. If you’re not taking risks, someone else is, and when they succeed, they’ll be ahead of you.

If you’re a manager who likes to chew out your management buddies, think about how that behavior is replicated by others in the organization. After all, you’re supposed to be some kind of role model.

Speaking of Apple, I also found a piece on Fast Company about the ever-accelerating smart phone wars.

Telling Stories Together

The next writer out also has a last name that starts with a Y: Adam Yuret. Adam shares the insights he’s gained after taking Elisabeth Hendrickson’s Introduction to Acceptance Test Driven Development. Specifically, Adam talks about the value of doing story workshops. In the end, Adam writes, we might not end up with a story chiseled in stone, but the shared understanding gained from a story workshop should reduce time lost to major changes and confusion later.

I couldn’t agree more. While I have only tiny experience from ATDD (a client of mine recently chose to go this way), I have lots of experience of facilitating workshops of different kinds. In my experience, the value of effective workshops is dual. First, we get the value of clarifying assumptions and laying out a clear plan of attack together. Second, we get the value of realizing that we’re actually in this together, and that we have the potential to work as a team. It’s plans and morale, both for the price of one.


Back in the eighties, my best friend’s dad sometimes took his Mac SE/30 home from work. We ended up exploring it’s every nook and cranny. Probably the best piece of software on it (aside from the game Dark Castle) was HyperCard. It was the precursor of the wave of multimedia development environments that rolled in during the nineties.

HyperCard was awesome. You could easily create interactive storybooks and simple applications with scripting. Ever since then, I’ve been waiting for a replacement with HyperCard’s impact. This, of course, is when more experienced software people feel obliged to comment that ”that myth of making everybody a programmer has been around since the beginning of computer’s”. Well, maybe it has, but it won’t be a myth once it’s true. Or, if it really is a myth, I still choose to believe in it.

Why would anyone want a tool that makes it easy to create programs? Why wouldn’t we? With computers, we’re sitting on the most incredible piece of universal machinery ever created. But, for almost everyone, the power of the computer is still locked away behind arcane programming languages.

The untapped demand for accessible development environments is evidenced by, for example, how Excel is frequently used to develop ad-hoc solutions to computing needs. Professional programmer’s would say that’s not using Excel but abusing it, but the fact remains: Excel might just be the most widespread non-programmer’s development platform. Heck, even people who now how to code for real create stuff in Excel, like Space Invaders, for example.

This week, a tweet flew by about something called WaveMaker. It sounded like an attempt to create just that kind of accessible environment, so I checked it out, and it turned out to be some kind of browser-based development environment. I just downloaded it now to have a closer look. I don’t think WaveMaker is what I’m dreaming of, however. I managed to create a simple ”Hello, world!” app in a few seconds, but that’s just because I used to be a programmer. All in all, this looks more like a programmer’s IDE than the everyman’s toolbox I’m dreaming of. That doesn’t mean WaveMaker isn’t awesome. It does mean that it’s not what I’m looking for in this regard.

What’s a Test Strategy?

My friend from the AYE conference, Fiona Charles, has a great new article out. It’s called ”Basics Revisited: Test Strategy”. In it, Fiona takes a clear and pragmatic look at what a test strategy is. Fiona takes a stand against huge documents filled with boilerplate text. Instead, she urges us to understand what it means to have a test strategy:

”A test strategy is the set of big-picture ideas embodying the overarching direction or design of a test effort. It’s the significant values that will inspire, influence and ultimately drive your testing, and the overall decisions you have made about ways and means of delivering on those values.”

Fiona also asks us to think about the medium we use to communicate our strategy:

”I have used one or some of: a mind map, sticky notes, a drawing on a board, a colorfully highlighted diagram, an outline document, or presentation slides. The choice depended on the organization I was working with and the nature of the test. Whatever medium you choose, it should work as a tool you can walk around with to talk to stakeholders, or use in meetings to promote discussion.”

Also on the testing side, I found this neat report from StarEast 2011, written by agile tester Lisa Crispin.

Stay Uncomfortable

Finally, Andy Hunt has some good advice for advanced agile practitioners: stay uncomfortable. If you’re starting to think you know what this is about, that may mean you’ve stopped thinking hard about how to developer even further.

This Week Online – Saturday, May 7, 2011

Here’s a mixed list of some of the things I appreciated online this week. They might turn out to be useful to you as well.

Fake and Shapes

Randy Rice published a blog post that listed different testing tools that came up during a tutorial session he hosted at StarEast 2011. I don’t work as a tester, but I’m fascinated by the field, and like to follow it from the sidelines. Plus, I love a smart tool.

One of the tools that stood out on Randy’s page was Fake (USD 29.95), an application that wraps a web browser with some Automator-like automation. I probably won’t be using it to automate tests, but I’m already keeping my eyes open for some boring web-related task to automate.

Lots of Mac software is made by small and creative software shops, so when I find a nice piece of software, I always look for other interesting offerings from the same developer. This time, I found Shapes. As with Fake, I haven’t tried it yet, but it looks interesting. I needed to help a client with some diagrams a year or so ago, so I bought a license for OmniGraffle. I can’t stand it. I will never learn to master it’s cluttered interface. Shapes might be what I need for those occasions where a napkin sketch isn’t enough. We’ll see. It’s only USD 4.99, so I could afford trying it on for size.

Balancing action and reflection

Esther Derby’s writings are thoughtful and balanced. This week, Esther published a piece called ”Fixing the Quick Fix”. In it, she argues for a balance between deciding and act fast and decisively, and not acting before you have understood the underlying problem.

I know from my own work with clients that this can often be hard to discuss. It’s not uncommon for organizations to be in constant conflict over this. On one side of the battlefield, department A wants to see higher speed in execution. They are wondering why nothing is happening. On the other side, department B wants things to slow down. They wonder why the organization has to spend so much time fire fighting, and so little solving the true problems.

What makes it hard to discuss this? Well, depending on where we’re coming from, we look at speed in different ways. An experienced and skilled agile team, for example, will think it perfectly natural to execute in high speed. They can move fast, in controlled formation.

A less experienced, less skilled team, will struggle to move fast. They don’t yet have the knowledge and understanding they need to speed up. Asking them to ”just move faster” is a recipe for disaster.

Do you know which of these situations most resemble your current workplace? This is where the questions Esther poses in her article come in handy. They are about uncovering the facts of the situation, so that you can take appropriate action. This too, is hard work, and follows the same laws of speed as everything else. If you’re skilled at asking them and if there is trust between you and those you ask the questions to, then gathering this information will be less of a struggle. When you do it for the first time, there is some risk that other will see you as the one slowing things down: ”If it weren’t for all your questions, we’d already be done with this”.

Esther’s article also goes into what you could do once you have a better understanding of the current situation. Specifically, Esther advises us to see if we can back up our ideas with hard data. This too, is often challenging, in my experience. Many organizations won’t be able to produce the numbers you need, because they do not yet operate in a way that makes extracting such numbers possible. Still, trying to get some data and finding out it can’t be done, is also valuable. It tells you a little bit more about the organization.

By now, you might you’re ready to decide. Hold it for just a little longer. Take Esther advice one more time, and generate at least three options. Generating options is a key part of any creative process. We don’t always have to be super creative, but we do need creativity at all times. Without creativity, companies end up being about as good as, or worse than, their competitors, and that’s no fun way forward. One of your options now is to escape from this weekly summary and dive into Esther’s excellent article.

Innovations in Management

Via John Seddon’s regular news letter, I found a blog called ”Gary Hamel’s Management 2.0”. You might have read it already, because apparently Hamel is a big management guru in the States. Somehow, I’ve managed to miss him completely. By the way, if you’ve already read Jurgen Appelo’s ”Management 3.0” book, it might seem that Hamel is running behind, version number wise. I’m sure Hamel will upgrade soon. Probably to 4.0.

Anyway, the reason Seddon mentioned Hamel was that one of Seddon’s clients – Owen Buckwell – has been awarded a prize instituted by Hamel, for his work in transforming the housing services organization he manages.

Apparently, Hamel has started something called the Management Innovation eXchange, which aims to highlight potential game changers in the field of management – and that’s what I wanted to tip you about. Pay a visit to the Management Innovation eXchange site, there’s bound to be something there that can inspire you.

How to Start Up …

Speaking of management, I have to share this link to a blog post that contains, essentially, a checklist for how to start a web company. All you have to do is follow the steps. I might try that some day. In a way, it still managed to inspired me a little bit, even though it reminded me of Paul Davies’ absolutely wonderful book How to Build a Time Machine. It’s pretty easy if you know how to do it.

… and how to start starting

Finally, for this time, I learned about the book ”The War of Art”. I believe I read about it in Kent Beck’s Twitter stream. This book is about resistance, specifically the kind of resistance that rears it’s ugly head whenever we want to start some kind of creative endeavor. I bought it for my Kindle, or rather for my iPad’s Kindle app and started reading last night. It’s a very smooth read, which is kind of funny considering the topic of the topic. There’s no resistance in reading this book about resistance.

I guess the advice in the book gave me a little push, since I sat down to write this Saturday morning post, just as planned.

Also, speaking of resistance, I found my way back to one of many great pieces by Dale Emery on the topic. It’s called ”People Resist Change?”, and deals with how we related to change. An absolute must read if you ever deal with change. I guess you do.

I’ll let that be it, for this week.

Some Help Examining Your Engineering Practices

At Citerus, I worked with my colleagues to create a basic form we can use to take a quick inventory of the current engineering practices in the teams we work with. It was originally in Swedish, but I just translated it into English for use at a client.

We’re not dogmatic, so neither is the form. Nor do we think that anything goes, so there are lots of opinions built into the form. Use it at your own risk. The least it could do for you is to act as a conversation starter.

So, the form can get your team talking about engineering practices. There are many ways to use the form, and we don’t prescribe a specific way to use it. Among the ways I’ve heard it’s been used are these:

  • Someone used it as a thinking tool for himself
  • The members of two teams filled out the form individually, then got together to compare and discuss their answers
  • One team answered the questions together, and discussed as they went along
  • A manager used the example questions in each section to create a detailed questionnaire, and published it on a web based tool

The document is available as a share on Google Docs, from where we might update it from time to time. Google Docs isn’t very capable when it comes to formatting, so the lines and page breaks I’ve tried to put in might or might not work for you.

We’re publishing the document under this Creative Commons license:

Creative Commons License
Examine Your Engineering Practices by Tobias Fors is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Here’s the form: Examine Your Engineering Practices

Sketchnoting the Concept of Flow

I like to take stuff and try to express it in as simple language as possible. That’s my way of checking my own understanding of a concept. One concept that comes up often when we talk about lean software development, kanban and agile is that of “flow”. A couple of days ago, I decided to process that a bit.

One technique I use to process stuff is to sketchnote in Brushes on the iPad. Here’s the video output from my sketchnoting a basic explanation of the concept of flow in development.

What techniques do you employ to process stuff you want to learn well?

Thinking Tools for Conference Reviewers

Recently, I’ve been reviewing session proposals for Agile 2011. It’s a rewarding job, even though I’m not getting paid for it. I was asked to help out, and said yes because I knew I would learn a lot from it. Since this is the first time I’m reviewing sessions like this, I started out by doing some research into what to look for.

As a reviewer, my job is not to accept or reject proposals. So what is it? Well, my assumptions while reviewing sessions have been that the purpose of my review is to:

  • increase the chances of the proposal becoming accepted
  • help the session be useful for its participants
  • make the session easy to understand and select for participants

I already have way too much information inside my head. Reviewing conference proposals from a bunch of very smart people seemed like something that would fill my brain right up and jam it. Therefore, I realized I needed to use some kind of tool to manage the review process. It’s really not different from the monkey that decides to use a stick to get to the banana. I just needed to find the proper stick.

Right now, my favorite thinking tool is the framework. For example, I just love Esther Derby’s and Diana Larsen’s retrospective framework. It’s versatile and powerful, and I can plug all sorts of fun work right into it. I realized what I needed was a framework for my work on reviewing sessions. However, I also needed to get started on the reviews. For that reason, I pulled out what might be the most basic framework of all. After all, thinking up frameworks can be the ultimate yak-shaving activity, I didn’t want to go there. I’m busy enough as it is.

I don’t know if it already has a name, but I’m naming this basic framework anyway. I’m going to call it the Common Questions framework. You already know the Common Questions, so this won’t be news to you. Here they are:

  • Why?
  • Who?
  • What?
  • How?
  • When?
  • Where?

For the review work, I settled for the first four questions: why, who, what, and how. As I researched and reflected on what to look for (Mark Levison sent me some tips, and a link to a great post my Mitch Lacey) I sorted the things I found into the above four categories. I also added one final thing: my bottom line, a super brief summary of my full review. If I can express something very briefly, that probably means my thoughts are clear to me. If I can’t, that’s my signal to think some more.

Here’s how I use these questions. Having read a proposal, I scan through the questions and write things down as they pop up in my head. Having done a first pass, I work through the questions one by one again, this time going back to the proposal and looking for answers to each question, which – of course – I write down. The set of text snippets I get from this isn’t necessarily very easy to read, so I end the process by working them all into a text that flows reasonably well from start to end. Finally, I try to summarize my thoughts in a single sentence.

I posted these questions to my fellow stage reviewers in case they could be useful to someone else but me, and to get feedback on them. A couple of the other reviewers suggested that I publish this as a blog post as soon as possible, as a resource to would-be submitters to Agile 2011. I would have done it sooner, but this week has been crazy.

In case someone still finds use for it, here’s my set of questions.

– – –


The title and introduction will be used to “sell” the session to participants, so they need to not only clearly explain the session, but also read smoothly. The title and the intro will be used in the public conference schedule.

  • Does the title help me see if this session is for me?
  • What about the intro – can I make a first judgement if this fits for me, based on it?
  • Are there intended learning outcomes? … and does it seem like the session design will lead to those?
  • Does anything more need to be said about the session’s clarity of purpose?


Quality is value to some person, therefore, we need to know who the session is intended for to be able to judge quality.

  • Do I understand what the intended audience is, and how they would benefit from this session?
  • Are specific roles mentioned? If not, how is the audience explained?
  • What is said about the number of participants?
  • Does the stated level (beginner, expert, etc) seem right? In other words: is this session really for beginners/experts/etc?


What are the contents of this session?

  • Are the contents specific? … or is it hard for me to understand what will really happen in the session?
  • Is the topic about agile?
  • Is the topic timely, fresh, and unique? … or is it old, stale and has been done too many times before?


What can be said about the process to be used in this session? (Also referred to as “mechanics”)

  • Does the description match the stated format? Formats can be, for example: workshop, tutorial, talk, etc.
  • Is the text well written and well organized?
  • Does the size of the proposal match the size of the session? In other words: if it’s a longer/larger session, is the amount of detail greater?
  • How will the host be able to scale the session up and down as needed? The number of participants can turn out to be smaller or larger than expected.
  • If the session is big and long: is there more than one host to help make it work?
  • Does the session format model what is taught? For example: Talking about coaching is less helpful than practicing it.
  • How is interactivity handled?
  • Previous experiences with this? Has the session been run before by this host? What is the speaker’s experience level? Any references available?
  • Is there a brief but clear speaker bio, that helps me judge if this session host fits me?
  • In general, does the design seem feasible?

My Bottom Line?

– – –

Do you have experience of reviewing conference sessions? What are your best tips? What do you think about the questions above?

Programmer Productivity?

I’ll admit I’m a bit confused. Do we still believe that it’s meaningful to talk about the productivity of individual programmers?

Assuming we had some agreement in our business as to how exactly one should measure the productivity of a programmer (we don’t), what good would it do us?

Let’s say we discovered that he most productive programmer is 6.7 times more productive than, wait, than who? Than the average programmer? Than the worst programmer? I don’t know, but let’s pretend we did know, and had learned that 6.7 was the magic number. What would we do with that number?

Could we use it to find and hire the most productive programmers? How would we go about that? Should programmers add their productivity factor into their resumés? How often should they update it? When should they measure it? On their best day? On a day when they’re performing at their average level? Maybe going for an average over the last 12 months would be most useful? Seems a bit convoluted, doesn’t it?

How about using it to evaluate employees? What would that be like? Should an average programmer that happens to be in a stellar team get to reduce his factor, so he doesn’t look better than he really is? What about a star programmer in a mediocre team? How would we calculate his adjustment factor? After all, it wouldn’t be fair if his productivity score was harmed because he had to work with programmers worse than him.

Seriously, folks. We know the answer to this silly riddle by now. Productivity in software development isn’t controlled just by the individual, it is controlled by how several individuals interact with each other.

If you are, or have been, a programmer, you might recognize this situation: there’s a tight deadline, but nothing’s getting finished, because you’re spending all your time training the new hires that were brought in to help you hit the deadline. If that’s never happened to you or someone you know, maybe this situation is familiar. You have several really great programmers on your team, but nothing’s getting finished, because they’re all busy either quarreling or not speaking to each other at all. Yes, individual programming skill matters greatly. So does the ability to work effectively with others. It’s not either or, it’s both. And that’s still not enough. To be productive, programmers need a supportive environment, and I don’t mean (just) nice colleagues. I’m talking about being in an organization designed to maximize the effectiveness of those who work in it. My guess is that’s not an organization obsessed with measuring the productivity of individual programmers. It’s an organization obsessed with delivering great results, and having a
great time while doing it.

Writing: It’s Not Just About Writing

I try to write regularly. I write a lot more than I publish, and that’s OK for now. I’d like to publish more in the future however, so I keep trying to improve my productivity. One thing I’ve found that helps, is to do something that moves a writing project forward, even if it’s not really writing per se.

What I do is I work on structuring things I’ve previously written. I’ll typically look through my project in my writing tool of choice, and look for areas that need some cleaning up. Then I’ll go ahead and move stuff around, clean out stuff that no longer feels relevant, or even do a little bit of editing.

Every now and then, this not-quite-writing activity triggers something inside of me, and I get an idea. Once that precious idea pops up, I can easily write for some time. Conclusion: not all about writing is writing, but in the end, writing is what it’s all about.

Too Much Talk About Methods

I believe there’s too much talk about methods, and too little about how they are introduced. Methods can be very helpful, especially when used mindfully. What does that mean? To me, using a method mindfully implies, among other things, introducing it in the right way. The right way for me is with minimal hype and maximum participation of all involved. We believe in what we co-create and co-discover.

Have you been force-fed a way of working? What was that like for you?