browngeek

A QA engineer joined my Scrum team today. He is an experienced engineer and is well respected. The problem is though, he is entirely new to Scrum. His whole career has been in following the waterfall approach to software development.

So the first thing he asks me is “Where is the functional spec?”.

I say - “We have a living document that we update every Sprint iteration.”

He asks - “But how can you write code without a functional spec?”

I say - “Because we don’t know all the requirements yet. We are writing code for the requirements we know so far. When more requirements come, we will factor them in the next iteration.”

He - “You mean you don’t have a design spec!”

I - “No. We rather produce working software that speaks for itself.”

He - “But what will you do when new requirements come in? Change the design?”

I - “No. But we will refactor when needed. That is normal anyway. Even if we did write a design spec, there is no way we will know all the classes we will ever write for the whole release. Instead, we simply whiteboard the design when needed and write code.”

He - “But how will I write the test cases? I need to see the functional spec to write them.”

I - “Do you really only look at the functional spec to write your test cases?”

He- “Well, sometime I also look at the design spec.”

I - “Really?”

He- “Only sometimes. Other times I look at the alpha drop.”

I - “You mean you look at the actual software to write the tests?”

He- “Yeah, we can quickly understand what the features are by playing with the product.”

I - “Good. You don’t have to wait until alpha anymore. We will give you a working drop every month!”

He - “…”

I - ” (smile) ”

Most people that are new to Scrum or any agile approach are very apprehensive about the lack of comprehensive documents upfront. They seldom realize that such documents only give a false sense of security (Its just a line item in the Great Master Project Plan ^TM). In each and every case, the final product will be a far cry from the what was proposed in the functional specification months (sometimes years) ago.

The thinking has to change. Fear has to disappear (or atleast hide). Courage has to occur.

The Agile Manifesto principles are

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

I believe there should be a key fifth principle.

Courage to try over Fear of failure