In this blog post I’ll try to explain why using Scrum didn’t fit our needs. I’ll talk about the main reasons, my personal opinion and what the alternatives are for our team.
First of all, let me explain the team situation, the products we make and how we used to work.
As mentioned in my first blog post, I work as a development team manager at a software company. We develop a collaborative framework which is the base of some main products. The team working on the applications consists out of some developers, configurators and designers. They all work on our framework and the various products.
You get something like this:
We did already work on an agile way of software development, but we needed a better way to manage the process, to create structure and overview. All this using a time-boxed iterative approach. So we did some research on Scrum. From what we’ve read and learned about it, this was the way to go.
Scrum its use has focused on the management of software development projects, and it can be used to run software maintenance teams or as a general project/program management approach.
On the exact moment that we wanted to implement Scrum, Visual Studio 2010 (our development software) released a Scrum process template, perfect! This process template is a great way to define a product backlog, create sprints, work-items, test cases, a burn down chart ..
So we had a decent tool, we had a great product backlog with lots of amazing new features to be implemented, we had a good team, we did standup-meetings in the morning, sprints were defined.. Off we were…
But after a while, things did not work out as planned. That’s why:
- There are too many projects and custom client-solutions
- Our team is too small to focus on the sprint for each project
- Sprints take much more time to complete than planned.
- Every team member is working on all projects at random, it’s hard to ‘focus’ on the defined sprints.
- Sprints are influenced by clients. Client requests have a higher priority than the sprints
- There was not enough discipline for the daily standup-meetings
- In general, time boxed iterations do not work for our -type- of work
- Our sprints are mostly event driven, instead of time driven
My personal opinions:
- It’s definitely not the fault of the tool, which is awesome
- We have to combine big feature development with custom client-development, support and maintenance
- There are too many Work In Progress items at a time
- The best solution is to stop using Scrum
We’re currently looking into another solution which will suit us better. I’m talking about Kanban, but more about that in a later blogpost.
Any suggestions and experiences are welcome, just post a comment!
