Written by Bob Molenaar
I’ve been a consultant for almost 20 years. My recent experiences with Agile Scrum made me think of some of the infrastructure projects I have done and how Scrum could have made those projects easier. Scrum is known to have the best practices for software development projects, but the experiences I’ve had with Scrum, prove that this method is also a good way to manage infrastructure projects. I believe that Scrum can be used for more than just software development. In this blog, I’ll share 7 lessons I’ve learned using Scrum for infrastructure projects.
1. Only join a team if you can give it a 100% of your time
I was hired by a big bank as a solution designer. The main goal was to translate requests for certain products and solutions for business to workable solutions, which could be used by all employees. When I started, I was asked to create a digital workplace for Scrum Teams with members that work onshore and offshore. This was the first time I joined a Scrum Team and it was the first time Scrum was introduced to the IT Services department of the bank. They had to determine the correct needed sizes for the Citrix farm. I’m specialized in Citrix in an Enterprise environment, so the product owner asked me to join the team for 50% of my time. That’s where I made a mistake. When you start to work according to the Agile Scrum methodology, you must commit a 100% of your time, otherwise it won’t work. Scrum needs your full focus and attention. If you have to divide your time between the Scrum Team and other projects, you lose focus. Scrum takes time during each sprint for actions such as planning sessions and daily stand-ups. Therefore, you lose too much time to be effective if you don’t fully commit to Scrum.
2. Don’t try to manage all the problems that might occur, but just get started and solve them along the way
During the first project I did in Scrum style, I tried to manage all the problems that might occur. This made it hard to get started. It took me two full sprints before I realized I should have just started. Trying to manage problems which aren’t there (yet) demands a lot of time. Now, I just get started and deal with the problems when they hit the surface along the way.
3. Make sure you have the people with all the required skills in your team
The first Scrum Team I joined had to handle a lot of different requests, so we needed different skills in our team. We made sure our team was equipped to handle all the requests. The problem in this team was the lack of backup when a team member was unavailable. We took care of this by making use of the “four eyes” principle. Thus, there were two team members working on one user story. As a team, losing focus can be an issue when there are too many different items that need to be delivered. As a result, each member works on his own subject because he/she has the proper knowledge. We fixed this by creating “themes” and made sure we only worked on 2 or 3 “themes” in one sprint. By making team members responsible for “themes”, and by helping each other and learning from each other, we regained focus and worked more as an actual team.
4. Make the run organization or stakeholder part of your team
In the first few sprints, we struggled with getting access to the environment we needed, because we didn’t have the resources or team members with the right access level.
We spent the next couple of sprints on getting a good overview of the farms, applications and who needed access to those applications. When we were ready to decommission the first batch of servers, we ran into a major bump in the road: the change process. I understood why these processes were in place, but I learned this process doesn’t work with Scrum if it takes eight weeks to decommission a server. On top of that, we were not allowed to do these tasks ourselves. It would have been better and worked faster if we had somebody from the bank itself in our team, who had the needed access level for these tasks. It would have been even easier if the organisation gave us the needed access and made us fully responsible for the process.
5. Make sure you understand the user story and won’t accept it when the story is not ready
Don’t start with a user story that is not ready. When a product owner has a user story and puts it on the backlog, and it is unclear what he wants or not all information is available, don’t accept that for the next sprint. Without proper information, you can’t properly estimate the time needed for the user story. Collecting information can take a lot longer then you initially expect. This leaves you with a user story you can’t complete during a sprint or even worse: a user story that is not what the product owner or stakeholder wants.
6. Make sure there is always a definition of completed or acceptance criteria
The biggest problems in the first sprints I made were the user stories that could not be completed in one sprint. Also, the definition of done/acceptation criteria were not clear or properly defined. This resulted in a lot of discussions during the sprint planning, because everybody had his/her own opinion of what the end result should have looked like. Do not accept a user story without acceptance criteria, to prevent spending time on a sprint for nothing, because the product owner and/or stakeholder gets a product that he doesn’t want.
A good tool to determine if a user story is ready to be put in sprint is INVEST:
|I||Independent||The user story should be self-contained, in a way that there is no inherent dependency on another user story.|
|N||Negotiable||User stories are not explicit contracts and should leave space for discussion.|
|V||Valuable||A user story must deliver value to the stakeholders.|
|E||Estimable||You must always be able to estimate the size of a user story.|
|S||Small||User stories should not be so big that they become impossible to plan/task/prioritize with a certain level of certainty.|
|T||Testable||The user story, or its related description, must provide the necessary information to make test development possible.|
7. Involve your stakeholders as much as possible
It can be a challenge for the product owner to make sure the stakeholders are happy with the progress. It often happened that the product owner had a vision about a product that needed to be delivered and its requirements. When we delivered the product, the typical feedback was that some requirements were missing. By involving the stakeholders (and users) to determine the requirements, this can be prevented. Another challenge was the need for somebody with specific information for the user story who wasn’t part of our team during the sprint. That is why you need to make sure that before you put such a user story in the sprint, the person who has this information is dedicated to the project and he has the time to provide you with the information/help to finish the user story.
Scrum for consultants
I love the scrum process and as I mentioned earlier, I think it would have helped me a lot in some (if not all) of my previous projects. I work for a consultancy company and we do most projects on a fixed time/budget basis. This makes it hard to fully use the Scrum methodology. I think the Scrum method only works if the client also buys the scrum way of working.
In most of my projects there was (or I did it myself) a project manager who made a big MS project planning with all tasks that needed to be done. However, this doesn’t work, because the whole planning fails if one tasks falls through or takes longer than planned. This can only be solved by asking for more time/budget from the client. I think most consultants and/or architects know how much time a project will take. If you split the whole planning into two week sprints, it will already start to look like a scrum project.
Scrum for every project?
This all sounds like Scrum is the way to go in IT infrastructure projects. But applying Scrum in a time/budget fixed project is not easy and it requires a lot of experience. Furthermore, using the Scrum methodology in a company that is not used to work this way, will demand some preparations and commitment. But if you work in a company where the daily operations and projects are separated, the Agile Scrum methodology can be beneficial. Even in 1st/2nd line support teams, I can see a benefit to structure work with scrum. But what is the correct way to use scrum? Many ways lead to Rome. But, with an experienced Scrum master and product owner, Scrum can fit in almost every scenario. For example, I turned my house renovation into a Scrum project. In addition, I read an article about a family who uses it for the daily processes, like: getting ready for school, work and bedtime.
It is not hard to learn the Scrum principles. With the Scrum guide and this video, you can get a good idea of which Scrum methodologies you can apply in your work. However, it takes some practice (and failure) before you can use Scrum successfully.
Don’t hesitate to get in touch with me if you have any questions.