The Leaseweb Cloud development team has used Scrum as a software development methodology since 2011. During these two and a half years, we produced a lot of good results. But of course, there were also some bumps on the road. We had to deal with various challenges, adapting our processes along the way. As product owner of the Cloud development team, I would like to share some of the things we have learned over the years.
Scrum basics
If you are not (very) familiar with Scrum, I’ve written a short overview. While it does not do justice to the complexity of the Scrum methodology, it should serve as a good introduction. Scrum falls into the category of Agile software development, which came about as a reaction to the (at the time) more mainstream ways of developing software. These other methods usually took a lot of time to deliver, while the end result often did not meet expectations due to changed priorities or business needs during development. Agile development methods deal with those shortcomings by maintaining flexibility while developing by iterative incremental development.
So how does Scrum work? A cross-functional team, including developers, testers, functional design, etc. works towards a (roughly defined) goal, captured in a user story, which are defined by the Product Owner. User stories are goals for a development deliverable, described in a specific way:
“As <stakeholder> I want <certain goal/feature/piece of functionality/software> in order to <business value>.”
User stories should be accomplishable within a certain timeframe. These timeframes are called sprints, and are usually very short. For example, we currently use 2-week sprint cycles. A major difference between a fully-specified requirements document and a user story is the level of detail. Or better put, the lack thereof. This lack of detail helps maintain flexibility in the technical solution(s)/architecture and allows for easy correction of the goal if insights change – which happens very often! All this helps improve the end result. As an added benefit, the short cycles of development and rough goal description save a lot of time up front, so you can quickly begin working on software and start adding business value soon.
To make sure everything runs smoothly, there is a structure of meetings which are part of every sprint:
- Grooming: Estimating the complexity of user stories by assigning story points. In the long run, these points give a handle on which goals can be achieved during a sprint. Eventually, experience will deliver an average velocity in story points, and the team can commit and deliver spot on! The focus of estimations is therefor based on complexity and not on time.
- Sprint planning: The team breaks down a groomed user story into smaller tasks and commits to delivering a user story in the form of working software. They only commit if they think it is feasible within the timeframe of a sprint.
- The daily standup: A short morning meeting to discuss what every team member did yesterday, and what they’re going to do today. It is meant to identify impediments and keep in touch with each other’s work. Everybody is standing to keep the meeting short and sweet.
- Demo: Showing a working piece of software to the end users at the end of each sprint.
- Sprint retro: During this meeting, the team discusses what went right during the sprint, and determines what can be improved next time.
As with every methodology, the implementation of Scrum often deviates from the intended structure. This is a good thing, as a methodology needs to serve a purpose. The idea of Scrum is not to follow its methods to the letter, but to get things done.
Things we learned
Are you thinking about implementing Scrum? Be sure to keep the following in mind:
- Choose the method that delivers results When developing a new product, Scrum might not be the ideal method during the starting phase. When creating a product from scratch, it is difficult to define feasible user stories and deliver workable software for the end user within a sprint. Sometimes, a business goal might have such a high priority that you need to temporarily switch to a methodology that better fits that goal. Consider using a Kanban approach instead. Or accept that until all components of a basic product are there, not every sprint will deliver working software for the end user. Whatever’s the case: be careful not to get stuck in your method. Remember, the point of Scrum is to stay flexible.
- Synchronize development (cycles) within your company Having different teams that use different methods of developing software within the same organization can be challenging. Especially if the products of all teams need to be integrated into a single platform, such as Leaseweb’s proprietary customer portal. In our case, combining Scrum with a waterfall method of developing software required aligning workflows and processes. Things become even more complex if various delivery cycles (sprints and releases) are not in sync and have different time frames. The longer cycle will automatically determine delivery, which can defeat one of the advantages of using Scrum; fast delivery of working software, thus adding business value. After a while, we realized that we needed to rethink the way we develop software as a company. This resulted in aligning the methods used by the different software development departments by choosing a more compatible and common way of developing.
- Clearly define the role of the Product Owner A Product Owner should have the mandate to make decisive choices about the software being developed. In order to do so, he/she needs to have a clear picture of what is wanted by all stakeholders. Unfortunately, the Product Owner’s role is often misinterpreted. The most important things he/she has to do are:
- Gather wishes and requirements from all stakeholders
- Form his/her own opinion about what these stakeholder wishes boil down to.
- Use this insight to explain to the developers what is required of the software they’re working on, and thereby help shape the outcome of the developers’ work during a sprint
- Everybody within the organization has to accept that the Product Owner has final say in what will be built during a sprint. Otherwise, confusion will follow. One of the great things about Scrum is that the short delivery cycles guarantee that mistakes or misunderstandings can always be corrected swiftly. Gaining that authority for the Product Owner (i.e. me) took some time, but we got there by delivering results and aligning often. This, as well as our flexibility when adapting any mishaps, led to the required trust.
All in all, we are more than satisfied with our decision to use the Scrum methodology. The speed at which you can develop valuable new features and functionality is great. As a team we learn new things and improve our skills every sprint, and we look forward to putting them to use by further developing the Leaseweb Cloud products. Do you have any tips or experiences when working with Agile methods? Be sure to share them in the comments!