Waterfall vs Agile(History)

Software is hard, working with people is harder. How have we dealt with this problem?

History

Erik Meijer’s put it best in his amazing presentation One Hacker Way.

From the Fleet Marine Force Manual Chapter 1. Replacing the word warfare with software

Excerpt from Fleet Marine Force Manual Chapter 1
“It is primarily shaped by human experiences”

How did we get here/Where are we at?

Most would agree that developers are among the smartest people. They can wrangle computers into doing almost anything
given enough time

So when you ask them to make something, they will disappear for a few days and come bak with something amazing.
The problem is

Its often, not what you asked for

The obvious next step is to make your specifications more specific. Ask more questions, write better documentation.
Hire someone who’s a developer/business person (Business Analyst?) and get them to speak to the Developers.

Maybe you go one step further and get someone to look over the entire solution(solutions architect) so they can
add to the specifications document.

Layer after layer is piled on top of the developer to filter the requirements. At the end, the Developer is told
exactly what to do to the nth minute detail.

The problem now,

Its still not what you asked for.

At this point the developer gets frustrated and demands more details be added, and the cycle continues on the next
project.

This approach of trying to get it right in the first place is called
Waterfall
and it can be good, if you’re making something you’ve made before (you know what the end product looks like),
otherwise…

The fundamental problem

“Business people don’t know what they want until they see it”

This is not a bad thing, its human. The reason business people pay to have custom software made is because it isn’t
available commercially off the shelf

Enter Agile

Now we get to Agile. Better explained as iterative approach to software

The general idea is to embrace change. Know that it will not be perfect the first time, know that things will change
and expect it.

Instead of concentrating on getting perfect design requirements, focus on getting “ok-ish” requirements
and when you see the end product, submit a new change. Keep doing this until its exactly what you want.

Next time I’ll talk more specifics on my approach to leading an Agile Transformation and what it takes to be an Agile
Coach