Scrum for Developers
Scrum series
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.
A scrum project starts with an almighty, all knowing product owner that has the entire list requirements prepared in a prioritized product backlog.
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.
Mohammad Fazeli on 2012-03-13
That was a great intro about Scrum..Thanks Anders.
Just wanted to share my experience of working with scrum within the context that you have described above. To use scrum methodology there are couple of factors that need to be taken into considerations:
1. Size of the project that you are going to use Scrum for – the project’s scale can be an important factor if you are about to decide on a methodology for the project. Scrum is quite a good model for small-scaled projects and it may make large-scaled ones just longer despite other benefits that it might have!
2. Customer engagement – while scrum is trying to involve customers in a periodic manner throughout life time of a project, the developed prototype or demo is an important indicator of the progress of the project. But bear in mind, that it is really hard to convey this message to customers that “this is just a demo and not a fully functional system! ”. In addition, the customer or project owner’s availability has a direct impact on each iteration’s result.
3. Fixed price projects – Scrum is definitely not an option! Each iteration in scrum tends to add more knowledge on top of current requirements in terms of new requirements or improvements of the current requirements. This extra knowledge is initiated from customer’s feedback which sometimes can significantly affect the overall project’s costs and time.
4. If Scrum is the Go for the project, it is of high importance that every single person who is involved in the project be educated about the aspects of a ‘Scrumish way of doing things’. By everyone here we mean both clients and also people involved in the project implementations (managers, developers, admins,..)
5. And one last thing, the quick nature of scrum requires full participation of all involved parties especially enthusiastic developers who see themselves dedicated for the project.