agilecollab brings you an exclusive interview with Ken Schwaber. A brief profile of Ken at Scrum Alliance website reads: Ken Schwaber co-developed the Scrum process with Jeff Sutherland in the early 1990s to help organizations struggling with complex development projects. One of the signatories to the Agile Manifesto in 2001, he subsequently founded the AgileAlliance, a nonprofit organization dedicated to the creation of Agile software. He then founded the ScrumAlliance, a nonprofit organization dedicated to expanding the understanding of Scrum. A 30-year veteran of the software development industry (from bottle washer to boss), he has written three books about Scrum: Agile Software Development with Scrum, Agile Project Management with Scrum, and The Enterprise and Scrum. He lives in Lexington, Massachusetts with his family. His web site is www.controlchaos.com

In this interview Ken answer’s questions about use of Scrum, origins of Scrum, Scrum and Outsourcing, changes required to implement Scrum and the India connection.

agilecollab: You might have answered this a lot of times - how did the motivation for coming up with something like Scrum came about?

Ken Schwaber: My company, ADM, provided process automation products to several of the large methodology companies, like IBM and Coopers & Lybrand. Between all the new features that we wanted to introduce, features demanded by our customers, and our somewhat unstable object oriented technology base, we were overwhelmed. A friend of mine, Jeff Sutherland was experiencing similar problems at Easel. Jeff asked which of the methodologies ADM had automated we were using internally. I replied, “none; otherwise we’d be out of business!” Jeff already had some ideas about Scrum, so we started collaborating. The result was a pretty complete, field-tested Scrum by the end of the 1990’s.

agilecollab: Are you pleased at rapid spread of Scrum?

Ken Schwaber: Yes, in that the spread means that people are desperate for a new approach. No, in that they may think of Scrum as simply an iterative version of waterfall. Many CIO’s still think of Agile as more, faster. However, as organizations and projects flee the existing controls and safeguards of waterfall and predictive processes, they need to recognize the even higher degree of control, risk management, and transparency required to use Scrum successfully. I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.

agilecollab: Do you agree with 50% Scrum approaches? Are there any dangers in this approach?

Ken Schwaber: Scrum is a very simple framework within which the “game” of complex product development is played. Scrum exposes every inadequacy or dysfunction within an organization’s product and system development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them.

agilecollab: Does outsourcing and Scrum work together or you should keep both of them as separate as possible?

Ken Schwaber: Outsourcing can be as simple as additional Scrum teams that are remote. They have the same Scrum responsibilities as any team, and have to test and integrate their work according to the same schedules or as worked out by the teams. Then Scrum works fine with outsourcing. Scrum’s transparency makes any inadequacies visible.

agilecollab: What makes Scrum a good fit for using it with any engineering approaches like XP or even system approaches like Lean?

Ken Schwaber: Scrum is a framework. XP engineering practices can be used within a Scrum Sprint to improve quality and productivity. Lean is a way of thinking that optimized complex, repetitive processes. Product development is more of a one-off thing, where every release and project is more unique than similar. However, much of the thinking that Lean uses is also used by Scrum, so studying lean helps you understand Scrum. For instance, value stream mapping helps optimize some of the processes – such as change control – that aren’t addressed by Scrum. Scrum purposefully has many gaps, holes, and bare spots where you are required to use best practices – such as risk management. Scrum then shows you how well that approach works through transparency, so you can continually optimize the approach.

agilecollab: You must have coached many people now. There must have been a lot of Indians in those trainings as well. Anything specific you noted in the way they respond to the values of Scrum?

Ken Schwaber: I think that the cultural differences are given too much significance. I find excellent, serious, determined professionals from India, China, Germany, Finland, Iceland, and the America’s.

agilecollab: Have you been to India? Any plans for the same?

Ken Schwaber: I ran development projects for the United Nations Development Program from India and Indonesia in the 1980’s. A wonderful people, a long airplane trip.

agilecollab: A lot of people in India say - “Scrum is not suited in Indian cultural context”. You would have heard that probably in many cultures before. There are blog articles who say “Agile is for Bay Area”. How do you respond to this?

Ken Schwaber: Several changes, or cultural shifts, are required to use Scrum. The first is to forget predictive, waterfall thinking. The second is to realize that self-management is a much better practice for productivity and creativity. The third is to understand that cross-functional teams produce more robust products. All of these changes are extremely difficult, regardless of the country. I’d say that the United States has a lot of trouble going from top-down, command and control to self-management; we believe that the only way to get something done is to make it get done. Many large [and other] Indian companies believe the same. Success, competitive advantage, and quality products are the fruits of the change, to those who make this change.

agilecollab: Finally, what are your next goals?

Ken Schwaber: To create many environments where Scrum helps people look forward to coming to work, where customers love working with software developers, and where the quality and predictability of our efforts significantly increases. To help the 25% of the organizations that are willing to make the effort to improve, and to help them beat the pants of those who aren’t. To make it work so well that firms in the United States turn to offshore because they need more people, not because they can’t stand the developers in the United States or just for pricing advantage. And, to help everyone conceive of people as people, not resources.

Popularity: 60%

Posted on February 19th, 2008 by admin
Filed under: Around the Globe, Interviews | 6 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: 16%

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