I have been working in different mission the last couple of years with the focus on an Agile way of working. Myself have done mistakes in interpreting the Agile world and the surrounding frameworks as Scrum, Kanban and lately Scrumban. It is more the later one for who I will discuss some observations.

The group of people with who I was working with received a course about Scrumban for 3 days, presentation of its history, theory, benefits, the companies that succeeded (where are those who didn’t) and finally a nice workshop that pepped up the whole group resulting in a nice Scrumban board. Yes we are ready (or not) to rock.
Before we continue I have to say that the group of people is in fact a team that works on demands that are simple and fast to fix, usually 1-4 days, including all the steps from analysis to test and go to production. We can call the group with the ugly word “Maintenance team or Development support team”.

First thing that I found not right about our processing was the fact that the Scrum Master Role was a pudding of a Project Manager and a Scrum Master, and here I observed already the influence of external partners, so the order of task or priorities where already not being followed, I suppose that flexibility exists and political reasons are there.
The above didn’t create a lot of frustration in the team, as it where no Scrum purists, so for the weeks after the start of the new stuff nothing did changed really, just another way of having a view of work in progress. And at that moment you can clearly see that if not all team members wants’ to enact the basic principles of scrum (even if we do scrumban you can at least inform you about Agile or Scrum no?) and try them, you are finally not going in the right direction. The motivation level was too low to get there where I thought we were going to go. For me a team needs to be more kicked in the ass sometimes.

Some of our team members were stuck with long running demands, like they were not really part of the team. This caused by request of an external partner to let Joe do the work for them on that part of their project. There is no issue in that but if the task isn’t sliced in subtasks that can fit in the Scrumboard then this isn’t maybe a task for this team? So this results in not sharing the knowledge to other team members, other team members not able to join forces. We missed the publication to external partners how we process and what we can process.

Mistakes we did where starting on demands that where not completely clear, not having a product owner(s), identifying demands that looked small in scope but who revealed to be much larger and it took a long time to start having a better backlog.

Finally we succeeded in making things better, a lot of lessons learned and at the end being able to teach external partners what we really did and needed from them.