Lessons learned working with scrum
Hello I’m Stijn and I’m the latest addition to the awesome Uni-t team. Today I want to share some knowledge and experience about working in a agile / scrum environment. Hopefully these tips might help when you decide to give scrum a try.
Scrum is what you make of it
At my previous job I decided to introduce the scrum methodology when we were about to build a massive SaaS application for the healthcare industry. Being a scrum novice I decided to apply every aspect and technique of scrum to the letter: from the time-boxed daily stand-up meetings starting at 9AM sharp all the way through planning poker and demo meetings.
The first few sprints were horrible: as a team we had a hard time adjusting to this new way of working. We had to get used to the massive amount of communication and discussion, as well as actively participating in all the meetings that are part of a textbook scrum implementation.
After a few sprints we started to like our newfound methodology and really managed to produce results that we could present during the bi-monthly demo meetings. To me, the tipping point was when I realised that you can easily drop any aspect of scrum if it doesn’t fit your team or project. At one point we decided to drop the retrospective meetings, which felt as a huge relief at the time.
Buy-in is everything
The reason I was able to introduce scrum was because of early support of senior management in general, and our CEO’s flexible attitude towards process improvements in specific. A few months ago I followed a Product Owner training and was very suprised to hear how much difficulties certain people had in trying to maintain their scrum processes.
After talking with my fellow trainees it became clear that in most of their companies there was little to no buy-in from senior management towards the scrum methodology. This is critical for success. If your CEO or COO does not believe in the benefits of scrum, or if they fear that not having fixed deadlines will jeopardize the product roadmap, scrum will simply not work in the long run.
Velocity = difficult
One aspect that we never really got around to was velocity. A team’s velocity stipulates the amount of user stories a team can complete in the timespan of one sprint. The first few sprints a velocity is irrelevant: the team is adjusting to the new way of working and probably doesn’t produce a lot of results just yet (which is perfectly fine). The problem with velocity has everything to do what how you assign “weight” to a user story: story points or actual hours. We played planning poker to assign a certain complexity, but during sprint planning we resorted to actual hours to plan the sprint. This made it very difficult to deduct our velocity. After a few attempts we decided to drop velocity all together. It just didn’t fit our scrum toolbelt at the time and you know what: that’s perfectly fine.
So to conclude, I leave you with the only useful advice about scrum I can think of: only use the techniques you really need for your project and your team.