Note: before I get started, I would like to thank Oscar, our Marketing head who has taken a pretty amazing route to get us all into blogging as a company. I wish we all had an Oscar in our world as I have seen some very interesting blog posts coming out from my colleagues as an aftermath of his initiative. Thank you Oscar for your patience and support.
I have observed a deeply integrated mindset in many people: results are the only things that matter. When a belief is that widely accepted, it usually has a whiff of dogma about it - and when you catch that scent, you know you want to look a little closer. I certainly do.
Well, if we're not just looking at what's been created, what else could we look at? Here's a natural candidate: the creation process.
Don't just tell me, show me
There's a pretty good example of how important this can be in just about every supermarket: FairTrade products. Take a look at this picture of a FairTrade coffee packet from our local Budgens.
People buy FairTrade not just because of the quality of the goods. They also buy it because they know it matters how something is made, not just the end result. It matters to people - a lot of people - that they're not exploiting agricultural workers in less-developed economies; and it matters to promote environmentally sustainable farming techniques.
Here's another example: passing an exam. You can go down the path of learning and working to achieve the end result or you can take shortcut pathway like cheating or just cramming at the last minute. Both could possibly get you pretty similar end result of a degree, but how you got the degree does matter.
These two examples ought to be enough to shatter our dogma: on every street we can buy evidence that it matters to people what the process of creation is. If you think through your educational and professional life, you'll likely see many instances where how you achieved something was at least as important as the paper certificate you got at the end.
What has this got to do with software?
Let's take this conclusion to another context - making software. While it's clearly not a 1:1 match, the examples above actually remind me a lot of Scrum, for a couple of reasons.
Scrum makes you think of requirements as user stories (if you are new to user stories, this wiki site is a good place to start). This means through the course of the project constantly and consciously any story is structured to bringing value to users. The effect ripples over contributing to a more valuable product creation.
Scrum encourages and thrives on collaborative working. Brings people together, gives them an environment with no interruption, freedom to do their roles and constant constructive feedback through retrospectives every week leading to a consistently improving team. This enhances positivity and happy people making the best of their ability vs. stress driven living caused by lack of focus, blame culture and limited or no learning to present the opportunity for improvement.
In sum, the journey to the destination - the process of creation - makes a difference. It matters in and of itself, and usually also produces better results.
If you want to read a real-world example of what I'm talking about, check out this recent blog post that tells the story of how Scrum helped a team related to the Occupy movement to continually improve themselves and their output.