Conflict in team over Scrum vs Gantt

Question

I'm a developer in a very small startup consisting of 6 people, and I have decided to cure our lack of organization now that we have clients.

To give a little context, here is our organization:

• 2 junior developers (myself included)
• 1 senior business specialist
• 1 junior seller
• 1 senior seller who's the boss

For the last whole year, we had absolutely no organization. Everything was complete anarchy, and we were all over-working. We often miss deadlines set a long time in advance, lack visibility over our workloads and the business specialist is nearly in nervous breakdown. :D The only thing keeping stuff in check was my huge gantt chart I had to update a lot.

So we decided to get back on what we did before:

• A scrum board. (our business specialist was fed up with the "hippie" side of Scrum and lobbied to stop all kind of meetings, discussions etc to spend more time working). But as always it's working great for the dev but the others need very clear workload view to understand how many things they have to do for the next month or so.

The problem is that I know that it can't work, as I was the one managing the Gantt chart for the last year. Fixing set tasks doesn't work when you build software, as we underestimate time too much because of pressure. Also, the gantt chart is only good at the end of the project, after 300 successive updates.

So should I try to convince everyone to go for the more frightening Scrum way of "planning" stuff, without set dates for sub-tasks completion nor visuals for the next month workload per member, etc? Or should I just accept to build yet another fake Gantt chart to reassure everyone, making them believe we can plan one year in advance the life of a software development project? Or is there another way?

Answer 1

The other way is to build trust. Your colleagues need to realize that the kind of planning they want to do is simply impossible and an outdated method of working in most cases.

Gantt charts only work when the work to be done and the burn rate are very predictable. Neither of them is in software development.

There is a better way of navigating these uncharted waters than simply getting an empty map and drawing a straight line. That way is planning much shorter routes so you can, for example, easily avoid that island that just appeared on your horizon...

Agile development (and Scrum) are ways to deal with limited information, by making your yearly plan flexible enough to accommodate changes. You won't have the warm, fuzzy feeling of a precise Gantt chart, but that is not due to agile. That's due to the reality of incomplete information.

How do you plan a year using agile? Write epics corresponding to the large chunks of work you want to be done. Prioritize, estimate in points and distribute across the appropriate people. Fit to a year. From that point, remember that you should be time boxed and not scope boxed. You know when you are going to deliver (how many iterations you will dedicate to each chunk) but not exactly how much of the scope (because you will deliver the most valuable stories in order for as long as you have time).

Answer 2

You can follow Scrum/Agile and have a roadmap for planning purposes

...others need very clear workload view to understand how many things they have to do for the next month or so.

Just because you follow Scrum does not mean that you are totally blank about what you are planning to achieve in the next month/quarter/year. Here is one approach to a goal-oriented roadmap in detail:

"The benefit of a goal-oriented roadmap is that it shifts the conversation from arguing over features to agreeing on shared goals."

Everyone is committed to the goals but, as @Sklivvz pointed out, the exact scope to reach those goals can be determined and prioritized from sprint to sprint.

Answer 3

Everything is question of zoom: which level of details do you want to display and track? You could be crazy enough to make a Gantt Chart for each hours in the day, each day in the weeks and so on. It would describe tasks such as "Turning On Computer", "Launching your IDE" ... It could be helpful to manage monkeys, but probably not really efficient for developers with the right level of autonomy.

Your problem here is probably similar at a different level: Do you really need to know that in three months Jon will need to "Optimize DB Request" after he completed the task "Write DB Query". Is it producing value for your company to know this information? Jon is probably smart enough to find by himself the tasks he has to accomplish to reach a goal.

You should however probably keep a Gantt Chart for high-level goals and commitment. Instead of planning details of the DB Integration, you just write in your Chart "DB Integration", this will be the goal of your team, with duration and finish-date. During the execution of this tasks, you may notice that you are running late, need more sprint to finish. Then you can reflect this in your Gantt Chart.

What should be carefully detailed in your chart will be the dependency between each "goals". What will be the other "activities" which cannot start before completion of the "DB integration"? This will allow you to get the big picture and prioritize the different goals and even organize your work in your sprint.

For instance, the DB Integration is half-completed although it was supposed to be completed. Do you start working on another task for your next sprint or do you focus all your effort on this task? You will find the answer in your Gantt Chart by checking the impact of missed deadline for the different goals coming soon. In addition you may even roughly project the delay impact of your higher goals (Product Delivery) by updating your chart with the new information.