A team with long experience in waterfall experienced agile development.

Summary

I works as a consultant and coached a team with long experience in waterfall to develop a product by agile. I lectured some agile practices and I asked what they thought about them.

Practices which I lectured

• Sprint
• Task management with Kanban
• Test Driven Development
• Pair Programming
• Refactoring
• Estimation by story points

Impressions of introducing Sprint

• In the first sprint, we only focused on the most valuable feature so we designed it and coded it immediately. I thought it was good that the span of PLAN to DO was short. Because in the watarfall case we cannot DO(coding) until we PLAN(design) everything and this is too slow to verify that the product is really valuable.

Impressions of introducing Task management with Kanban

• Task size was smaller than we do in the watarfall and I was glad I could concentrate on the small task. I didn't need to see other modules or functions.
• I could see who do what, so I didn't need to worry about progress.

Impressions of introducing Test Driven Development

• It was very interesting to develop product gradually.
• Test driven development seems to be incompatible when test specifications and test reports are requested as deliverables
• I think it's very interesting that the test behaves like a specification, so I'd like to actively incorporate it if I can get the customer's understanding.

Impressions of introducing Pair Programming

• Troubles are solved immediately and it is easy to do (less time spent worrying alone)
• I spend more time thinking or doing research than coding, so I thought pair programming does not decrease productivity.
• It seems to be incompatible with man-month calculation.
• There is no atmosphere of coding with people(normally alone) in the current position, so introduction of pair programming seems to have psychological obstacles.

Impressions of introducing Refactoring

• The end of production means the end of the project in watarfall, so there's not much motivation for refactoring.
• Code doesn't have to be pretty. If it move, OK!
• But I know I should code cleanly.
• Because specification of product can change every weeks in agile development, it's important to keep the code base so that changes can be accepted.

Impressions of introducing Estimation by story points

• Accuracy was higher than estimated by feeling
• I was able to experience that the accuracy improved with each sprint

Conclusion

Waterfall development is vulnerable to change, and programmers at the site are aware of it.
The importance of doing things like "I don't know what the user wants. Let's make a hypothesis and receive feedback to grow the product" is increasing in this age.
In doing so, the above agile practices may be helpful.

I want your comment.

I am Japanese and in Japan almost all of development is waterfall.
I work as a consultant to change their mind, skill, or company system to move to agile from waterfall.
I want to know about your country case.