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 »

Lets start with a quick snapshot of a daily stand up:

• Who should attend - the team including the scrum master/ agile coach/ process coach
• Who should not attend - Customers, management or product owners
• Why should it be standing - This is to help:
  • Keep everyones focus - you are more alert standing than sitting
  • Quick - you can stand comfortably only for a while
  • Able to be conducted right where the team sits
• How does everyone stand - In a huddle, facing each other
• Why should I listen to what “A” is working on - You guys are the same team working on same project or team goals, and you would like to know if something A is doing is useful to you or you would be able to help/ provide insight to A. If team members are still not convinced, the process coaches should find out why the team does not have a “shared committment and a vision”.
• What if customer wants to attend - There are two aspects that you should consider here.
  • Why does the customer wants to know this? Does he/ she not see enough business value being delivered by the team
  • Provide them sprint backlog or a consolidated “team wise” work done. If that wont work, allow them to attend without speaking anything.
• What if A is not available - Do a tele-call in or have a proxy in place or probably send in an email summary
• How long should it last - Less than 15 minutes [roughly around 1 minute per person]
• What time it should take place - Same time, every day of the sprint
• Who decides what time it takes place - The team, the decision can be facilitated by the Scrum Master
• What is A and B can’t make it on time - The team has to figure out a way
• What is the agenda - Basically every person answers 03 questions:
  • What did I do since our last daily stand up?
  • What will I do till our next daily stand up?
  • Is there something that is holding me up?
    • This is all. There are no other aspects discussed like technical details or dependencies etc.
    • To keep the team focusses, its useful that the team talks of things they are doing/ going to do in terms of the sprint backlog
• When do I discuss the problem holding me up - Raise a hand and ask concerned people to stay back after daily stand up and discuss it then OR come up with an alternative plan that does not disrupt the flow of above agenda and make daily stand up more than 15 minute
• Who starts first - No rule set. The team can decide. Some creative examples are late comers start first, pass the card, whoever wears yellow/ blue/ red socks etc.
• How does Daily Standup relate to the Sprint Backlog - After the daily stand up, the team goes to the sprint backlog and updates the same [adds tasks/ edits tasks/ re-assigns tasks/ mentions work remaining etc]Who is the above reported to - Other team members
• Who is the above not reported to [in Daily Stand Up] - Customer, management, scrum master/ process coach/ agile coach or product owner
• What if the team looks at scrum master all the time - Daily stand up is a wonderful opportunity for the team to collaborate with each other and self organize. Hence, scrum master should turn around so that the team can talk to each other rather than them.
• Can Scrum Master question the team during daily Stand Up - No. The ideal place to do the same is “Sprint Review” meeting.
• What if someone has any questions - These can be taken up after the daily stand up
• What if team stands there like bozzos - Let them. Help them get out of their bozzo like existence long term rather than short term. Tell them they have 15 minutes to accomplish this as a team and see how they go about it. They would get better with time.

A daily stand up is perhaps the single most important ceremony in an Agile development framework. As discussed above, the purpose of a daily stand up is simple - “Meet for less than 15 minutes a day to inspect and adapt“. The team meets, synchronizes work, finds out how they should collaborate together, who needs help, who can help and are they on track or they need to re-organize to meet a sprint goal. The important thing here is “the team” does all this. The process coaches can help guide the team but not coerce or lead them to a particular way of thinking.

Although, the daily stand up is a wonderful tool for collaboration, it is also useful to highlight a lot of obstacles and things that are stopping the team from reaching excellence. As you can see one of the question team answers is “what is stopping us from doing our work“? Initially, the teams would make some politically nice statements. However, as the teams use of Agile intensifies, they will start revealing obstacles [we have to reach a QA through a project manager and that stops our work and focus, it would have been better to do a prototype first for this, customer is not available for feedback, these requirements are not clear, we do not have the skills to take on this work etc.]. Before you know there is a long list of obstacle backlog items that need to be addressed. This is where a Scrum Master or an Agile Coach or Process Coach comes into picture, whose main role is to “everything in his/ her power” to remove the obstacles and create conditions for the team to do their work in an enjoyable and optimal fashion. In fact one of the things good coaches should do is to get the team to raise as many obstacles as they can and beyond.

Popularity: 45%

Posted on February 17th, 2008 by admin
Filed under: Collaboration, Introduction, Practices | 3 Comments »