I remember when I was young, and I was programming alone, you know, as a hobby. I was the customer, the requirements analist, the designer, the architect, the programmer, the tester and usually also the only user. It was great fun. Trying to solve complex issues gave me joy, and doing it successfully made me proud. And then it became my job.
Software development is a complex job. Doing it with a team makes it even more complicated. Add to this that customers usually don’t know what they want, and there’s your recipe for failure and frustration.
Over the years, companies have introduced various measures to reduce the level of failure, mostly by increasing control. As a result, the quality of the software has improved, but most of the frustration remained (not so much for me personally, but in general). The business view on software development was (and still is in some organisations), that after twice the time and for twice the cost, you get half of what you want.
In my opinion, the popularity and success of Scrum is thanks to the fact that it addresses, and solves, the frustration. It actually makes complex teamwork fun, with quality and productivity as by-products.
The two key factors in Scrum that contribute to more fun are improved communication and increased involvement of the business.
You have to understand that software developers, like most people, don’t like to share their work until it’s finished. They don’t even like talking about it until they are sure that they will be able to deliver. Forcing them to do that anyway, in a daily standup, results in three things:
- they discover that sharing a problem makes it less of a burden;
- they discover that their co-workers actually have useful input;
- they make sure that they make progress every day.
After some time you’ll see that even the developers that preferred working alone in silence, start communicating and working together. That’s a huge return on investment for just a bit of scheduled interest in each other’s work. It creates a more lively working environment, and consequently more fun.
The other important fun-factor that a good Scrum implementation enforces, is continuous involvement of the Product Owner. Communicating with all stakeholders and managing the Product Backlog are very important tasks for the Product Owner, but it is equally important that the Product Owner is involved with the Development Team during the Sprint. There is simply no other way to make sure that the product is ¨potentially releasable¨ at the end of the Sprint. But that is the formal reason. Having the Product Owner close to the Development Team continuously, also increases the mutual understanding, and it makes communicating about functionality more important. This is a good thing for diminishing the hierarchy within Development Teams, where traditionally technical skills are most important. A team where various skills are equally important can become a well-balanced cross-functional team.
To work in such a team is great fun, it just might be even more fun than programming alone.