If they are, is it simple to use them with theses methods? Have you some use cases to present?
Yes and no (I bet you love this answer)
Agile programming methodology usually deals with pretty short periods of time (e.g. a two-week sprint), during which there is also a large amount of flexibility on what tasks should be performed in what order. So on the scale of single team, I say no - gantt is not useful.
However, on the scale of larger project involving several teams working concurrently it starts showing it's usability. On this scale you deal with more long term planning, you need to manage several teams (and in fact, some of them might be working agile, while others might be using different methodologies). So on this 'strategic' sort of level it can be useful.
Not at all!
The mindset (based on predictive process control, theory X) for which Gantt are invented as a tool are totally incompatible with the agile mindset (empiric process control, theory Y).
Read this post by Jeff Sutherland (co-inventor Scrum) why Gantt chart were banned in the first Scrum sprints!
Yes - provided you are talking about Feature Gantt charts and not resource Gantt charts. Feature Gantt charts, get you and your organization focused on the work and not on the workers. Because most of the world knows how to read a gantt chart, it can be very helpful in communicating widely about your progress and priority.
In comparison, burn-down and cumulative flow charts require an education for most folks. Now the burn-down and cumulative flow charts are much more helpful for steering your agile teams and work in process.
If a projects has a beginner and an end then it could be represented in a Gantt chart.
Also, a Gantt could represents task measured in hours.
Don't forget that AGILE methodology could be adopted in the design/implementing/supporting level, however it is not common to see other section of the business adopting it. For example, a Agile Team can show to the Business/Finance Team, a Burn Down chart.
As far as I am concerned, there is no place for Gantt Charts in Scrum. However, if your Scrum Master is a ex-Project Manager, you are still likely to end up with one.
Another reason to avoid Gantt charts is they are very good at managing dependencies. Having a good dependency management tool can lead to an imbalance of horizontal vs vertical user stories, with too much focus on the horizontals.
Consider alternative tools to Gantt charts that align well with Scrum like:
- Story maps to group and workflow user stories
- Feature maps to group stories in to business value and plot them as milestones on to timelines to communicate expected releases to the customer
- Burn down charts, both at a product and a sprint level
- Ensure you estimate everything, including EPICS but make sure you don't end up down a rabbit hole in the infinite minutia of estimation, remember, estimates are estimates...
- Focus on vertical instead of horizontal user stories
If you really do think you have to have a Gantt chart, then maybe you actually have an iterative or waterfall project (e.g. a big data centre move). In this instance change out your methodology (Scrum) for a more appropriate one (Iterative/Waterfall).