What form of requirements makes most sense to developers? If there are multiple cultures in the mix (Chinese in my case), what makes sense as requirements. Should we do big documented use cases, should it be process diagrams, should it be working prototypes?
There may be some fundamental assumptions – how different human brains processes information, what the established literature recommends, and what works in different team and cultural contexts.
What my team struggled with is dealing with a distributed team and laying out the right format of requirements for them to be productive. Initially, my assumption was that in case of a distributed development team that perhaps lacks the full context of the problems that the software intends to solve, we should focus on creating documents with excruciating details thrown in. So get those requirements specifications to be so well documented that a person with relatively zero context can covert it into working code that fulfills the original goals and desires.
Using the templates set forth by Alistair Cockburn, in Effective Use Cases, we felt pretty good about the format. Others in the team suggested using Control-Action-Response matrix for each UI element on the screen in conjunction with the use cases. This became a laborious process, but we did get it done. What we realized was that the biggest beneficiary of these detailed use cases were the QA team members who got a ready-made template to convert into test cases. The other beneficiary was the offshore development team, who were kind of cut off of the whole contextual nature of the solution. The offshore team members were tackling a completely unfamiliar domain and they lacked the proper preparation to come up with any innovation on their own. The use cases became a very very hard specification of what was supposed to be developed. Very infrequently were the requirements questioned and alternatives proposed.
However, the onsite development team was on a different track. These team members were visiting the end-users regularly, sitting down and observing them, becoming their apprentices for a day or two to really grasp the nature of the problem. Their contextual awareness was very high. In turn, they became one of the chief sources of innovation. The ideas poured in continuously and made a healthy backlog. These improvements were recorded as normal enhancements into JIRA and formed the basis of many features that were absolutely loved by the end-users.
Recently I checked out the “Head First” series of books. These books excel in condensing the relevant information for the brain to process in a very precise, humorous and entertaining fashion, while educating. And I wondered to myself – could this form a model of how we record requirements, how we conduct trainings, and impart education in the classroom. If a teacher is part educator, part entertainer – there is a better chance of him or her engaging the students.
Here are some tools that may help create more entertaining requirements documentation.
Balsamiq Mockups – This is one of the best mockup tools and is very easy to use. I frequently use it to make my requirements documents, and even emails more entertaining. Joel Spolsky is another big user of this tool to help create entertaining essays.
Flickr Creative Commons – I use this site heavily to draw from thousands of funny, humorous photographs to illustrate a point. I am always looking for situations that are well described by some photograph to capture the reader’s attention. Of course, you can draw from your own pool of photos if you have them as well.
Image courtesy – J from the UK at Flickr
ScreenFlow for Mac – Video is the most under-rated tool in requirements definition and can really make a difference in your deliverables. I use ScreenFlow for Mac, but there are equivalent screen recording softwares for Windows as well. For iPhone and iPad, there are numerous apps that will record and screencast.
VoiceThread – Why restrict collaboration to text, images, video and audio. Why not use everything in combination? This is the promise of VoiceThread which allows users to interact asynchronously using any media.
During the course of helping clients execute their projects, I observed a common theme across industries. There was a disproportionate amount of project leaders who were strong “drivers” and were “making things happen”. However, beneath the surface revealed teams that became dependent on having such drivers in place.
So I went and re-read Steve Yegge’s landmark article on “good agile, bad agile”. He talked about emergent properties versus the whip. In most organizations, CEOs put “whips” in place to drive projects to completion.
How do you know, if you are in a similar organization? Here is a simple formula:
Take the number of meetings you have every week and multiply it by the number of written status reports you have to provide. If the number exceeds 5, you are probably in an organization that has multiple layers of “whips”.
Ask yourself the question: if no one were to tell me, would I have a clue about what I needed to do for the next 3 months? If you are having trouble coming up with the answer – you are probably in an organization which has not worked on creating emergent properties.
Now surely, there could be a healthier way to promote self-organizing teams. Are we inherently flawed such that in absence of strong direction and push, we are simply incapable of reaching a goal? As teams within organizations, have we just accepted the fact that instead of strong team players with single minded vision, we need to rely more on strong drivers who can push people to get things done?
Ricardo Semler set something in motion at his company. Google believes in emergent properties and incentivizing teams towards self-driven launch goals. Southwest Airlines practices what they call “warrior spirit yet servant’s heart” . But such companies stand out among hordes of other companies. These are companies that are not only ahead of their competition in terms of the best workplaces, but also outperform others in the long term.
Recently, at a conference, I had a chance to interview ReadyTalk co-founder Scott King. ReadyTalk was recently chosen as one of the best places to work in Colorado. According to Scott, their main goal is to be a great place to work at, rather than be the largest company in their chose market space. They intentionally avoid external investor pressure and work hard on their organizational culture as they firmly believe that employee satisfaction reflects directly on a company’s bottom line.
In conclusion, look for signs of a “whip” on your team, don’t panic. Understand the motivations and work with your team on being self-propelled towards a common goal.
Where do most enterprise software projects go wrong? As a software manager, how can you ensure that the next application your team is about to build will revolutionize your enterprise? Here are my top ten ways to ensure failure to raise the body of work beyond mediocrity: