Scrum framework is one of the most popular and well-known agile methods for software development. I’ve used it for a while now and have definitely had my fair share of Scrum projects. Many organizations implement Scrum or other methodologies knowing the advantages of agile methods, because of their popularity and/or because they are accustomed to that methodology, without even considering an alternative.
That being said, on more than one occasion I’ve felt that a certain aspect of my Scrum Methodology wasn’t working the way I hoped it would. The key, keep development flexible.
Here are some common examples:
When your retrospective meetings are between two or three people it may feel like a waste of time to get together once a week or once every two weeks to check in on the progress. They may feel repetitive and boring, especially if the team members are programming near each other and are keeping up with the communication.
In this case, I found that sporadic stand-up meetings (twice a week) to check on the team’s progress are less invasive, allowing for the retrospective meetings to be shortened and more focused on keeping the team united and communicative. Communication is crucial, therefore, as long as the communication flows, it’s more important to feel good and work well, even if it means not following the usual processes.
Remote work is on the rise. Whether you are working remotely for your company or another company as an extension of their team, when either party doesn’t work with your methodology, you may find it hard to implement it yourself. If there’s poor communication or the requirements are not given at the beginning of the Sprint it will be very hard to define your Sprint.
The first step, in this case, is to try and convince the client/team that Sprints are the best way to work with your team, or at least the best way to meet deadlines. In the case that the client is not convinced, you may need to adapt and shorten your Sprints or have more than one planning per Sprint so you can group requirements as they are given to the team.
Some projects begin without a clear vision of the end product. There’s a general idea, for example, “an app to track your health”- users register their meals, show calories, etc. However, you may then realize that you need to shift the focus of the app to exercise and calories burning instead of meals, and so on until you find the right end product. The client may know which needs they want to satisfy but goes through a long trial and error period until they find the right fit.
In this case, the changes may be too radical and consistent for your team to define their usual two-week Sprint. The team may feel as though their work is not useful and get frustrated if the Sprint requirements change too much. Again, shortening the Sprints could be helpful, and focusing on constant communication is important in these cases. It’s also very important that the team understands the project’s vision in order to help the client discover the right track, which in turn, will help make the requirements and goal more clear and the development easier.
Of course, these aren’t the only cases where you may have doubts about the methodology you are implementing. Experiencing any of the issues described above does not mean you have to stop using them. You can always use various agile frameworks simultaneously or create your own adaptation as the project evolves. The beauty of agile development is that you are part of a process that is constantly changing, which enables you to continuously improve the way your team works.
The two most important signs of needing a change are the team’s motivation and their metrics. So my advice is to follow your instinct and back it up with proof that your suggestions are indeed improving your team’s performance. Don’t be afraid to try out new methods and be flexible. Remember that, as long as you follow the Agile manifesto, you are free to experiment and evolve your methodology. That’s the only way to learn and improve.