One of the games that we played at our internal annual indoor games was Clue 16. The game was played by two players. One player could think of any person or place and the opponent had to guess what did the other person thought of in series of 16 questions which can only be answered in Yes or No fashion. Now lets say you are playing with me. You come up with “Mother Teresa”. And my questions go like this:

1. I could start by asking: Is it Bill Clinton? The answer is obviously no.
2. I could then ask: Is it London? The answer is again no.
3. I could then ask: Is it South Africa? The answer is obviously no again.
   • And so on…

As you would see, I am going to exhaust my options pretty soon and chances of reaching “the solution” are pretty low. A better approach is to ask the question in “a series of sets”. So it could go like this:

1. I could ask: Is it a person? The answer is a Yes and hence, we rule “place” out.
2. I could then ask: Is the person living? The answer is No.
3. I could then ask: Is the dead person a woman? The answer is Yes.
   • As you can see we are at a much better place at the end of third question compared to first round of reasoning.

In a set based theory explanation, this example is provided through a 2-player in a room game where the first player can only guess objects from a room only. If the opponent has 20 [instead of 10 questions] questions to ask and each question eliminates 50% of options, the game is winnable with certainty in a room containing up to 2¹⁹=524,288 objects². Hence, you can see the trick is to ask the right questions at the right time. It would be very risky to ask the question - Is the dead person a woman as the first question. You could get lucky [we could write an essay on risk and luck too :)] but chances of not being lucky and hence, risks are high. Or, you could ask the question if you knew that the other person is only going to think about a dead person. This is a big assumption, but if you can validate it with some degree of certainty, it is probably worth asking this question. Also, asking questions through “sets” or “regions” rather than “specific instances” is more efficient. You will identify the region as “worth looking into” or “not worth looking into“. This is useful either ways.

As discussed in the web page on set based design, recent work provides evidence that commercial success is correlated with set-based thinking. Also, this can enhance an iterative process even further. Traditional iterative processes first hit on a solution and then try and refine it. Set based concurrent engineering methods emphasize the need to first target multiple alternative/ options and then eliminate the options to converge on a given option. It is a bit of an overhead to start with but the later stages more than make up for it. Further, the risk in the later stages is lower using this approach. This is because you have narrowed down the paths you don’t want to go and selected the most relevant space to look for a solution. And the biggest risk is to look in the wrong area. As can be inferred, this has profound implications for new product design. Hence, set based design approach helps us by:

• Helping us defer decisions till the last minute when the best information is available
• Explore many design alternative at the same time
• Converge designs more quickly

Working with a set based concurrent engineering approach could actually enhance the efficiency even further. Concurrent Engineering is a business strategy which replaces the traditional product development process with one in which tasks are done in parallel and there is an early consideration for every aspect of a product’s development process. This strategy focuses on the optimization and distribution of a firm’s assets in the design and development process to ensure effective, efficient and concurrent product development process to minimize duplicate or repeat effort and risk. If we see an example within a web development process, then concurrent engineering would mandate requirements gathering, analysis, graphics design, architecture design, development, testing and deployment at the same time. This in itself is known to improve productivity. In concurrent engineering, collaboration between various design groups/ departments is stressed. In set based concurrent engineering approach, various design groups reason, develop, and communicate about sets of solutions in parallel and relatively independently. However, they are free to talk to people working on the other sets, rather encouraged to. As various design groups ask questions and find answers to them, they narrow down their respective solution sets. The fact that each of the participants choose a different path means that rich information and feedback to lot of scenarios is available. Theoretically speaking, more the design groups working, reasoning and communicating about sets or options or alternatives in parallel, the better is the chance of an optimized solution solution. Optimized systems generally provide greater overall efficiency. Toyota uses SBCE rather well. SBCE can be used in software effectively as well. One of the places where it could be used is to decide between three-four different alternatives for coding language i.e. answering a question like should we use C++, Java, .Net or PHP. This is how we can go about it:

• 4 pairs can pair program to spike on what they feel is most complicated or strong case for their language in the project
• They are free to talk to each other during their work particularly about how would they evaluate their exercise
• They record their findings and experiences and more than likely for a web based application C++ pair would probably give up and Java pair would probably record findings which suggest heavy overhead and the pair suggests use of Java as non-feasible [and on some projects it could actually be very useful]
• PHP and .Net group would benefit from the findings and depending on the project, the decision could swing either ways

The trick in SBCE, is to realize what decisions you can defer and what you must take now as well as how risky or difficult would it be to change a decision later. For instance, the decision to change a programming language later in the project is momentous. However, just changing the search algorithm is comparatively not as difficult. From a risk perspective, wrong choice programming language is potentially a huge risk while wrong choice of search algorithm is comparatively a lesser risk. Through the user of SBCE you would like “risky or difficult to change later” situations and decisions to be minimal. Decisions like programming language are probably irreversible but some others like architecture and algorithms can be taken with a view to maximize alternative approaches. A modular approach [SOA, Layered Architecture, Network Protocols, Machine Independent Language] for instance, is known to improve design alternatives. Many examples of modularity are based around the ideas of abstraction and of an interface: two parts make a commitment to how they will “talk” to each other, but no commitment about what happens beyond the interface. Another approach that can help in not doing something wrong is simply not doing it. The implication is so profound and challenging probably because “not doing it” is not considered as an alternative at all. However, not doing it “now” could allow us to do it better when we really need it or have enough information about it. In case of new product development, where multiple scenarios would probably need to be tested, carrying on with multiple approaches can help. Lets take an example of a “landing page that converts”. Assigning one designer to work on the design is a point based approach. Having 03 designers come up with 03 different designs and each tested/ evolved separately would either yield the best design among the 03 or better still through feedback from each other 01 collaborative design that is better than the best in the 03.

