Failing project, how can I pull it back?
I'm working on a project that has had a very tight, defined deadline since the very beginning (just over a year ago). I said at the beginning that I thought it wasn't enough time but was assured that it would be fine as there was a lot of existing foundational work done.
I also raised my concerns, when it started, over resource and this has never been fixed, we've struggled to hire/keep enough skilled people on board, none are perm and very few are FT.
It is a very small company but they have ramped up significantly from 6 people to over 20. They refuse to split the into smaller more manageable scrum teams, so I am looking after the entire team in one go. The head was meant to be the product owner but they have not been adhering to this and gradually tried to merge this into my role.
The head of the company hasn't ever run a project with this many people and such a strong deadline before. They are also trying to do some of the work (which I have repeatedly opposed) as they are adamant that they are the only one who understands the product. They also are absent a lot, which means they aren't doing a good job of running the company or doing the actual work.
We now have only a few sprints left until release and they are looking to me to try and get this product out on time and I honestly don't know how!
- We've cut a lot of large features, I have tried getting them to cut out further things, that are not essential, but the head still keep adding things that we should have known months ago.
- I have been a broken record about getting more staff but this hasn't happened and have constantly told them I don't think we can do everything they want.
- The product is highly unstable and, while I keep trying to drive down to the root of the problem, we just keep finding more and more major bugs. Many of which are repeats of old bugs we had fixed.
- The head is vehemently against pair programming (thinks it's a waste of time!?) and does not command any sort of respect from the team in a leadership fashion.
I feel like they are very disorganised and that feels like my fault but I don't know what else I could have done or could do now.
What have I missed and is there anything I could try to see if I can help save this project? If not, what should I have done differently?
What have I missed and is there anything I could try to see if I can help save this project?
Did you make it clear that Scrum consists of a series of "very tight deadlines", known as Sprints, each one of which is the most important project that can be had?
The Sprint is the project that allows empirical process control to be established and maintained. The leap-of-faith being taken in the project you describe is comparatively hair-raising and the consequences are as you see them.
I'd suggest that in reality you have a succession of fake sprints, few of which result in Done work for inspection and adaptation, and which are effectively go-faster stripes on a waterfall process.
We have been working in sprints but I think you're right with the suggestion that ultimately, they are 'fake sprints'. We work with 2-week sprints and have a goal with what should be a working iteration at the end, but often this is broken, many times right at the end of the sprint by a messy commit. Or people get diverted (by the head) onto 'critical issues' that aren't that critical. So quite often the goal isn't achieved. Any suggestions on what I could do to improve this?
Find out who in senior leadership actually wants the situation to be improved, so they can create, communicate, and reinforce a sense of urgency for change. Who actually wants to establish empirical control over value, flow, and quality within Sprint timescales?
The organization must clearly stop doing things so it can start doing Scrum. There is an organizational gravity to be overcome, and it doesn't sound as though you can create the requisite sense of urgency for this by yourself.
I'm going to be very blunt in this response. My opinion is that you have done everything you possibly can. @Ian suggests that someone in senior leadership could be your partner in improving the situation. However, from what you have said the "head" would not listen and doesn't seem to think there is a problem.
Sometimes the best way for people to realize that they are wrong is to suffer some pain. The "head" needs to realize that his expectations and practices are unreasonable. You can show that you have done everything that you can to make this work. They need to realize that they did a lot to make sure it wouldn't work. There is nothing that a Scrum Master can do to solve this problem. You do not have magical powers and nothing short of a miracle would fix the problem you described in time to deliver the product in a few more fake sprints.
I know this isn't the response you had hoped to get but I don't know how to give you one that is pleasant. However, I will say that you have a very good opportunity to help everyone learn about empiricism. Empiricism says that all learning comes from experience. You do something, inspect the results, learn, and adapt as necessary. The situation you describe is full of opportunities to inspect, learn, adapt. Your project may not end in the desired manner but it isn't a failure if you learn from what happened and adapt so that you are able to avoid the same situation in the future.
Thank you both so much for your responses. I really appreciate them!
So many great points from Ian and Daniel.
To add to this…you can lead the head to water, but you can’t force them to drink. Don’t feel like you are at fault for this, you are doing what you can to lead and guide.
Some thoughts, and other things you could consider trying…
In order for Adaptation (change) to occur, you need Inspection. In order for Inspection to be effective, you need Transparency. Transparency means making things visible, and understandable to those viewing it. If the Head is not seeing what you are trying to show them, you may need to approach it in different ways. Speak their language, catch their attention, find something that connects for them. Light a bonfire if you have to.
How might you hold up a mirror in the situation to help with this?
What can you make transparent so the head and leadership can see the current situation more clearly, and understand the cause and effect impacts of activities like adding new scope to the Product Goal or injection of ‘critical issues’? (When you do this, this happens…)
What data do you have available that can be leveraged for this?
If you have Done work, you could look at the team’s throughput each Sprint to get a sense of how much work can be done in each iteration. This won’t be perfect, but it can be a way to illustrate that there is a finite amount of work that can be completed in each Sprint, and as such each Product Backlog Item and Sprint Goal needs to be carefully selected. Trade offs are going to need to be made as there is no room for waste or nice to haves.
If you have refined PBIs in the backlog, your throughput can be compared against this to illustrate how many Sprints may be needed to complete what is known today. (This project car has this much gas left in the gas tank. You can’t reach every destination with the fuel/time you have. Where do you want to drive with your remaining fuel?)
If you have quality issues, how might you quantify and illustrate this? Can you tie back to injection of ‘critical issues’?
You mentioned stability issues. Is Technical Debt being made transparent in the Product Backlog?
What else might you leverage to shine a spotlight and bring Transparency?
Thoughts on this?