Avoid to kill project without reducing scope

Question

Within a project, we develop an application. The project is set up as follows:

• The overall application is divided into four different "level". We completed one of those levels in four month.
• We use scrum with a one week sprints-duration incl. estimation of complexity. But we miss often our sprint goal and shift tasks to the next week.

The project team consists of:

• One consultant and PM
• Three developers: Two are developing the back-end and one is developing the front-end part of the application
• One remote developer for front-end tasks
• There is also a subcontractor company for some tasks.

Our plan for the close future is:

• Finish two other "levels" within one month (we working on one of these "level" for two months aleready). The focus shifted from back-end to front-end work (where we have just one developer, incuding one remote developer)
• We are aware that the schedule is quite tight

What would be the best way to deal with this situation, taking the team constellation and the scheduling into account?

I am thinking of switching to Kanban for the entire project, like here

Answer 1

If you ask if Kanban is going to help you deliver, it won't. Actually, none of the methods will.

There is the project management triangle. If the time which says that you cannot have all the angles - scope, schedule, and cost - fixed. If your scope and schedule are fixed, the only thing is left for you is to hire more people that increases cost, increases communication, which risks the schedule.

If I understood correctly, you did one layer in 4 months and plan to do another two in one month. It is very unlikely that you'll be successful, so if I were you I'd started to communicate a scope reduction and find a way to iteratively roll out the not delivered layers. Since you are a small team, has no external dependencies Scrum can help you to focus and deliver. I don't see a reason why you should change the development method, you have a different problem.

Answer 2

Agree with @Zsolt, and would add that you are better off determining the amount and sources of schedule increase from the first chunk of 4-month work, and then applying that to future projections. This could be as simple as "we underestimated by 50%, therefore we will probably underestimate future work by 50%" all the way to "of the 50%: 10% was due to unknowns/emerging work, 25% was due to stakeholder feedback, and 15% was due to a risky feature not going as planned". The second approach is obviously much more actionable, since you can apply it a bit more effectively - discussing how to mitigate feedback through early alignment or simply prioritizing it better, evaluating remaining risky features a bit more thoroughly, etc.