The Post-it seems inseparable from Agile management, but: manipulating Post-its adds no Agility to a project. You can manage an Agile project without Post-its, especially outside software.
1) Post-its are misleading
Some Agile tools use Post-its
Kanban and Scrum boards use Post-its. KanBan means "signboard". The Post-it is valued for its repositionable nature. Electronic versions also exist, sometimes with added complexities that give team members the impression they are doing useful things (when in fact: they are not).
Yes, Post-its are associated with Agile tools, but...
These Agile tools are not suited to every project
It is important to identify projects that could benefit from Agility. The others should be managed traditionally.
Some projects or project phases are not suited to Agile tools. Using Scrum or Kanban on non-Agile projects does not work, just as traditional management does not work on R&D projects: delays++, tensions++, budgets++.
Some projects should not be managed with Agile tools that manipulate Post-its.
Using Post-its does not make a project Agile.
The Post-it is a tiny part of the project
Before sticking Post-its, you need to write them. You write them by breaking down the project into tasks (WBS).
Example of a traditional breakdown:
- Requirements analysis
- System design
- General design
- Specification
- Component testing
- Integration testing
- System testing
- Acceptance testing
This waterfall breakdown (or V-model) prevents the small-step progression that defines Agility.
It is not the Post-it that defines Agility but the way you break down the project.
Tasks are activities, not results
A Task Board tracks activities, not necessarily the project's progression. Pareto 80/20.
Example: "Acceptance testing" moves from "in progress" to "done" = progress in management, but if the test fails, the project actually regresses enormously.
Advanced: an effective board should manipulate Post-its with Measurable Objectives rather than tasks.
2) Managing an Agile project without Post-its
Back to the basics of Agility
In traditional management, you start from precise specifications and an exhaustive task list.
When you cannot do that (R&D, 25% cost reduction = breakthrough), the team must use Agility. In Agile, there is no predefined task list. Risks and unknowns must be addressed DURING the project. The art of Agile = securing the project without a predefined path.
Even if you wanted to monitor activities, it would not be effective since the list builds up as you go.
So you must monitor the progression of a result
Preferred indicator: "I have painted n% of the surface" (result tracking) vs "I have painted for n% of the planned time" (activity tracking).
Tracking indicators should not be based on tasks but on the progression of a result.
Iterative incremental in action
Two types of projects: continuous progression or breakthrough. Both use the iterative incremental approach.
- Continuous progression: direct indicators ("percentage of surface painted")
- Breakthrough: indirect indicators ("level of certainty of finishing on time"). Strange at first but incredibly effective over the project's duration.
No need for Post-its to track the progression of an Agile project.
3) R&D specifics
Difference between Software and Hardware projects
Software (frequently testable) does not progress like an R&D project (electronics, mechanics, chemistry). The difference = the granularity of progression.
Example: "Develop a website" vs "Have a 2-tonne injection mould manufactured".
Really that different?
Let us challenge this difference: do not confuse finished products with the development phase, which can have similar intermediate steps. Agile development stops at the mould definition (before manufacturing), and this upstream part resembles software development.
The real difference
Agile management addresses risks and unknowns. The difference = the nature of the risks.
- Website: the main uncertainty is the content. Technologies are known.
- R&D: the objective is known but we do not know HOW to achieve it. You may need to invent or adapt technologies (using for example the ASIT method).
4) Tracking an R&D project = tracking a search for solutions
R&D projects consist of searching for new solutions. Examples: reduce cost by 25%, double the frequency without impacting cost, find a differentiating communication angle.
Example 1) Reduce cost by 25%
You cannot achieve 1% then 2%... A breakthrough solution is needed. Tracking cost progression alone gives a misleading indication.
Indirect indicators:
- Validated reduction with the identified solution
- Certainty level of reaching 25%
- Expected theoretical reduction from the current solution
- Already observed reduction
Example 2) Double the frequency without impacting cost
The team can improve the existing by +10%, but that is useless since the final solution (+100%) will be technologically different.
Strategy: list technical avenues with estimates, decide which ones to pursue, make them concrete (do not deceive yourself).
Example 3) Find a differentiating communication angle
Either you have it or you do not. Working on a poor message will not improve it enough (differentiation is not improvement).
Tracking breakthrough
In breakthrough projects: the solution either exists or does not. Managed with Agility, progression is iterative incremental, and tracking uses indirect indicators.
To explore this concept further, watch this video on "Trouvage" (Finding): www.youtube.com/watch?v=9J9KyAHbWOY
To go further, discover the Agile R&D training to learn how to manage your projects without Post-its, or the Agile coaching for personalised support. Also find more resources on agilitehardware.fr and our client references.
