Scrumban

I posted a really popular blog a while back all about Scrumban, At the time of writing I'd only ready worked with Scrum and Kanban but whilst working with a new team I had the opportunity to bring in Kanban and than evolve the process into Scrumban.

I shared some of my adventures on LinkedIn and various Scrum groups I'm a member off but now it's time for the full write-up on the adventure.


The team I was working with had a heavy mix of both support work and project work and became apparent from the start that the management liked to be hands-on...

They wanted to track velocity, estimate work and keep track of resources (people) better.

One of the biggest problems I had with the team was changing priorities - especially with project work... The team were working extremely hard  but actual output was low.

An overly busy Kanban board - Spot the excess of work in the testing column.

One of the biggest problems I realised I had immediately were the management within the IT department - they were young and very inexperienced in both project management and team management. They were keen to introduce agile working practices but with little understanding as to what this really meant!

I suggested using Kanban - It would allow for priorities to be changed, allow management to keep track of resources and I hoped would quickly identify the problems with the current setup.

As I hoped it very quickly made workload very visible - It showed the quantity of working entering the team and the throughput - I was able to calculate mean lead times and average number of tickets per week. 

But more importantly I was able to reflect decision making upwards - Show the importance of making the right decisions and the knock on effects of back decision making....

One of the brilliant things with agile is the visibility it gives - but that visibility is two way... It shows what the team is working on and it shows how good project management is - Which was the department's biggest weakness.

After a month or so of running the board it had become apparent to the entire department that the team were overloaded and the decision making process flawed - Unfortunately the management decided to disengage with the process rather than embracing with it and hid away more and more.

After being put in the strange position where the management suggested that I should bully people into getting them to work faster and employe several other questionable tactics - we both came to the conclusion that I was not a good cultural fit for the company.

I don't believe in bullying - Not in the workplace or anywhere, It's morally and ethically wrong... Even if you don't share my morals or principles on the matter.. It doesn't make good business sense. People are are scared are not creative, they don't speak up or share ideas, scared people are not honest people and as Scrum Master I won't to hear the truth about project status updates not what somebody thinks I want to hear! I don't want to lead a bullied demoralised work force - I want a team who's excited about coming into work everyday.

So... Alas I don't really have full report on how successful Scrumban really is... It certainly allowed me to track a sort of velocity and estimate work better.... However without the management in place to support the process and work with it... it might just highlight bad management!