During the last 18 months I made myself familiar with agile methodologies. They have been a hot topic at conferences, lots of articles have been published and even some customers asked for it. Especially scrum. So I started to learn about it.
I think that scrum is a good fit for many scenarios. But I do have some reservations in regards to using scrum as an agency. In this article I want to point out some of the problems that I have found.
Understanding of scrum roles
Lots of times the customer is very excited to use a method like scrum. But they don’t grasp all of the ramifications. And most problematic, they often don’t understand their own role as a product owner. This puts a heavy burden on the whole project. And it may lead to overhead on the agency side if you want to put in a proxy product owner to make up for it. It will also lead to a lot of of discussions during the project and especially after finishing the project.
Procurement regulations
Sometimes the project team on the clients side is very enthusiastic about using scrum. And all the roles might be understood. But many clients who use an agency have very strict procurement regulations. And the procurement department is very straightforward about this. They need a fixed price and they need a fixed final result. And at best they also need a fixed date. This is very understandable as they need to minimize risk. But this makes working in a scrum context very hard if not impossible.
Resource allocation
In many projects there will be an ongoing support contract. This means the agency has to plan for supporting a project on a longer time frame. And they need to plan their resources accordingly.
People from the original project need to be able to make time available for feature requests or bug fixes. They might also have to stand by for call support.
They also need to take into account the effect of emergencies. In this case developers from the original project team might need to support.
But as you can’t plan emergencies and as this problem might also occur in project contexts in general, this is only a minor consideration.
There might also be a need for certain types of experts. These experts are typically shared between parallel projects. This makes planning for these resources very difficult.
Resource allocation for scrum projects needs some type of exclusivity of the people who work in the project. This is very hard to do in a ongoing support situation.
Workplace limitations
Many agencies prefer open floor offices. It reduces friction while working together and makes communications a lot more inclusive. When a project becomes hot, some switch to a team- or project room or even a war room. But in regards to the requirements, a scrum project is always hot. So it might be tough to find a room for each scrum project.
Please don’t get me wrong, I think that scrum is an important project management methodology which has many benefits for a development team. And we will definitely continue to use it in client projects.
But I also think that you need to consider the limitations and risks of using this methodology in certain contexts.
Maybe you have already solved a lot of these problems…