In this series of articles I am looking to outline why Scrum works for us. During the series I’ll be looking at the challenges in software development today, firstly in general and then specifically with two “traditional” approaches – waterfall and solo working. In the final part of the series I demonstrate how Scrum works for us to address those challenges.
I was motivated to produce these articles to educate our wider business. While we have been operating in a Scrum manner for over two years, acquisition has brought many new faces to the table – many of whom are confused by the way we are working. It’s also a great opportunity to refresh those that have been working with it for a while.
I would stress that these articles are not intended as an academic study of the differences between development methodologies. These articles have been written to highlight the weaknesses that Scrum addresses – thus will likely come across as one-sided when exploring the “traditional” approaches.
For the same reason, I don’t explore other alternatives for solving any deficiencies within those approaches.
This article addresses development in general and raises a number of challenges to be overcome. The subsequent two articles will add to that list of challenges by looking at two “traditional” development methodologies – waterfall and solo working. In the final part of the series I demonstrate how Scrum works for us to resolve those challenges.###
Development is, at its heart, problem solving. It’s the taking of problem and using technology to resolve that problem. Development has been described as much art as science.
This puts developers very much into the category of knowledge workers – a worker whose main capital is knowledge. Knowledge worker are workers who “think for a living”.
“What differentiates knowledge work from other forms of work is its primary task of "non-routine" problem solving that requires a combination of convergent, divergent, and creative thinking” Wikipedia
This means we need to think a little differently when managing and directing work to a knowledge worker.
Firstly, let’s take a step back to what most of us would recognise as normal management.
Command and control has been an exceptional driving force in productivity during the 20th century. It underpins the majority of what we consider to normal or traditional management.
A manager dictates the work to the subordinates then monitors the execution of that work. This doesn’t however work so well for knowledge workers.
“Workers throughout history could be ‘supervised’. They could be told what to do, how to do it, how fast to do it and so on. Knowledge workers cannot, in effect be supervised” Peter Drucker (much respected management guru)
By trying to supervise knowledge worker you simply do not get the best results. This will vary by individual, but common problems are low moral & motivation and focus on dysfunctional targets such as time vs. quality. The former of these was easily demonstrated by good developers leaving.
The latter of these can be seen in poorly written, buggy code finding its way into testing or even production.
In the book Drive by Daniel H. Pink, Daniel describes three drives:
Drive 1 – Biological motivators
Drive 2 – External motivators
Drive 3 – Intrinsic motivators
Command and control uses that second drive, the External motivators. Most of us will recognise this as carrot and stick management. Daniel’s book goes on to say:
“For routing tasks, which aren’t very interesting and don’t demand much creative thinking, rewards can provide a small motivational booster shot without the harmful side effects”
The harmful side effects mentioned are the dysfunctional results observed when external motivators are used to encourage knowledge workers. As many academic studies and leading businesses case studies show; they invariable have the opposite effect to the ones expected – they actually reduced productivity.
Within the book, Daniel’s evidence shows that the third drive is much more effective for create, right-brain, heuristic tasks.
So, this gives us our 1st challenge – How do we engage the intrinsic motivators?
Software is now everywhere and embedded in everything we do – from phones to TVs to even electronic books. With this comes a new sense of expectation in consumers.
They expect the software to work first time. They don’t expect it to have bugs. They don’t expect to have to wait a long time for it. They expect it to work for them.
There is such an abundance of choice within the marketplace that should a consumer dislike a product they simply switch to one that delights.
These same consumers are taking those same expectations into their business life and expecting their IT teams to match those high ideals.
So these expectations give us 3 challenges:
Within business every activity we engage in is at a cost – if nothing else the salary of the individual(s) carrying out the activity.
It makes good sense to ensure that all activities achieve the best return on that investment. Development is no different.
I have seen this interpreted in various organisations as “pay as little as possible and sweat the worker”. This of course produces hugely dysfunctional results and provides a very poor return on the investment. This can be a difficult principle to get across to executive management with an eye to the bottom line. I however firmly believe that if you are underpaying and/ or overworking an individual then you will simply not be getting their best – human nature tells us there will be resentment which in turn is a distraction. Any distraction and the individual is never going to be at their fully creative.
When I talk about getting great Return On Investment I’m talking primarily about reducing waste. Waste such as building software that is never used.
Based on an industry study carried out by the Standish Group, it is estimated that 64% of code is rarely or never used. This is obviously a huge sign of waste.
We don’t build the right thing – if the software doesn’t do what the user wants then it will never be used. This is already covered in our challenge: How do we ensure that we are developing the right thing?
We don’t build it at the right time – for example, if the software takes so long to develop that the opportunity no longer exists. This is already covered in our challenge: How do we ensure that we are developing it at the right time?
We bloat the product – if you look at Microsoft Word, it’s believed that most users will only ever use a fraction of its features. If we follow that same super feature rich approach to internal business applications then we would invariable introduce considerable bloat.
This introduces the challenge: How do we ensure that we are developing only what’s needed?
So far we have found the following challenges:
1) How do we engage the intrinsic motivators? 2) How do we ensure that we are developing the right thing? 3) How do we ensure quality? 4) How do we ensure that we are developing it at the right time? 5) How do we ensure that we are developing only what’s needed?
In the next article we will look at waterfall development methodology.