How we implemented SCRUM, lessons learned

It’s been almost a year since we started implementing the Agile way of working by using SCRUM. During this time we have delivered several projects from very small to medium ones. Was it worth following this methodology? Is SCRUM really improving the way we deliver software? And what did we learn? Through this post we would like to share our experiences and lessons we lerarned. We are looking forward to receiving your feedback as well.

In a previous post I explained the AGILE way of working. I presume that you are familiar with this basic knowledge when reading this post. Besides it is good to know that GOYELLO is a software development company mainly working for clients on a geographical distance. Face to face meetings with the client do not happen that often.

The way we organized the SCRUM way of working

We decided to implement SCRUM rather strictly, as advised by the godfathers of SCRUM. We have implemented a dedicated work flow in our Project Management Environment which we support with Redmine as our project management tool. Each sprint lasts for around one or two weeks due to the fact that we are dealing with projects with a rather short time to market.

We decided to have just one SCRUM master from the start. In our opinion this is the best wayto ensure that all teams work in the same way. In the upcoming time we plan to appoint more SCRUM masters to spread the workload.

Starting with some projects that urgently needed some adjustments, we gradually implemented a SCRUM way of working for all our project teams. Soon we realized that it is not possible to use this approach for very small projects. But for sure we noticed that even project teams of two people can benefit from this approach.

In case you would like to know more about SCRUM, have a look at the following movie.

Our project approach

The above lead to the following project approach:

1. Project intake – Defining the core functionality and the scope of the project.
2. Project kickoff –Analyzing the most important features and prioritize them together with the client. A detailed plan of the first sprint [link to sprint definition] is being defined.
3. Project implementation – Having a daily SCRUM to measure the progress and to gather the issues which are blocking the team. The team works on tasks from the current sprint. The aim is to finish the sprint within the agreed time frame. At the end of the sprint we have a short sprint review to monitor our progress and to predict the future team performance. Each Friday we send a progress status report to our clients. At the end of the sprint we deploy the solution for client’s review and approval.
4. Project deployment – Usually we present the result of our work to the customer at the end of each sprint. Therefore, project deployment is mainly focused on solving the issues that occur while delivering the solution.

We try to keep our SCRUM meetings informal

The main aim of our SCRUM meeting is to check if the project is going according to plan. This means that we discuss the following items on a daily/weekly basis:

• Have previous issues been solved by the team member or SCRUM Master?
• Are the team members focused on the proper tasks and do they communicate the issues to each other?
• Are there any issues that are blocking the team members’ productivity?
• (Weekly/Bi-weekly) Is the customer happy with the current status of the project?
• (Weekly) Is the project right on track and healthy from the financial point of view?

In general the SCRUM master checks these items by asking the following three questions:

1. “What did you do yesterday”
2. “What are you planning to do today”
3. “What are your issues”

We demand our team members to be prepared for the SCRUM meeting. To be honest this is one of the hardest things. Especially in the beginning we noticed that developers tend to treat these meeting as unnecessary hassle. They just do not feel the need. They feel their freedom is disturbed. Convincing them of this necessity has not been easy up to today. Sometimes it turns into a real struggle.

Management SCRUM to kickoff the week

At the beginning of the week the management team kicks off with a high level management SCRUM. All management team members get to know the status of the ongoing projects. They discuss the project performance and the way how to manage people to finish all projects on time.
Where are the project managers?
Well… we have them depending on the size of the projects. For smaller projects we limit this role to project leaders instead of real project management to prevent a lot of over kill and bureacracy.
Team members usually work on one or two projects simultaneously.

TO DO: Tell the client about SCRUM

Some of our clients really understand the change we are going through and they feel the difference. Projects are released more and more on time and within budget. They are more in control and can easily influence the end result. They have open communication with the project leader/manager.

Especially new clients tend to work with a more traditional way of project management. They try to fully specify their needs and prefer to wait till the end result sees the day light. We are thinking how to solve this issue. We prefer a lot of client interaction and software development in an Agile way. And this just needs client’s trust and interaction.

Implementing SCRUM pays off, even for small projects

I general, this is what the Agile SCRUM approach looks like in our company. For sure we didn’t t manage to solve all issues within our organization yet. But we feel we are on the right track. We are confident that SCRUM is a very useful methodology even to manage relatively small projects. I am curious about your experiences.

Feel free to provide me with your feedback and remarks about the way we work. This can help a lot! Any questions and suggestions are more than welcome. We welcome you to start a discussion on Twitter as well: @GOYELLO.

Tags: Agile, Scrum