Poetic simplicity

"If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. ”

                                                   - Antoine de Saint Exupéry

Since I first saw this qoute a few years ago I have had a piece of paper with it in large letters hanging by my desk. I find that it captures the the way that I the best way to develop somehting and that it also catches the essence of agile. Essentially I read it as saying, that if you can create a shared vision in your team and get everybody passionate about reaching the goal, then the team will self-organize and use all their enegy to reach that goal.

I have long wanted to write about this quote but each time found that I extracted more and more meaning and the post got longer and longer and still did not really catch the spirit of the qoute. So today I realised that perhaps I should do it the other way around. Because the qoute is short and simple and yet expresses so much, lets just keep it simple and remember that agile is about simplicity and that sometimes less is more.

This qoute has helped me a lot when both planning and executing a project – I hope it will help you to.

When you have to code … code! Don't document.

The inspiration for this blog post has very different roots. I have for a long time wanted to write a blog post about the ”working software over documentation” part of theagile manisfesto but could not find a good way to write a blog about it. And then suddenly a podcast I heard yesterday, a book I read last week and and qoute from a movie from 1966 made it all clear: It's all about getting things done.

Yesterday I was listening to the danish tech podcast Harddisken where they had visited the startup weekend  and talked to several of the participants. One of the participants was asked if he was not afraid that once you had told people about your idea in a public forum like the startup weekend that it would be copied by other people and diluted. And he said no – the idea is not the important part – it's about making it happen and that require the correct team – and the startup weekend was a good place to meet smart people that you could recruit for your team. An idea has no value in itself – it is the execution that matters.

Last weekend I stumbled over a book by Joel Spolsky called: ”Smart & get things done”. It adresses how to hire the best programmers which is something that has been a problem in all the companies I have worked at so I eagerly read through it. The thing that is interesting for this blog post is that it is not enough to hire smart people – you have to hire smart people that get things done. Again an emphasis on execution.

The last thing is this scene from the film: ”The good, the bad, and the ugly”. I have had it on my list of stuff that I felt embodied agile and leans pragmatic approach to making software, but could not fit it in. But the other two things put it into context. So when Tuco in the film says: ”If you want to shoot .. shoot! Don't talk.” he is in a way saying that ideas and intentions do not really matter if they are not executed.

And that leads me back to the agilemanisfesto and ”Working software over comprehensive documentation”. This part of the manisfesto is for me all about execution. Beacuse while some documentation is necessary the documentation in itself holds no value – only the working code holds value – and you could probably even expand that to that only working deployed code holds any value. And getting the code done and deployed to the customer that is all about execution. You can have endless good ideas, make tons of documentation but without execution you have no value. And to me that pragmatic getting things done is one of the things that have always attracted me to agile and lean methods, and I find that valuing working software over comprehensive documentation is a good hands on approach to gettngs things done.

So remember: When you have to code … code! Don't document.

Why is it good to fail fast?

The concept of failing fast seems to be part of much agile and lean thinking. However the concept is not in the agile manifesto nor the principles behind it. Traditionally failing is not seen as something good so that got me wondering why agile think it is good and if there is both a right way and a wrong way to fail fast?

In agile we do want to be able to respond quickly to changes and most agile methods (1) prefer short iterations and it is also one of the guinding principles that we should deliver software frequently. The reason we want short iterations is so we can quickly get feedback, and respond accordingly.

But failing fast is not just something related to iterations and feedback – failing fast has also become somehting to strive for in the daily work and coding. For example in this article by Jim Shore he tells about failing fast in code and how that can help you debug faster and build more robust code.

However if I was to tell a team to fail fast and gave them Jims article as an example, it could still easily be viewed as one one to solve a particular problem and not an explanation of why it is generally good to fail fast.

Reading the article something else hit me when Jim starts to talk of assertions, how and when to put them in your code, and how to structure the message that you want the assertion to give. Perhaps it is not the failing fast that is important, it is the fact the we get good information about a problem early on – or in other words: we get structured feedback that lets us act on it.

That harmonises very good with this article by Braden Kelley that I found while researching why failing fast is good. The authors advocate that the central question you should always as yourself when experimenting is: ”What do we hope to learn from this effort?”. And I think that is the same that Jims does with his assertions – he only inserts them when he can learn something significant from them, and uses a lot of time structruring the information he gets back – i.e. he thinks about what he hope to learn from inserting the assertion at precisely that place.

So to me ”fail fast” cannot be seen as a meme in itself – it has to be put into a context and serve a purpose before it becomes valuable. Failing is just one outcome of an experiment and unless you have procedures in place to learn form it (like the Deming circle: Plan-Do-Check-Act) or it holds no value.

Being a language oriented person I agree with Braden Kelley that failing is a negative word, and since what we really want people to do when we say fail fast is learn fast, why not just say that: ”Learn fast”. To me that much better catches the thinking behind agile and lean than fail fast.

