How about – Scrum?

Text originally posted on http://blog.omnicom.rs
No pictures were retrieved after the blog was taken down.

Is agile development the right solution for your project?

Sometimes, when you’re dealing with a really big project, you lose all hope that one day it will get done. Even if the project deadline is far away, or if the milestones are all reached in time, the continuous work on the same project can make you lose touch with reality, make you feel dull and repetitive. In these cases, the perfect development method to embrace is Scrum – the agile development framework. If you are unfamiliar with the term, I suggest reading this article – it’s short and sweet, and tells you everything you need to know if you’re a beginner at Scrum.

Scrum was first developed to allow a more flexible approach to changes during the course of a project. If, during the development, the client changes their mind or gets new ideas, this can be handled more easily within an agile framework than within the traditional waterfall software development methodology . That’s what “agile” stands for. However, even when everything goes according to plan from the beginning to the end, Scrum can offer the Development Team the possibility to improve, search for the best ways to solve problems and overcome impediments, and overall, boost their creativity. Another good thing about Scrum is that every two weeks (or however long you set your Sprint to last) you can see results – an increment of the product is produced. This way, there is no feeling of stalling, and the overall atmosphere within the team is much more positive. If applied properly and transparently, Scrum also allows everyone to clearly follow the accuracy of predictions, expectations met and corrections made.

When it comes to implementing it, there are obstacles to overcome . I have been witness to it, and I will try to write down some points that are crucial for the framework to – work. In this post, and the next one, you will read about Roles in Scrum, Sprint Backlog, Daily Meeting and ways to overcome impediments.

Roles

Scrum must be implemented properly. Don’t try to have a project manager instead of Scrum Master, or senior and junior programmers and designers. In Scrum, the only recognised roles are: Product Owner, Scrum Master and Development Team. Or, as Master Yoda would say:

“Do. Or do not. There is no try.”

The Product Owner owns the Scrum Backlog. This means that he defines the product, usually from the point of view of the user. These descriptions are called User Stories. He also decides on the priorities, and prepares User Stories for each individual Sprint. He must be able to present work for 1.25 worth of Sprint – just in case the work goes better than expected. It’s best if the Product Owner attends the daily stand-up meetings: he will easily spot diversions from the desired course or misunderstanding in the Definition of Done, and suggest corrections early on in the Sprint.

The Scrum Master holds the key to facilitating the work of the Team and improving Team efficiency. He does not assign tasks – he assigns a User Story. It’s up to the team to decide how best to go about it. It is important to accept that the role of the Scrum Master is that of a servant leader. He is not there to guide, but to remove impediments, distractions and blockades from Team’s success. The Scrum Master should also practice what he preaches: he needs to make sure everyone in the Team knows what the benefits of Scrum are, and apply them in his everyday actions. If your company is trying to implement the Scrum methodology to a pre-existing project, it’s worth thinking about hiring an experienced Scrum Coach for the Scrum Master position. A Scrum Coach will review the performance of the Team and highlight when there is regression back to the old system.

The Development Team is represented by programmers, designers, testers, and everyone else involved in the project. Scrum doesn’t recognise junior and senior programmers, every member of the Development Team is a developer. Also, even thought that’s not always easy, designers should be part of the Team and not do work separately. The Team must be able to work as a whole – it must be multi-disciplinary, self-sufficient and self-directed. They also must be located in the same room, relatively close together, and obviously separated from other teams and employees. This way, they will be not only allowed, but encouraged to discuss the project, Sprint Backlog, possible solutions, and progress. They should be allowed to post sticky notes and be given a white board to visually present their work and sketch impediments. Other employees should know: the Development Team is allowed and encouraged to be noisy, if that will help them get the job done faster.

Sprint and Sprint Backlog

Sprint is a period of two to four weeks in which an increment of the Product is produced. As I mentioned before, the Product Owner prepares the necessary work for a Sprint (actually, for 1.25 Sprints) and in the Sprint Planning Session the Product Owner, Scrum Master and Development Team discuss it and create the Sprint Backlog. It’s crucial that all members of the Team have a say in the creation of the Sprint Backlog and crystallization of the Definition of Done (the acceptance criteria for User Stories and Product delivery).  I found this article to have very good tips on Sprint Backlog creation.

The Sprint Planning Session should last about 10% of the Sprint time, and it is best if the meeting is time limited – this highly improves the productivity on the meeting and encourages participants to focus on the subject.

When identifying tasks needed to complete a Sprint, it’s important to keep in mind that not all tasks are just coding: some time is spent on research, learning new skills, testing, database imports, etc. Every task should fit in a day. If a task doesn’t, split it into smaller ones. In the article mentioned above I read a tip: not to estimate the time needed to complete tasks. This might be an interesting experiment to undertake, but I am not sure how much I agree with the idea, before trying it. If you have tried it, please leave a comment with your experience.

The Sprint Backlog is allowed to evolve during the course of a Sprint. It’s best if Daily Meetings are used to evaluate and improve the Backlog to give better results. Also, inspection and adaptation should be done seamlessly –  they should not, by any means, interfere with the development, but should be able to review and correct the course if the development, if needed.

There are tools to follow and estimate the success and development of a Sprint. Sprint Burndown Chart is especially designed to show how much more work is left till the end of the Sprint (tasks/time), but also allows estimation of the Sprint’s success. The Sprint is doing fine, when estimates are within 15% tolerance threshold. You can also use Sprint Burndown Charts to forecast future work on the list of products in the Scrum Backlog.

Scrum Burndown Chart should be displayed for all to see. That way improvements will be made within a Team to correct or compensate for a slower period.

 

If you would like to know more about Scrum, this article has a list of resources that can help you. Or you can bear with us, and read more about the Daily Stand-up Meeting and the ways to overcome impediments in my next post.