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: 27%

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

Often we confuse leadership with management. Agile teams need more “Leadership” than “Management”. A simple differentiating factor between a manager and a leader is this : “If we took away your position of power given by an official title, would you still be able to influence the others with your opinion, knowledge and intellect?” Ruthless focusing on this rule has helped us identify following “knowledge areas” in which our self functioning Agile Teams need leadership to deliver best quality products and meet the customers expectations with regard to the release schedule:

• Marketing Leadership: this typically comes from people who interface with the client and help them prioritize the requirements by business priority and risks. The result is that we work on highest priority items first, eliminating risk early and providing business value early.
• Technical Leadership: this typically is done at a level of what is traditionally called “technical lead”. The leads help the teams answer questions and guide the teams on technical architecture so that technical debit in a product does not accrue on the product. This enables us to build products that are not only extensible but also maintainable.
• Process Leadership: this is very important for us. The teams need to know what are the simple yet stringent rules of SCRUM that teams can’t opt out of. The teams also need to know how to approach problem solving keeping the values of SCRUM - simplicity, collaboration, time boxing, inspection and adaptation. A leader who can naturally attract confidence of the people helps team learn and improve the process that they select and define themselves. The process leadership also helps the individual team members to answer questions about their own career paths and business - position job alignment.

Popularity: 20%

Posted on December 16th, 2007 by admin
Filed under: Leadership, Skills | 1 Comment »