IDEAS
- Overcome cultural inertia.
- Deteriorated work environment for developers.
- Reducing risk means pursuing less innovation.
- Reducing cost means providing less content.
- Adding people late to the project.
-
People must choose between investing themselves into their projects
or having a life outside of work.
-
Launching software on the same date as some event (movie premiere,
conference, inauguration, etc.) is considered very important.
-
Knowledge is growing during the project. Creating knowledge is expensive.
-
Delivering working software iteratively helps proving that an idea
is viable earlier in development.
Lessons from the past are a good starting place to reveal the reasons
for adopting an agile framework for software development.
"The game market decline in the mid-eighties was caused by the
increased proportion of inferior games released because of falling
hardware costs. The specific logic of each game moved from hardware
to software. With this change, the game developers turned to programmers
to implement games."
Clinton Keith, Agile Game Development with Scrum
Facts
The "Chaos" report published in 1995 by the Standish Group include
several hard facts, for instance:
-
Average project success rates 16.2% - this means that a staggering 83.8%
of projects were either challenged or impaired.
-
An average of 52.7% of projects cost 189% of original budget.
-
Only 61% of originally specified features and functions were available
in failed or impaired projects.
-
Over 1/3 of challenged or impaired software projects experienced time
overruns of 200 to 300%.
The Standish report provides several clues on how to fix those problems, eg.
- User involvement
- Executive management support
- Clear requirements
- Proper planning
- Realistic expectations
- Smaller project milestones
Des études internes chez Systematic montrent que le coût de résolution
d'un défaut augmentait de 1,6 heures lorsqu'il était détecté dans la phase
de codage, de 12 heures lorsqu'il était détecté dans la phase de test et
de 23,7 heures lorsqu'il était détecté dans la phase de maintenance.
Three simple truths.
-
It is impossible to gather all the requirements at the beginning of
the project.
-
Whatever requirements you do gather are guaranteed to change.
-
There will always be more to do than time and money will allow.
...
Then ask everyone in the room to speak. When someone does'nt speak
at the beginning of the retrospective, that person has tacit permission
to remain silent for the rest of the session.
Whether you finish planning in the retrospective or incorporate actions
into iteration plans, be sure that people sign up and commit to tasks.
Without individual commitment, people assume that "the team" will do
the task, and no one does it.
Magnified facts
- Software people earn a lot of money.
- The kitchen is stocked with free beverages and snacks.
About the Author
Stéphane Micheloud is a senior software engineer. He holds a Ph.D in
computer science from
EPFL and a M.Sc in
computer science from
ETHZ. At EPFL he
worked on distributed programming and advanced compiler techniques and
participated for over six years to the
Scala project. Previously he was professor in computer science at
HES-SO // Valais in
Sierre, Switzerland.
Other Articles
