Detailed Specification Docs, Where good use cases go to die

I have seen that the longer and more detailed a software specification document, the bitter and contentious the discussions are. This is particularly so with teams that do not work in the same location.

So we decided to take a different approach. Instead of defining the 'spec' as a document we defined it as 'A common understanding among product managers, architects and user experience designers'. So instead of striving to write the spec, we strived to arrive at that common understanding.

This is where techniques such as use case creation as a team, trips to customers sites as a team and user interface creation as a team came handy.

When development team members had questions about the use cases and the spec document we posted on a wiki, they posted the questions as comments and product managers answered the questions as replies to comments. This process was followed slowly and steadily until the entire team arrived at a common understanding of the solution.

The final spec? Oh! That was written in a day and posted in the internal spec tool we had. No one bothered to discuss the 'spec' because everyone knew what was in the spec and everyone had a common understanding of what the spec meant.

Look for my earlier posts to read about the use case creation process.

Geography is more powerful than technology

A couple of years back I said that Geography is more powerful that history. I also realize that Geography is more powerful that technology. You can overcome distances with online meeting software such as Adobe Connect , Cisco WebEx or video conferencing software. But you people in different parts of the world are going to be in different time zones. You can't change that. You need to be humble enough to understand that and plan around it. Technology is not an answer to all problems faced by distributed teams.

Writing a book using a wiki

We are almost done writing our book using PB Wiki. The writing part went very smooth. Then the publisher gave us a MS WORD template. So we decided to format the content offline in WORD. This process was not as efficent as the initial writing part. We had to email each other to keep each other posted. Our publisher has already announced the book. You can the details of the book at the SAP Press web site

Personal Capability Index

Personal Capability index is a measure of an individual's capabilities developed through five levels of 'deliberate practise'. The levels and the activities associated with each level are described below.

I developed this methodology to track the capabilites of my team and develop their skills. I recently used it to demonstrate to a class of workshop participants, how their capability improved with every session of the workshop. Dharini Ramakrishnan helped define some of the levels.

The methodology defines 5 stages of self-development.

Level 1: Develop an understanding of the concepts behind the capability by reading a book, attending presentations or attending a training course.
Level 2: Apply your learning in a controlled setting with a mentor watching you and providing you feedback.
Level 3: Apply the lessons learned from your successes in Level 2 in a real-world setting.
Level 4: Apply the concepts in real-world scenarios a minimum of 3 times, enhance it and teach the concepts to others.
Level 5: Perfect the capability, address gaps and mentor others in developing the capability.

When you conduct a training workshop, you can track the over all improvement in the personal capability index of individuals and quantify the development for the participants. More about that later.

John Seely Brown on Informal Learning

John says that corporations needs to be a making environment and a learning environment. He argues that the concept of sending an employee away for retraining is archaic.