1. I say most because I do not know all agile methods out there. However all the ones I know prefer short iterations.

What playing games can teach us about organizing work

I have for some time been thinking of doing a series of blog posts that focus on what we as software developers can learn from other parts of life to make us better at developing software. And this is the first go at that.

I have always been playing a lot of games – both board games and computer games – partly because it is fun and partly because you can learn a lot from most games. For the last couple of years, I have primarily been playing a game called EVE Online. And it was when reading one of their blogs on how they plan to develop the game, that a particular part struck me as more universally appliable than just for having fun in a game.

The blog post is part of their design effort for how to improve the game and when I read this quote I immediately thought it had wider appeal than just in a game:

Maximize "can", minimize "must"

• Nullsec features should always maximize the amount of valuable options available to the player, and minimize the number of mandatory tasks they must complete
• Nullsec features should always encourage players to solve their own problems rather than using mechanics to regulate things

EVE Online is what they call a sandbox game where everything (almost) is player built or player interactable and Nullsec is the most deregulated part of the game and hence both the most dangerous but to many also the most fun part of the game.

However what struck me was that changing a few words in that statement will change it from speaking of how to enjoy a game to speak of a way that we can organize work that must strike most people in software development – especially if you are using lean or agile methods – as something to strive for:

• The way work is organised should always maximize the amount of valuable options available to the employee and the business, and minimize the number of mandatory tasks they must complete
• The way work is organised should always encourage employees to solve their own problems rather than using rules to regulate things

I think that Maximize "can", minimize "must" is a good meme - It is certainly one that I will use in the future, because I think it is a good way to quickly expess the gist of these priciples from the agile manifesto:

Build projects around motivated individuals.  Give them the environment and support they need,
and trust them to get the job done.

Simplicity--the art of maximizing the amount of work not done--is essential.

So one of the lessons I think we can draw from playing games, is that work get more fun and rewarding if we can maximise ”can” and minimise ”must”. This might not work in all companies but I feel that in software development where creativity and innovation is essential to make a good product this is the vision I would like managers to have in a company I work in. And I do not think I am the only one that work harder, longer and get better results if I find the work to be fun and rewarding in itself (read my earlier blog post on motivation here and here).

Agile vs Lean startup - is there a conflict?

Check out Todds blog post about it. I agree with Todd that there should be no conflict between the two, and I find that trying to say one is better than the other, is a sign that you have not understood neither agile nor lean.

However Todd might be over reacting, as when I read the blog post from Abby Fichter and listen to the video in the blog post, it is really about how we can improve agile. And that is a very agile mindset.

Perhaps it just boils down to words - perhaps lean startup is not better but just different and another way to adress the problems that agile adresses. In which case it is just a case that we need to communicate more about it and try to understand what the other side means and not try to defend ours as the best - we can probably learn something even if we do not adopt it.

What are the best personalities for an agile team?

A discussion in one of the groups am I am member of in LinkedIn asked the question – specifically which of the Briggs-Myers personality types fits best.

This off course got me thinking. First I tried a test myself so I knew what type I was myself, and if that fitted both the role I have filled on agile teams (product owner) and agile thinking in general. It turned out that I was an INTJ which means that I am Introverted iNtuitive Thinking Judging. Having an INTJ personality as a product owner is probably is probably a good fit, as evidenced by this qoute: ”INTJs are known as the "Systems Builders" of the types, perhaps in part because they possess the unusual trait combination of imagination and reliability.”.

Then I turned to look at if it possible to determine if there is a single or range of characterics that fit agile thinking better then others. But I actually could not find any. Is it easier for an extrovert than introvert to think in agile terms? Is a judging personality worse at agile than a perceiving?

If we look at the agile manifesto, there is probably a good chance, that an extrovert would be better at having people and interactions come before processes and tools – and a thinking personality worse at selecting working code over documentation. But with four dictomies the Briggs-Meyers personalities have sixteen different outcomes and when I read them they all have some advantages that could be useful on an agile team.

Thats when I remembered that behind the agile manifesto there are 12 guiding principles and 3 of them are about teams (see below). Agile thinking is very team oriented. And normally you would look for a synergistic effect of a team where the whole is more then the sum of the component parts. This often require different personalities that supplement each other. A team of 5 masterminds like me (the INTJ type is called the mastermind in the Keirsey temperaments sorter) would probably not make as good a team as a team with 5 different types.

This has lead me to the conclusion, that there are no best personalities for agile thinking or teams. It will probably be a good idea not to have opposite personality types on the same team, as they might disrupt the team, unless there is also a mediator type that can talk to both of them. The Briggs-Myers personalities can be used a tool when you select your team, but you have to remember that as with any other tool individuals and interactions comes before tools and processes.

---
The 3 guiding principles about teams in the agile manifesto are:

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The best architectures, requirements, and designs emerge from self-organizing teams.