How things are connected in the financial Crisis

This has little to do with distributed development. But a simple explanation of how the credit crisis happened.


Part II

Use Adobe Connect and Confluence Wiki For Agile Design

My product team and I just completed a critical two week design session for the next release. Our user experience designer from Germany flew to Bangalore and I joined the team via phone and Adobe Connect from California.

On day 1: The user experience designer came prepared with basic design screens based on our prior customer discussions. We had a few CLOUD level summary use cases written on the Confluence wiki.

We then started the discussion at the summary level use cases and added SEA level use cases and some FISH level use cases to the page. While the discussion were going on the UI designer composed the UI on here computer while sharing her desktop with everyone else via Adobe Connect.

So all along the discussion about the workflow, everyone could see the proposed basic UI design and shape their questions and conversations around the use case and the associated UI screens. This was very effective.

I took charge of the use cases and expanded them where required. In some cases we realized we need new use cases and created new ones. As more and more use cases emerged, we grouped them by actors and summary use cases.

At the end of each 3 hours session, I sent a summary email with the use cases that were changed along with the action items if any. The development team added comments and thoughts below the use cases posted in the wiki.

We then started adding UI images to the use cases. The user experience designer added images to the use cases.

On day 10 we went through the use cases one by one, reviewed the completed UI screens and marked the use cases as complete. Some were identified for future discussions.

We concluded the design process we followed was very close to the agile software design model. Iterative design, frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid design of high-quality software, and a business approach that aligns design with customer needs and company goals.

Using a Wiki to Organize Your Use Cases

Chaper 13 in Alistair Cockburn's book 'Writing Effective Use Cases' is just two pages long. But it is one of the most effective chapters in the book. In this chapter he talks about scaling up to many use cases and using tools to organize them.

• Say less about each use case: He argues that the use case name alone is useful. He says that the collection of use case names is an excellent working medium for manipulating the full set of use cases. This is true. We maintained all our use cases on a single wiki page and linked every use case heading to its own page. No big deal. But the list of use cases we had not written was highlighted in red and clearly indicated to everyone the status of the use case. It had not been written.
• Create clusters of use cases: We created a list of high level [Cloud level for those who know the Cockburn usecase hierarchy] use cases and then grouped the lower level [Sea level usecases in the Cockburn hierarchy] below them. This quickly gave us an idea of the high level use cases, the use cases below them and their status.
• Group Use Cases by Actor: We also grouped use cases by actors. We are building a learning system. So the actors were learners and administrators. This further clarified the use cases to the team.

Cockburn also says that the use cases can be grouped further by development team and release and by subject area. We have not gone there yet.

Mr. Cockburn talks about using Lotus Notes or spreadsheets to keep a list of use cases and cluster them. He wrote the book in 2001, when wikis were not popular. Probably that is why he did not mention the wiki.

However, it is is 2009 and Web 2.0 is here. We posted all the use case names in the wiki, clustered them by summary goals, and by actors and evolved the use cases over a period of a month and an intense one week design sessions where we uses the usecases as social objects for our discussion. Whn ever one of us was not clear about the discussion, it was possible to come back and ask the question, "Which use case are we talking about?".

While the team was discussing the product managers updated the use cases in the wiki with relevant details. The UI designer provided quick screen shots for inserting in the use cases.

At the end of each day's session the product managers sent the links to the updated use cases to the entire team. The development team added their comments, thoughts and questions in the wiki page. Since the product managers subscribed to the use cases wiki pages, product managers got instant updates of the questions, answers and confirmations.

After the first week of design sessions, the product team confirmed that the week has been very productive and the entire team had a good handle on the design. Not everything is done. But we know what we know and have a clear idea what we don't know. We know what we have done and what needs to be done.

If your product team is distributed, use a wiki to capture your use cases. It can be your secret weapon.

We use the Confluence Wiki to write our use cases.

I did not mention how our UI designer shared her screen using Adobe Connect so that all along the discussion everyone can watch the design morphing from conversation to onscreen elements. More about that later.

Numbers about the virtual workforce

750 million virtual workers in the world by 2011. 75% of them will be in the US. However business processes are not designed for this virtual workforce. Useful thoughts by the author of the 'Uniting the Virtual Workforce'. They say that reducing virtual distances will reduce cost. Web 2.0 technologies can reduce virtual distances can improve productivity. Web 2.0 technologies can create context. Web 2.0 technologies can enable specific conversations that provide this context. Create dialog that helps teams fill in the blanks.

How can community software help Human Resources team

This is an excerpt from what SocialText says HR can do with community software. "They (HR) can engage employees in highly active, ongoing conversations, and create a more open, transparent, and trusting culture. Employees in new or changed roles quickly see what others are working on, discover others who might be important to them, and learn from documented best practices of their colleagues. People can jump into conversations underway, and tap into corporate memory to quickly absorb the history of important topics. With rich profiles that let colleagues get to know each other better, ambient awareness of what others are working on, and the means to discover social networks, trust levels rise and the culture shifts to one of strong teamwork and independent thinking."

It is interesting that SocialText still refers to their software as collaboration software and not community software. May be the word collaboration is better understood than the word community. One of my colleagues from work told me yesteday that the "potential for collaboration is inherent to community but you do not necesserily achieve or enable community in collaboration".

Pbwiki's Free 2GB Wiki

PB Wiki now gives a free 2GB site which you can use for collaborative content creation. It is a great tool that can be applied to many development situations. Content developers can use the site to script content. Software development teams can share their specifications and use cases. Quality teams can keep track of their issues and status. Great tool. I hope pbwiki succeeds in their efforts of providing simple collaboration tools.

Writing Effective Use Cases By Alistair Cockburn

A few months back I read the book 'Writing Effective Use Cases' by Alistair Cockburn. I like his classification of use cases as CLOUD, KITE, SEA, FISH and CLAM. Simple yet very effective way to discuss a use case. It is very easy to say "Oh! I think it is a clam" to your team mate, rather than saying "I think that is too detailed". The approach works well for collaboration over the phone.

Use Cases As Social Objects

I now manage a product that has team members in California, Germany and India. We started posting our use cases in our internal wiki so that everyone in the team can see the list of use cases we have. We slowly expanded the use cases over 10 different discussions and evolved it with user interface screens, questions from developers, comments from product managers and so on. Such a collaboration is enhancing the value of the information in the use case. It is also bringing the team closer to a common understanding of what we are building. I will provide more updates on this.

You Tube Videos In My Blog

Added YouTube Videos on Web 2.0 to my blog today. I am displaying videos tagged with the key word Web 2.0 now. I think Web 2.0 tools play a key role in distributed teams. Hence the interest.

Added Twitter feeds as well. Since I send tweets using my mobile phone while I am listening to a presentation or reading an article outside at a cofee shop, I think it is good way to share my quick thoughts.