I’ll admit it right away. I do like scrum. I think it is a natural that I do, because I am a developer. Scrum is a lean methodology that focuses on making the developers as productive as possible. Working as a developer in a scrum project means spending most of the time writing code, with clearly defined tasks at hand. It is a developer’s dream. Even though I am in love with scrum, I have to admit that scrum isn’t a silver bullet making a complete software projects work. At the heart of a successful software development project there is code writing going on, that is perfectly well suited to be managed with scrum. To make the entire project succeed, a number of other things are needed too. In a series of posts I will be putting scrum in the context of a complete project. In this post I’ll start with scrum itself.
Scrum in two minutes
Warning to sensitive readers: This text describes a scrum project in an ideal environment, where people are almighty, all knowing and cross competent. If that’s not your view of the world, then this series is for you because it isn’t my view of the world either.
The backlog is presented in priority order to the developers at a sprint planning meeting. The scrum master (the developers’ spoke person at the meeting) informs the product owner about how much available working time the team has for the next few weeks – the sprint. The developers break down each product backlog item into technical tasks called sprint backlog items. For each sprint backlog item a time estimation is done. When the sum of the estimations for the sprint backlog items reaches the available time, the sprint is full and the planning complete.
As the team is totally cross competence, all developers can take on any task so coding is done in strict priority order. Each day starts with a 10 minute daily standup where the developers make a quick status report to each other. During the sprint, there are no other meetings.
At the end of the sprint, there is a sprint demonstration where the developers show the results of the sprint to the product owner. The next day there is a new sprint planning meeting and everything starts over again.
Focusing on the Developers
Scrum is an excellent methodology for getting maximum productivity out of developers. The administration is cut down to a minimum, leaving most of the time free to write code. The tasks at hand are clearly defined to eliminate time loss due to vague requirements. At the end of the sprint, the developers personally show their accomplishment for the product owner. The personal responsibility for the demo is very important for the morale in the project. The day before sprint demo all developers are a bit tense. They do extra tests, adjusts minor layout and spelling mistakes and prepares a complete workflow showing their new functionality.
At the sprint demonstration, each developer gets a direct, in person, feedback on the work done. That feedback is very important in establishing a relation between the customer and the developers. Nobody will do a great job if it is unlikely that anyone will ever notice. The sprint demonstration makes sure that everyone involved will notice and know who to praise or blame.
From a developer’s perspective, scrum is a complete methodology for running projects. It contains everything needed. Clear decisions and prioritizations and a minimum of meeting, giving maximum keyboard time. Requirements analysis, funding and budget, release planning, testing and deployment planning are all problems for someone else. The developers’ needs are solved.
What about the Rest?
Widening the perspective a bit from the needs of the developers, it quickly becomes clear that scrum is not the only answer. It can be a key factor to a successful project, but it is not enough in itself.
Our MD at Kentor, Urban Berlinde, says that a project isn’t complete when delivered to test. It isn’t complete when the system is taken into active use by the customer. It is complete when the system has been in active use for a period of time, with the final fine-tuning done. It is complete when the system is delivering actual business value to the customer.
In this series I will put scrum in the context of an entire project. The project starts with an idea. It ends when the system is effectively supporting the customer’s business process. Between the start and the end of the project many different tasks need to be carried out. The development handled by scrum is only one of those parts.