The best teachers I have ever had made their finest points outside of the typical every-day classroom lesson. A long time ago, my fourth grade school teacher wanted to teach us a valuable life lesson. He whispered five sentences into the ear of a student in the first row. She then whispered the sentences to the next kid and this went around and around until the very last student had the information. I recall being somewhere in the middle of this long whispering chain. Not surprisingly, the information had completely changed, and also, this being grade school, the results were very amusing.

Information is delicate

The teacher was trying to show how rumors and hear-say can quickly change what once might have been truthful information into something you would never trust as fact. At the time, I was more worried about what might have been packed for me at lunch, or passing my next spelling test, so I haven’t thought about this for years.
Before AGILE development became hip, the process to create software involved getting some kind of requirements at the beginning. At the end, we would all bite our lips while showing our product to those paying for it. All of the technical concerns of scalability, separation of responsibilities, using the right tools, none of this matters if the business isn’t getting the product they actually wanted. When things go wrong at this point, its very bad. Money has been spent, trust disappears, and the project is in serious trouble.

The honest truth

Let’s be honest, even the most diligent business analyst isn’t going to have every detail about the requirements. Sometimes, conditions change beyond anyone’s control. In fact, I was recently on a year long project where in the final month, a whole slew of new requirements rolled in because of foreign regulatory changes. We must accept the fact that requirement will change. As requirements change, so too will the approach and technical solve.
AGILE came along with a significant change in how we approach product development. We still have a notion of initial requirements, but the inception only covers a starting view of the project and often excludes fine detail. Instead of 1 large cycle, we have many smaller iterations or sprints. The units of work played inside these iterations are called “stories”. Each story would be implemented by a developer, validated and finally signed-off by the business and architect. We can measure the performance, or velocity of the team, by how many story points have been completed. This was an important change because instead of setting yourself up for a major disappointment, there are many cycles. There are now many decision points to change scope and to some degree, the technical approaches. This does not mean you can re-invent the application every iteration, but it gives us more flexibility.
Now let’s think about this problem again, only this time, with-in a single iteration. For any particular story we play, we may think we know everything at the start, but often don’t.
The business analyst writes a story by themselves, hands it to the team and sits back and expects the result to be exactly what is expected. It all makes perfect sense when you are the one person writing the story. Too often, this ends in disaster. The developer picks up the story and thinks one thing. A QA picks it up next, possibly thinking something different. We hope at sign-off what we have is what we expect. If it’s not, the story gets moved back. Just like in my fourth grade lesson, information at one end of a chain does not resemble what we end up with. A story implementation can work out, even in-spite of bad communication, but we are missing out on an opportunity to shape the product we want.
You may have stories that get moved back at sign-off. If the business is not active in the sign-off of stories, you may notice new stories covering the same ground. How this manifests itself from group to group may differ, but there are ways to measure this phenomenon.

Continuous touch-points

We need meaningful touch points with-in the sprint itself. Without this, the work done for the whole iteration can often be disappointing. This begins by the business analyst and technical team writing the story together. In particular, the acceptance criteria of the story are the confluence of the requester and responder of the work defined. I am not taking about a mini-inception or any additional amount of time to be spent. Simply, that the time spent communicating in isolation be substituted with some collaboration. As the architect, in helping to write the story, I include sections for design, implementation and testing considerations. This helps align the approach for developers, QA’s and forces us to answer the needed questions up front. Some teams include a “desk check”. This is another touch-point just before the QA would start validating. At this time, the business can get a preview of how something works, and the architect can see that it was implemented as expected. The final touch-point is the sign-off. Ideally the QA that validated the story gives a sign-off demo to the business and the architect. If we have the other touch-points with-in the iteration in place, the sign-off should go fairly quickly and easily.
The product will be better because the design will accommodate knowledge of the future. The developers now have clarity in the stories they pick up and how it fits in with the overall design. The QA’s can validate the story with greater understanding of what actually should have been developed. Sign-offs become a formality and now we have moved our work to done.
We thought that when we substituted a single touch-point for many touch points, our problems were solved. What we continue to learn is that what we must have is continuous touch-points to shape product development effectively.
I suppose if I had to go back to the fourth grade, and re-live that moment again, I could stand up and ask for a huddle or a sign-off session. I probably should be careful though, my teacher had one or more conversations with my parents over my velocity.