agile requirements : lessons from 5 unusual sources

Just a short remark this post: the magazine Agile record has a nice article by Raja Bavani on requirements lessons from 5 unusual sources.

From observing restaurants and waiters, he learned:

1. Welcome customers and stakeholders with a smile whenever
you interact – even when you are on the phone
2. Listen well to understand the requirements
3. Rephrase or summarize your understanding to get confirmation
before you end a conference call or a meeting
4. Believe in your expertise and stay committed
5. Be flexible enough to re-prioritize and accommodate
changes as long as it is not too late
6. When it is too late, be polite and communicate the impact
7. Be open and ask for intermediate feedback during your interactions
8. Feel free to talk about ‘what else’
9. Value time and money
10. Apologize when things go wrong

He emphasizes no 3: rephrase or summarize each requirement to check if you understand it well. Though rephrasing every requirements may be overkill, imho it certainly pays to do this for every requirement that might be unclear or liable for misinterpretation. And of course no 1 is a great way to keep spirits up. In my current project their is one colleague that manages to find something fault with everything. Everything is useless. It is very tiring to work under such circumstances. Keep up a smile, and look for possibilities.

From observing airports and flights he learns:

1. Preparation is critical to success. This is applicable to the entire agile team, including product managers or product owners, agile project managers or scrum masters and agile teams.
2. If you arrive late, you miss the flight. In the same way, you can’t accommodate late arrival of requirements during iterations.
3. Any delays or changes can only lead to further delays.
4. Change management can never be effective when there is no support from all stakeholders. You cannot blame an individual or a small group of individuals when things go wrong because of ineffective change management.
5. Dependency management in large projects is necessary to avoid wait time and delays. In case of large projects with many related projects, we need a function or a team that plays a role similar to that of the control tower in airports. In most cases, we call it the governance team.

His third source are children. Children are curious and explore without inhibition, he says. Though I disagree with the latter, I'd like to stress the positive effects of curiosity. In my youth in native Netherlands, curiousity traditionally was not encouraged in children. Some old proverbs as an illustration: Children who ask are skipped over, children may eat everything but not know everything, a curious ann (een nieuwsgierig aagje), and do on. But curiousity is the engine of discovery.

Likewise, he learns the importance of communication skills from schools and teachers.

His last lesson comes from ant colonies. I'm not very convinced about what he writes here, so i'll skip this topic, though what he writes about team roles is true.

You can find the complete pdf here. Certainly worth a read!