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.
This article addresses solo development and the challenges to be overcome. The previous two articles looked at development in general and the waterfall development methodology. In the final part of the series I demonstrate how Scrum works for us to resolve those challenges.
What is solo?
Solo is where you are working in isolation. Also sometimes affectionately referred to as cowboy development.
This will generally be a “lone ranger” responsible for developing, delivering and maintaining their system – over which they, and only they, have full control.
Working in this manner can appeal to an individual – I’ve certainly enjoyed it in the past (and would probably attribute a good deal of my career success to it). The sense of having full control and being able to, generally, work unfettered with the end users can produce a great sense of worth and powerfully addictive buzz. This actually goes some way to addressing the “How do we engage the intrinsic motivators?” challenge.
During my career I seen plenty of examples of solo developers or even teams of solo developers being a team in name only.
How does it occur?
Solo working occurs very naturally within start-ups and smaller companies. But it can also creep into larger organisations.
An individual owns a system or project either by virtue of them being the only person that can or by doing such a good job last time. In this latter case, I’ve seen hugely capable (and expensive) developers being tied to simple but critical system because they had simply stepped in to help out.
In one case, an Enterprise Architect spent a considerable portion of his day supporting a simple form application for the Compliance team because he’d mocked it up for them.
Business teams love the ability to have a go-to-guy/ gal for their system. They are busy people and want to get stuff done with the least fuss. For the Compliance team in the above example, it was great – they could get stuff done without the bureaucratic overhead of going through project requests (oh the irony).
I’ve also seen it be an ego thing. A team or individual feel that they are so much more important than the wider business and as such, why should they have to deal with anyone else than their “guy”/ “gal”.
So what’s bad about it?
While this can seem an attractive to the business and, in some cases, the actual developer - it is storing up problems for later down the line.
The quality of the system can be poor as it is relying on one person’s view. This is basically the equivalent of marking your own homework. And if you are on tight deadlines, why wouldn’t you push out the nice new shiny function and come back later to fix the bugs – after all, it’s your system? It’s certainly not uncommon of the developer to become tired and inadvertently introduce bugs. This ties into our existing challenge “How can we ensure quality?”
The system will generally be isolated in terms of its interconnectivity with the rest of the organisation. With only a single developer working on it, they are unlikely to see similarities in other systems or identify opportunities to integrate with other systems. This produces a new question – How can we ensure that our systems interact properly?
And if your developer gets hit with a bus? This adage is still true today as it always has been. If one developer is the single source of knowledge then as a business you are simply not resilient to illness, time-off or even heavy workload. Some people believe this challenge can be circumvented through documentation. Personally I believe this to be a fallacy.
Even should the documentation be fully up to date (which it invariable won’t be) it will still take considerable time to bring in a replacement and get them up to speed. Still not convinced – then treat it as any other Disaster Recovery plan (because this exactly what it is) and test it and see how well it works. Until it’s tested, then it nothing more than a theory – and a dangerous one at that because you are gambling your business on it.
So this gives us our final challenge, How do we ensure a developer doesn’t become a single point of failure?
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?
6) How do we allow development to start without documentation?
7) How do we maintain momentum?
8) How do we handle change?
9) How do we ensure the work is understood by the entire team?
10) How do we ensure we are working together?
11) How do we ensure ongoing quality?
12) How do we minimize project overhead?
13) How do we highlight and avoid technical debt?
14) How do we expose something is wrong quickly?
15) How can we ensure that our systems interact properly?
16) How do we ensure a developer doesn’t become a single point of failure?
In the next and final article we’ll look at how we use Scrum to address those challenges.
Labels: IT Management, Scrum