Scrum methodology may provide a strong basis for a winning project execution. But on the flip side, its processes must be carefully adapted to every project to incorporate its specific needs and circumstances. The way it would be done is often the cornerstone of the success or failure. In this article, Valeryia Kitun, a Project Manager at Intetics and Certified Scrum Product Owner describes the way they walked to put Scrum to work and deliver a great quality product.
Background
The idea to implement Scrum came to us during a large project. At that time, we were working on the implementation of new functionality. Since we had no unified approach, the team experienced a never-ending rush. Sometimes the team load was so intense, that they worked with no letup. The development cycles were too long while the time for testing shortened exponentially. Often the testing team reviewed the features that were implemented a month ago, while the next release was already knocking at the door. We scheduled for testing only the most necessary things and almost didn’t write any test cases. Eventually, it all ended up with hot fixes after the release.
After that release, the team continued working in the same rush, but things could not go this way anymore. The development quality was going down, the client was disappointed. We badly needed changes.
Water-Agile
What we had then could be called Water-Agile. As on the one hand, it kept the main Waterfall principle – the feature implementation first and testing afterwards. And on the other hand, we had Agile items: scrum meetings, scrum-master, product owner, product backlog, and others.
However, the main problem then was the huge rush. The testers couldn’t catch up with developers. When the development team had the complex functionality to implement, it came to testers in the very end of the sprint. It means they had only 2 or 3 days for checking it, making the regression testing and release-candidate. Thus, it was decided to pump the brakes and reorganize the processes to enhance the process quality.
Firstly, we divided development and QA sprints. It allowed testers to receive all the features from developers in the beginning of the QA sprint. In fact, it was quite a rescue.
As a result, the testers got enough time to check the features in a proper way. We prepared test-cases and involved experienced test automation engineers. They worked according to the framework and covered the sanity checks. It decreased the testers’ load over the last phase of testing.
Those Scrum sprints lasted 4 weeks. The first couple of weeks developers did their job. The second two weeks were left for testers to do theirs. We reached the scheme when the testers were provided with implemented features, had enough time for QA, and rounded up on time.
However, this approach had its minuses.
Business goals realization took a lot of time. It was important to get all the business requirements before the new features planning. We agreed with the client to provide the requirements two weeks before the development. It gave two weeks for developers to work on the requirements, and the testers got two weeks to check things up. The entire process took a month and a half, which was too much, considering market competition and other factors.
Untimely meetings & planning issues. The developers had to deal with several versions at the same time: the version under development, the version under testing, and the one in production. They worked with three different code versions. It was rather complicated. There was a risk of making the incorrect changes in one of the versions and trigger the project to an absolute collapse.
To accelerate the process, we decided to cut up the timeline. Time reduction was made by the sprints overlapping. From then on, what previously took us 4 weeks was cut up to 3. It was great for the client, but for us it became controversial.
The timelines of the development and QA sprints started to superimpose on one another. It could turn the planning into a mess again, but we found a great way by using the paper calendars, however old-fashioned it may seem. We placed them in every room and gave them to every team member. Since then timelines were never left in our heads or somewhere on the manager’s whiteboard. The calendars appeared to be such an advantageous thing that we use them even now when the sprints are not that complicated anymore. The planning issues were handled.
To adapt the team for sprint transitions, all the changes were made over the holidays when the process stands still. It took us one sprint to complete a transition and begin a new one.
Back To Classics
As our team grew, we got a chance to go away from those shifted sprints for a regular scrum. We finally came to a classic 3-week Agile sprint with the following characteristics:
Planning every Thursday after morning delivery
Start of the sprint on Friday
9 days for development
11 days for testing
2 days of regression
1 day for release candidate
We also prepared a set of rules for the client. Here is one of them covering the release conditions: If the testers have 7-8 hours to test a feature, we may recommend the system version for release. If they have 4-5 hours – there’s a huge risk. If the time limit is less than 4 hours – delivery isn’t recommended.
Based on our long journey with Scrum implementation, we created kind of a guide, primarily, for ourselves, though the teams planning to adopt Scrum can rely on them. They are tested. We are keeping to them now:
Make test cases.
Mark the milestones. They cut the work process into certain time intervals to help keep up with the deadlines.
Test automation is one of the key things if you are going to implement Scrum into your project. Without the automation, it’s only possible to work by hiring a huge team of manual testers (and there’s no economic sense to do it). So, test automation is everything. Remember it as the Holy Bible.
Listen to your team and implement only those processes that make the work comfortable.
Estimate how the load is spread over the team members. Check how they deal with the tasks and analyze how this process fits them in general. As in the worst case, it will all come to nothing.
In the nutshell, I can add that the rise of Scrum has moved beyond just a trend, but towards a must-have. To ignore this line is to put yourself at risk of not being able to compete and finish your projects on time.
Even with many of its benefits moving your project forward, Scrum implementation can be a difficult transition to make. To reach success, it’s important not only follow its basic features but also to provide a proper environment for your team and project, even if it sometimes means walking a long way and getting back to the roots.
Valeryia Kitun, Project Manager, Intetics
Valeryia Kitun is a Project Manager at Intetics and Certified Scrum Product Owner. She holds a Bachelor of Science degree in engineering and software development. Valeryia has profound experience in scrum framework development, business analysis, software testing, QA engineering and project management. As a business professional, she is actively engaged on the projects related to implementation of new technologies. Valeryia is a dedicated and details-oriented person who cares not only about the technical quality of the product, but also about the convenience for the end user.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.