Scrum: to use or not to use
At a certain point every company specializing in software development realizes the importance of having a simple and efficient approach to project planning and implementation. Having tried multiple sorts of planning, delivery and support methods on our projects, we opted for such a popular Agile framework as Scrum. Today we are using it in most of our projects and find it so powerful and helpful that we cannot imagine our daily life without it. At the same time, we are everyday finding room for improvements on how to employ this method in even more efficient ways.
When to begin?
In our case, it came to us naturally. There were several reasons to start using Scrum; and its implementation is a kind of continuous step-by-step work.
Requirements. First, in most of our projects we have only high-level requirements as input from our customers. When doing our projects in compliance with a Waterfall-like approach, we always had to convince customers to start with the Requirements Specification and Architectural Design phases. No doubt it is surely good and helpful to collect requirements as much as possible in advance. But is it efficient in most cases? Not at all. Simply because it takes tremendous efforts to interview all target users and stakeholders when collecting software requirements from all possible perspectives. Even if you manage to create hundreds-of-pages documentation with actor diagrams, sequence diagrams, and long lists of use cases, you will most likely need to revise it and change dramatically in the future, when you eventually proceed to implementation. Taking into account the time and money spent, nobody is inclined to spend more. People are normally trying to implement the system according to only those requirements collected during the previous stage of the project.
Feedback. Of course, during the implementation phase by classical Waterfall you also have milestones and interim deliveries. But over and over again, our experience proves that in the majority of cases customer people are just happy about the progress reports as they believe that everything is running well when the software requirements specification has been carefully completed beforehand. As a result, product review is postponed till another day closer to the end of the project. Last minute change requests are often brought to the table at the point of not having enough time and money for their implementation. All this happens not because of the lack of skills, manpower or loyalty. Not at all. Everyone was trying to do their best to build modern and powerful software, but things simply did not fit in the timeframe because of the employed monolithic development method like Waterfall.
How to begin?
Today we love Agile, and Scrum in particular, more and more. However, looking back at the past when we only started working by Scrum, we had no idea about the best way to proceed. Having external personal Scrum consultants on a long-term basis is very expensive and, in many cases, is not very efficient. The team should walk through this path themselves and implement best practices into daily chores. Eventually we decided to take consultations from time to time as needed, and bring selected practices, based on those external consultations, into the projects. Practically speaking, we support our team members, who are most interested in Scrum, by providing professional external courses in order to bridge the knowledge to our daily work on the projects. It means those guys regularly prepare and conduct in-house trainings on different aspects of Scrum with practical exercises and parallels to our real projects. They also act as professional Scrum masters educating all players on both our and customer sides to properly utilize the principles of this development method in full measure.
Experience is always a personal thing, but we strongly believe that learning from others is something very efficient and natural, so we would be happy to share our Scrum experience gained at our company of GRSE. It will be published in several posts starting with such important topics as shaping a project backlog and estimating the efforts. We hope you will enjoy and find it practical to apply within your organization.