As we can see collaboration, reaching the optimal solution, multiple scenarios, flexibility, minimizing waste and efficiency are the key objectives of set based concurrent engineering approach. This align perfectly with Agile.

Popularity: 15%

Posted on January 10th, 2008 by admin
Filed under: Business Alignment, Collaboration | No Comments »

MingleNow.com was one of the projects that started the Agile wave at Net Solutions. Ishita Chaudhuri, the project manager, was involved in the project from conceptualization in October, 2005 to its final day on January 07, 2008. In this email interview, she shares her experience in the world’s leading nightlife social networking website.

agilecollab: What has been the greatest learning personally and for the team, by working on MingleNow.com?

Ishita: MingleNow.com was a technically challenging project and we learnt many new things. The client for this project, Blue Lithium was one of the largest advertising networks in the world and as you would know they were recently acquired by Yahoo. We expected it to be fairly challenging but the combination of technical and business dynamics, made this a unique and complex yet rewarding project for all of us. Specifically, we learnt how to handle multiple server environment ie. how the code functions on a cluster of servers and optimization of code using memcache and pearcache. We also had a do a a little bit of unlearinig i.e. optimizing database by de-normalization. The team also got a chance to work on advanced perl scripting using image resing functions with Imagemagick. MingleNow.com was among the first projects to have a central code repository and use XP principle of shared code. We used SVN and created an automated environment for coding and deployment using SVN. We also did some automated testing using Selenium and load testing using JMeter. From personal view point, I think I learnt a lot about how to understand and respond to the customer’s expectation and how to maintain cool in a critical situation. It took some time to reach a stage where I could look at a critical issue and not jump out of my seat, instead thinking of ways to sort it out, having a plan b etc. And most importantly the team learnt how to organize itself to be responsive and accept change as a way of life for a new product development.

agilecollab: At what stage did you decide to abandon the idea to control the requirements and rather organize yourself and the team to respond to changing priorities?

Ishita: Around the time that we released the beta, we realized that there were lot of changes just after a deliverable. For instance, we changed the design of the complete website 04 times in 02 years. These changes were necessary for the site but were eating into the approved time for the project. This made us look for a solution that would be beneficial for both the client as well as for us. Hence, we went from a fixed price approach to an hourly approach borrowing some principles from Agile - like daily team meeting, collaborative code and a roster of prioritized requirements. Other things followed.

agilecollab: What sort of “testing” was implemented on MingleNow.com?

Ishita: All the team members tested their code before releasing it to the repository. There was no automated unit testing done however. At one point in time, the site got so advanced that it was not possible for the testers to test everything and hence, we added a mechanism for rigorous automated testing as well as dedicated team member for regression testing. Upon the request of the team [and conceded by the customer] we had three servers ie. development server (for coding), QA server (for checking final deliverables after merging) and live servers. We also had a big beta testing phase and lots of bug bashes internally which gave us insight into usability issues.

agilecollab: How did you work with “UI design team” and what are things you will keep in mind next time around?

Ishita: The UI design team was involved in all the discussions and hence were aware of all the functional requirements of a module and they also used the website as regular social networking users. They were encouraged to use all the sections of the site. This gave them an idea of the usability issues and they kept those in mind while designing for newer modules. Design concepts went through 4/5/6 and more iterations normally. These iterations were based not only on client requirements but also the development team’s feedback. After a while, the self organized process worked like a dream.

agilecollab: What was the biggest “team organization” challenge in a project that spanned over 2 years?

Ishita: The design team and development team worked at different hours so initially it was difficult to co-ordinate the discussion timings but then two designers volunteered to work as per the development teams hours and at each stage we had at least 02 designers working with us. This helped us a lot. Also, initially some of the development team members were used to working on single projects or maintenance projects only and hence it took them a little time to get used to the multiple developer scene but since modules were developed in such a way that at a time not more than two developers were working on a module, it was manageable. Another challenge was to work with the freshers in latter part of the project. However, the team members showed remarkable affinity to train, pair program and mentor the new resources.

agilecollab: Finally, how do you feel about MingleNow.com coming to an end and what is in store for the new year?

Ishita: Personally, I feel a little sad that MingleNow.com has come to an end because it was the first project that I worked on as a project manager and I would believe that I gave it all to make it work. It took a while for us to come to terms with the announcement. I also felt difficult to break the news to the team. When I did tell them, some of them also felt the same. It took a while to get out of the daily routine of chats with Krishna and his team for the first half of the day and then the mad rush of making the changes, reviewing, testing and getting it ready. The way users on the site took to the new features and their constant feedback kept us going and the constant growing number of users on the site pushed us more towards giving it our best.

Popularity: 15%

Posted on January 9th, 2008 by admin
Filed under: Case Studies, Interviews, Skills | No Comments »