Beyond Method – Tobias Fors

The Value of Recreational Programming

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 …

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 neary would be a better word, 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.

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:

Draw the canvas on a big whiteboard
Put on your facilitator hat
Choose an aspect of your software development work to explore
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.

The Birth, Death, and Rebirth of Ideas

Watching the waxing and waning of software development methodologies made me think about the lifecycle of ideas. Throughout the ages, humans have come up with ideas. Some ideas never become more than a thought. Others spread globally, affecting people for a long time. The life of ideas seems to be an eternal cycle of birth, life, death, and rebirth.

The Spark

Who can tell where ideas come from? Suddenly they appear. Sometimes we can trace their origin, backtracking through threads of thoughts and experiences. Sometimes, they seem to materialize out of thin air. At times, we can clearly see how an idea grew on top of another. At other times, the idea seems to be radically, even inexplicably, groundbreaking. We can be sure of two things: as long as humans exist, ideas will keep coming, and as long as humans exist, we will often look with suspicion at new ideas – or be strangely attracted to them.

Disciples Arrive

While others are still suspicious, some are intuitively and emotionally attracted to a certain new idea. They may not be able to say why, but something draws them in. Maybe the idea seems to be a solution to the challenges they currently have. Maybe the idea just sounds right. Whatever it is, it is drawing some people in more strongly than others. Some of these first comers become disciples – students of the originator of the idea.

Conversations

In the beginning, there is no written curriculum, no rulebook to follow. The originator and the disciples gather and talk. The idea is still fresh and pliable. As the conversations go on, the idea evolves. Provoked by new insights from both originator and disciples, it mutates from its original form into something new. Because this happens in conversation in the group, the idea is the shared property of those who participate, and there seems to be unity around what the idea is – even though it cannot always be described exactly.

Spreading the Word

The lack of clear rules doesn’t deter the disciples. Eager to let more people see the brilliance of the new idea, they get to work on spreading it. More conversations ensue – in slowly widening circles. Some of the new people who learn about the idea decide to take part in spreading it further.

Growth

The new idea has taken root. It now seems to be spreading almost by itself. The originator and the disciples are no longer in control of the spreading. They are happy that the idea is catching on, but a few of them also worry. Some new people seem to misunderstand the idea. Even worse: there are now people who claim that they understand the idea, yet misrepresent it entirely when teaching it. Some of the disciples say that things are spiraling out of control.

A System is Born

Realizing that they are loosing grip of the idea, the originator and the disciples gather to discuss a solution. They that the idea needs to be more clearly described, so that new students can be steered in the right direction. Gradually, some things are clarified. But some things also seem to be lost in the process. Some of the disciples consider this a price worth paying – after all, they all want the idea to spread. Others quietly wonder if the frenzy to specify what the idea is about is making the idea itself disappear.

Rules and Robes

A system of clarifying rules is now in place, but maintaining it is no easy task. To make sure the rules are followed, new roles, ceremonies and symbols are introduced. Those assigned a role in the system play a part that is very different from the disciples. Instead of focusing on the original idea, the perspective of these role-players is that of learning and spreading the rules of the system.

As time passes, the players become further and further removed from the idea itself, and more and more attached to the growing set of rules. As the rule set grows, it becomes increasingly difficult to learn for those who cannot spend all their time studying it. This gives the maintainers of the rule set a clear advantage: they can now claim supreme insight – and their deep knowledge of the rules seems to prove it. They are given a title to carry, maybe with some symbolic item (possibly clothing), that make it clear that they and no one else are the keepers of the truth.

These interpreters of the message now make up a formidable layer between the original idea and newcomers. Ask us, they say, because we have the answers. Thinking for yourself will only lead you astray – it is too hard for you. Even dangerous.

Rewards and Punishment

Now far removed from its original form, the original idea is no longer a spark of inspiration. It has mutated into a stagnant rulebook, maintained by those who have made it their task to uphold the rules, whatever the costs may be. As both the number of rules and number of followers keep increasing, the likelihood of rule violations is also bound to grow. To maintain respect for the system, the maintainers devise systems of rewards and punishment and assign themselves the right to dole them out. Many of the new followers appreciate this – after all, they didn’t come for the idea, they came because they were attracted by the structure and order of the rule system.

Splits and Branches

As the burden of what is now a strict system of compliance increases, some followers can no longer accept the situation. They decide to form their own branch of the system, giving them room to adapt the rules to their liking – and to put more deserving people into positions of power. Soon, multiple schools exists, and relations are not friendly between them. There seem to be no limit to the amount of energy and time that can be spent on debating which rules are the best. Some find this entirely satisfactory; debating their adversaries has become their new mission. After all (they say) the One Truth must be defended, or it may become tainted.

Heresy: a New Spark

With multiple schools of thought and multiple rulebooks in play, the system has become all-encompassing. Its controls seem to reach all, but that is only an illusion. As its grip has widened, it has also loosened. Below the surface of polite compliance, free thoughts of resistance are bubbling, provoked into existence by the very system that sought to keep them out. One day, a new idea stands out so powerfully that some people find it irresistible, even given the risk of dire consequences for those who choose to speak about it. A small and still secret group of heretics gathers to talk about the idea. The life of the idea is over, and immediately starts all over again.