Just got back from a great training session “Working on a Scrum Team” held by Kenneth Rubin. Wonderful presentation and very useful also, where I learned a very important lesson. Don’t use Agile unless it brings value.

And we get to today’s topic: Scrum in Support teams

I feel the need to do a short description of the Support team: 7 people, fixing user’s Request Tickets and also fixing/tuning/implementing functionality of the service we provide, in my case, Data Warehouse service

Now, it seems that my company wants to be Agile compliant and implement the methodology across all teams and projects. At this point, a simple question arise: “How in the world you want to implement Scrum in the Support Team, when you don’t know the product Backlog for at least 1 sprint ?”

You may say….Kanban is what you need, and I agree 100%, but how can you adjust the Scrum beliefs and rules so it fits Support activities? The answer I see, is : YOU CAN’T DO IT.

I like to use the term ‘SCRUMFALL’ for what we use at this point and here’s why:

• Daily Stand-up occurs every day and takes 20-30 minutes for a team of 7 people (5 Dev + 2 QA) – fail
• During a 2 week sprint, we change the Sprint backlog 2 or 3 times because of the issues arise along the way – agree
• The Scrum Master role is held by a different person each sprint, but the backlog is often changed without its permission – fail
• During the Sprint planning, the team is not 100% involved. There are people who see the stories for the first time, at the point of planning – fail
• QA is not involved in development process from the start. They see the code and the functionality only after Dev Sign-off – totally fail – this is why we call it ScumFall

….and the list can continue

This makes me conclude… In an Agile compliant company, all products/teams must comply with the internal policy, unless there’s a strong team/project which can change the narrowed view of the management to use whatever methodology suites best for each individual project….in my case, Kanban