We had the opportunity to work with an IT company that used “Agile” approaches during our projects.
This is not an article about the limits of Agile, but it is to show how Agile treats the FLOW of its system.
Agile approaches use a practice called Sprinting. Without going into the methodological details of the Sprint, the teams are concentrate during a given time to deliver several tasks. We will see that giving a team some tasks to perform during a short period can generate a lot of bias.
The project team leaves with several development characteristics to achieve over a time period. As usual, there is a tough negotiation on what is and is not achievable during this period. Like any negotiation, in the end, no one is happy. On the one hand, you have people who say the team could do more, and on the other hand, folks who say it is too much in such a short time …
When you take the Fever Chart (illustration below), you represent the different behaviors. At first, the team explains that it is too much and therefore announces that even before starting the Sprint, the project is already consuming its protection.
This feeling is confirmed with the next scoring; the project sinks even deeper into the crisis.
We perceive teamwork (Agile or not) as when the team meets to find a solution without sacrificing the initial characteristics. This solution, built with the team, brings a natural breath of fresh air to the project since it allows the elements to be put back in order and to recover some of the protection.
This is where those who said the team could do more come back in! “You see you can go faster” (implying “whenever you want”). The second part of the sentence was not quoted but was heard by the team!
Mechanically, to justify that the team was not mistaken in its estimate, what happens? The project consumes the buffer slowly, indeed, and ends up... “right” on time.
The time was “fully” utilized to meet the original specifications. The time allotted has been consumed. But everyone can’t help but think that maybe we could have finished earlier…
In our FLOW Project Management approach, the sexy word is FLOW, and the keyword is MANAGEMENT.
- What is the point of filling the Sprint phase with characteristics that the team does not feel ready to assume?
- What is the point of making intermediate findings/judgments in a project when “only the result at the end counts”?
- And finally, what would have benefited the project and the team if they completed the Sprint content earlier?été le bénéfice pour le projet et l’équipe de terminer plus tôt le contenu du Sprint ?
It is these 3 questions, it leads us to think that Sprint has limits.
It’s these 3 questions that lead us to say that the team would do better to come together as their characteristics develop. To put them against the global project, rather than as part of the Sprint.
Finally, these are the 3 questions that let us think that Sprinter is useless …
Identify your critical task sequence.
Assume that these tasks will undergo variability that will impact the project and not the task (or Sprint).
Protégez le projet (et non le sprint) de cette variabilité.
Protect the project (not the Sprint) from this variability. And focus your team on those critical tasks to reward them when they find a solution, an improvement, or worse … complete sooner!
To find out more about Flow Project Management, do not hesitate to contact me!