Planning for quality

As the fourth value in the agile manifesto (link) is: ”Responding to change over following a plan”, I have often experienced that it is difficult to convey to a team, why we should plan when we know it is going to be changed later anyway. Why not just start coding and act.

Many agile methods such as XP and Scrum actually has a lot of planning activities in them, and actually follow a quite strict schedule, although that schedule is very different from waterfall methods. But I find that few can explain the paradox of why planning is necessary when we don’t plan on following it anyway.

And then I read this little insight in a book not at all related to agile or programming, but to leadership and it struck me that it was the reason why even agile methods emphasize planning activities, although they value responding to change over following a plan.

The insight is this little quote from a book called Lateral Leadership:

”The goal of planning, however, is not high quality plans but high quality work.”

So when the team ask why they must plan the answer is to heighten the quality of the work they are doing. Work must have a direction, something to work towards, a vision of how the world will be, when our product is finished. And that is what planning does – it gives us a goal, and with a goal it is much easier to see what the next step towards that goal is.

If we look at planning this way, how good a plan is can then be measured by looking at the output of the work that comes from following the plan. This can then be used as input for retrospectives, where we can suddenly ask ourselves, if improved planing can help improve our quality.

It can also help us set the time span of an iteration, as when following the plan no longer provide high quality work or value for the customer, then we should look at stopping to follow the plan or change the plan – i.e. start a new iteration.

The last thing I really like with this definition of what a constitutes good planning is that it gives us an external measure of whether a plan is good. A plan is no longer measured on if it meet certain criteria or conforms to a certain standard. It can be valued on the output – did we get the value we wanted when we did the planning.

What do you tell your team, when they ask you why they should do all that planning?

Gaming for a discount

If you have been reading some of my other blog post, you have probably realised that I am becoming more and more interested in gamification - i.e. how games and gaming can be used to make work both more fun and productive.

So this morning while browsing my emails I noticed an Email form Sitepoint that offered a discount if I completed a simple little game. Normally email with offers goes almost straight into the trash can, but because of the little game, I was intrigued.

The game was a simple game of searching their websites for 3 clues. I completed the game and even though I did not take the offer, they got me to browse their website. I think this is a fantastic way of showing how adding even a little gaming contect can spur the curiosity of a reader and get him to look at your website. This is gamification in it simplest form – I wish there where more like this.

PS – I am not in any way affiliated with SitePoint – I just bought some stuff from them and now receive their newsletter.

Action stations!

When I started this blog, I swore to my self that this was not going to be one of those blogs, that only have 3-4 post and then just stop. And here I am and it has been more than 4 months since I updated it.

Luckily I happened to watch this little fun video earlier today. Since it's core message is to take action, I decided to take some action and make a blog post. The part about taking action is one I have mentioned earlier in this blog post.

So this is the first post of the revival of this blog - please do come back and check regularly - I promise there will be more posts soon!

Cat herding – best done by cats?

Managing creative people are often compared to herding cats (link 1, link 2, link 3). And that can be a daunting task as cats are known to do mainly do what they want to do.

However this is not a blog post about the usual answers to leading creating people. As usual  I have connected som related things and got this crazy idea that I just have to share (and I hope that ranks me as one of the creative peole).

Well, leading creative people may be like herding like herding cats, which sounds stressful, and often taking part in a software development project is almost the definition of a stressfull environment.

This is a bit funny as actually research shows that owning cats have many benefits. One of the benifits are that having cats around reduces stress. Having worked from home the last couple of month I can attest to that having a cat sleeping on your desk next to your keyboard while you work has a very soothing effect that lets you concentrate on the job. And if you need a quick laugh just take 2 minutes watching a cat play with a string (not my cat, allthough one of my cats are called Arthur).

A couple of month ago, I stumbled over a refence to cat cafés. At that time I thought it funny, and was wondering if a cat café would work here in Copenhagen where I live. But recently I have thought further – what about cat offices? Would it be an improvement to an office if there was a cat or two present?

On the top of your head you will probably call the idea ridiculous but try to give it some more thought. Cats are very clean animals and they sleep 60-70% of the day, and are generally not hard to keep. It is a very little expense and that could easy be recovered if they help create a less stressfull enviroment with a less negative mood that increases the productivity.

I am not saying this is an idea that will work for everybody – perhaps it will only work for a few – but on the othe I hand I do believe it should not be completely written off either.

Do any of you know offices where they keep cats? Then please leave a message in the comments.

The user is never right

The user/customer is never right – at least when it comes to designing good IT systems. This might seem like a odd statement to come from someone like me that thinks agile is great. Because agile places a lot of weight on commucation and customer collaboration, and most agile methods uses user stories or use cases as their basis for development. And if we base our design on user stories they must be correct, right?

Well, sorta but not quite. In the recent massive amounts of articles about Steve Jobs that have appeared after his death I came upon this qoute: ”You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.". I know from personal experience that this is often the way customers act when you present somenthing to them. There is always changes or imperfections, or their problems and processes have changes. I am sure many other developers out there know the feeling.

So if we do not trust the user/customer to supply us with what to do, should we then just do what is awesome? Well, that often do not work either. I found this qoute in a blogfrom CCP about the problems they face when developing (they use Scrum): ”..when we start off with an awesome idea rather than an actual problem we want to fix or a feature that has a clear, functional and necessary goal, it generally requires painful fixes further down the road”.

Does that leave us with a catch-22 problem? We can't rely on customers and we can't rely on what we find awesome.

No – we actually have all the tools needed in agile thinking. As I see it much of the agile way if thinking is based on that the user never really know what they want. We – the developers – need to help them. So lets look at it that way.

First – as agile developers we are always ready to respond to change over following a plan. We know we can not trust the user/customer to know exactly what he wants, so we make short iterations and continiously deliver stuff to the user, so he can see if he can use what we have made – if the system solves his problems.

Secondly we collaborates with the user/customer. This is usually done by frequent interactions with the user/customer to build trust between them and us – we need them to trust that we understand their problems and that we will deliver something that helps them.

Which leads me back to user stories and the qoute from the CCP blog. User stories is a great tool if used correctly. They are however not requirements. They are a tool that facilitates communication with the user/customer, and grounds our – the developers - understanding of their problem. It is not the solution to the problem – the solution is experessed in deployable code that solves the problem.

When we look at the standard template for a user story (*) it has often struck me, both as a developer and business analyst, how often the last part is omitted – the benefit. But that is crucial for understanding the problem that we want to solve. It is the benefit that creates value not the action. So I find that the trick to creating a good solution is to focus on the benefit and how to achieve that and not so much on the action. If we can find a better/faster/smarter action that achieves the same goal surely we will deliver value. But if we assume that the user/customer is right, we often focuses on the action – which is usually also easier, but also leads us much more in the direction to focus on contract negotiation instead of customer collaboration – afterall the system can do all the required actions, right?

In my experience it is the projects that take user/customer inputs as absolute requirements that fail – at least in delivering value. The ones that succeed is the ones where the developer solve the user/customers problem often using novel technology or solutions that the user/customer did not think of. So the user is never right – but neither is you – but that does not matter if you have a little faith and trust in each other and look at the problem and what creates value.

(*) "As a <role>, I want <goal/desire> so that <benefit>" 

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.