Help! My Scrum isn't Working

Around two weeks ago, I proposed to my boss that sprints were no longer a worthwhile option for the biggest project in the history of the company; at that point we had been doing them for over a year.

Here is how we got there.

To start at the beginning means to set the scene a little. I had just been promoted from MI Team Leader to (Business As Usual) Development Manager; this basically meant I was in charge of everything BUT the biggest project in the company.

With zero experience it was a risk to push me forward into the role and also the fact that at the time I was the 2nd youngest in the team; it was definitely pressure on me to perform in front of developers who outstripped me in experience and could very easily not have taken to me. The very first thing I did was to get all the teams on Trello. Whether they knew it or not… they now had visible work and a flow to show the work going from one end of the system to the other.

Bottlenecks. Lead time. Definition of Done. Little’s Law. None of that was there… but the idea of communication was there.

To me, Agile tools are there to unearth problems and to help solve them.

Since then, my own personal Agile journey has gone down various different paths. From attending my first Lean Agile Conference, to watching various YouTube and Vimeo conference keynotes to reading material that would change the way I think about the whole of the industry in general.

Then came the call to take the next step up, and suddenly I had inherited a Scrum team of around six developers which now sits at over fifteen (it flexes).

Now I am a fan of Scrum. It’s the first real Agile process I have found myself delving into and I enjoy the discipline plus the ritual around it. We delivered a system in a matter of months through it before I stepped into the new team, and without Scrum I doubt we would have landed something as good.

Lately however, my thoughts have began to open up and for this company and this project I felt it was doing more harm than good.

DISCLAIMER (I know how Scrum should work; trust me. Any project is formed through it’s environment).

Here are some points that have come up along the way;

The Structure I’m the first one to say that just because you don’t have all the typical roles filled doesn’t meant you can’t do something; but when you lack key fundamentals in the Scrum process being able to give their time daily; the system begins to suffer. Product Owners and Stakeholders must be a constant part of the structure. If they are key figures in the company; don’t expect them to be at the stand up every day.

The Admin Overhead Without that Structure and those skulls to do tasks, they are then rolled down the hill to colleagues who are already doing other piece of work in the system. What that means is, come the time to discuss requirements or priorities it’s a game of assumptions and guesses to make sure we are building the most important thing correctly.

Uncertainty Agile was born for changing requirements. The exact reason we use it is because we know the details of the project will change every day as we try to make the best piece of software we can. However without those key figures helping drive the work down and break it up… all you have is enormous features in the system which the actual team then need to demystify and split up. When it comes to Sprint Planning.

Rushing Too must uncertainty and a hard working team means by the last day of the Sprint, developers are rushing to get their work done just so they have something to show at the demo. How stupid is that really? Someone is potentially cutting corners just so they don’t look like the odd one out the next day.

Being Too Nice This might be a weird one… but it’s probably the case that in most instances development teams will trudge through crap until someone tells them to stop and smell the flowers. They want to do work for the business and they want the project to succeed. They have done the Retrospectives and they have given their opinion… but deep down they know only a few have the ability to change what the company and team are actually doing so they just get on with it.

Getting on with it could be the most hazardous thing you and your team can ever do.

So what are we doing now? Kanban in TFS 2013

– Took away the timebox of two week sprints all together – Added UX and Test work into TFS as a visible columns to find the flow of work – Prioritised the backlog for the next month – When requirements were lacking discussions were then had around the item

That so far is all we have done. Two weeks into it there is a clear change in how the team is behaving; less panic around end of sprint demos and more awareness that conversions are needed between the team to discuss requirements and conflicting work areas (due to no sprint planning, they need to make sure their work doesn’t affect anything else).

Every business is different and so if every team. Agile tools are meant to be experimented with so that you and your teams can get the best way of working that they can within their business. No business’ are perfect. No Scrum implementation is perfect either because nirvana is a mirage.

But if you genuinely feel like something isn’t working right then stand up and discuss it with your team; it could be the different between an average product with half the most important features missing on day one to a quality product with the useless features missed out.