This is the second part in a 2-part series. Read part 1.
In my last post I gave an overview of how we started the process of changing the way we do agile development at Leaseweb by setting goals,
engaging our engineering teams, and developing a maturity model to get everyone working to the same standard. In this post I’m going to talk about how we set up our scrum teams, how we get all levels of the business involved in the development process, and how we calculate the cost to provide the most value for the company.
Our current Scrum teams are set up as follows:
- Product Owner – defines the priorities of the team; responsible for the order in which features are built.
- Scrum Master – in charge of the scrum process (coach): making sure the team does retrospectives, sprint planning, refinement, coordinating meetings.
- DevOps – Development and Operations in one team of about 5-8 people.
The first step to creating the teams was to train the scrum masters and product owners. We did this with the help of a company called Prowareness who helped us to develop solid agile principles. Once we had those in place we went on to train the stakeholders outside the engineering department on what scrum is and why we are using it and what parts are needed by different groups to participate. This included not only departments such as sales and support but also the board of directors. This was important to get everyone on the same page and using the same processes. We started 2016 with the sprint counters reset to zero so we could begin our first two-week sprint at 01.
Predictable Development
Our next challenge was prioritizing based on the company’s needs. Instead of just talking about ideas we wanted to write them down so that we could compare and calculate them. To do this we introduced business cases which are ideas from a department that needs a product or service. The department writes the business case itself which includes the value to the company while the cost is calculated by engineering.
Once there is a business case the next step is to develop a roadmap. We do this once every sprint. To accomplish this we set up a meeting to do the following:
- Invite all of the stakeholders to collaborate and discuss the business case and get different perspectives.
- Get all of the ideas on sticky notes to evaluate and group.
- Define a Minimal Viable Product; strip away excess features until you have the core.
- Find dependencies on other teams; decide what features require support from which team to gather resources.
- Find the priority of the (refined) business case; this is determined by the value vs. the cost. Ranking determined by which gives the most value to the company.
After the stakeholders have shared their ideas and a minimal viable product has been defined along with team dependencies and project priority has been determined the next step is refinement. The only team involved in this part of the process is the development team who meets at least twice a week for an hour. They take the ideas from the sticky notes and turn them into user stories.These user stories focus on the technical details and each one is assigned story points. The number of points is based solely on the complexity of the story and does not specify a time as to when the work will be completed. Complexity is not only determined by the service or product request but also the definition of done. The story isn’t done until the definition is met. Once complexity has been determined the team is asked to assign a number based on that complexity and then the highest and lowest are used to find a median on which to base the user story.
Now that the complexity is known the team can move on to determine the definition of ready. We do this with our INVEST checklist so that we ensure the user story is:
- Independent – can it be built without other dependencies? It should be small enough to be delivered on its own.
- Negotiable – can you still discuss with engineers what it should be and how it should look?
- Valuable – if it isn’t valuable it shouldn’t be built.
- Estimable – can you estimate how long it will take to build.
- Small – is it small enough to fit into one sprint? Don’t work on a user story that doesn’t fit into one sprint. If it doesn’t fit break it down into smaller pieces.
- Testable – at the end of the story can something testable be delivered?
Priorities Based on Value
With our refined user story done the next thing we want to figure out is our team velocity. Team velocity is the amount of story points that can be built during a normal sprint. Once a team has worked a few sprints we can determine on average how many story points can be burned by a team during a sprint. With this information we can calculate the how long it will take a team to do a business case. From there we can figure out the cost of the business case with the following equation: story points of business case / team velocity = # of sprints. The cost of development is the number of sprints multiplied by the number of engineers. Using these data we take estimated value of the business case and subtract the development cost to determine the priority.
Another key goal was to have a responsive organization based on market needs. To achieve this we have product managers who handle all of the non-development tasks. They work to identify trends in the market and write business cases to respond those trends as well as develop strategies, procure new hardware, and determine profit and loss.
The last step before development starts is to present the project to our product steering committee which includes our board of directors. The product owners present their roadmap for what will be done over the next four sprints and commit to that deadline. The committee can veto but this requires a good argument for why they don’t want to go forward. Once approval has been given the teams start development. If there are no new business cases to present, then this meeting is used as an update for the ongoing business cases.
Transparency
All of the previous goals help us achieve our final goal of transparency. Looking at the business cases per team we can determine which teams deliver the most value and we can see how we need to scale engineering. If there is no business cases for a team to work on then resources may need to be deployed differently. If a team is overloaded with work then it may need to be scaled up.
At the end of each sprint the teams demo their newly released products at an event for the whole company so that we can celebrate our successes. This is also the official handover from development to the team that requested the product or feature so they can then engage with customers.
We also do a retrospective at the end of each sprint to discuss a variety of issues. What went well or didn’t go well? What should change in the next sprint and did we over- or under-commit? Was there any friction within the team? This is the time for everyone to speak up. We also send out an anonymous happiness measurement to each team member before the retrospective and ask them to let us which team they’re from and tell us how they’re feeling, how they like working for the team and whether there are issues. This measurement provides us with an overview to determine trouble spots on teams and address any problems to help teams evolve.
Validate the Feature/Product
After all of the hard work is done and the product has been turned over, how do we determine its actual value to the company? During the development process we add measurements such as counters or logging in order to determine how often the new feature or product is used and how much time or money was saved. Based on these results we can decide whether the user story should be developed further or if we should go in a different direction.
Although we’ve reached our goals to become more agile, we still have a lot of work to do and our process is maturing as we go. We’ve found with this model that not only do teams help each other along and benefit each other with their achievements but that they also have fun reaching a new level of success which in turn helps the entire company grow.