-
サマリー
あらすじ・解説
Please checkout out this exciting interview with author of Essential Scrum, Ken Rubin. Ken is a distinguished author, speaker, and Agile instructor. He has worked with many of the nation's top companies, and he joins us in this episode to tackle some of the tough questions facing teams as they adopt Agile. If you haven't already read Ken's great book, please pick up a copy of Essential Scrum on Amazon today! You can also read Ken's blog and learn more about his services through his website innolution.com. I hope you enjoy this episode and please remember to subscribe in iTunes. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: coach@agileinstructor.com. All Things Agile - Episode 011 - Ken Rubin Interview Transcript: Welcome to the All Things Agile Podcast – your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast in iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr. Ronnie: Hello everyone and welcome to All Things Agile. I’m very excited to announce that Ken Rubin is our guest today on the show. Ken is a noted author of Essential Scrum as well as being a public speaker and Agile instructor. Before we begin, a quick reminder that this podcast is for informational purposes only and we accept no legal liability. So let’s get started! First off, Ken, thank you so much for joining us on this episode. I am really glad to have you on this show. I’ve given the audience just a quick introduction, but can you please take a few minutes and explain a little bit more about yourself, both personally and professionally? We really want to get a chance to know you. Ken: Sure! So my background is software engineering. My degrees are all in computer science and I’ve had a typical path through most software companies. I’ve been a developer, project manager, VP of Engineering at a number of companies both large and small. I’ve done 10 startup companies in my career, and I’ve taken two of those public on the NASDAQ. I did my 2 year stint with IBM in the mid-1990s. I’ve helped companies and I worked with 130 people; we ran around North America building large distributed object systems and if anybody’s old enough to remember, I came out of the Small Talk world. Back in the late-1980s, I helped bring Small Talk out of the research labs at Xerox PARC, and I worked with a startup company that was a spin-off of Xerox PARC called Barclay System. We were the early market object technology folks. So we brought Small Talk and object technology to the market. I’ve been doing Agile since the early-1990s. Scrum, formally, since 2000. In those days, I worked for a startup company in Colorado called Genomica. It was a 90 person engineering team, and they let the VP of engineering go. I ended up inheriting the engineering team which wasn’t functioning all that well and we transitioned everybody over to Scrum. And that ended up working out much better for us. And I’ve been using Scrum ever since, about 14 years. These days, I spend my time out either doing Scrum training classes and Kanban training classes or doing coaching. And, I hope that in our discussion today I can go over a number of examples that I had the benefit of seeing a lot of different companies and what’s working and what isn’t working. Ronnie: Thank you for the introduction Ken. I’m really looking forward to the insights you can provide us based on your considerable experience. The first question I’d liked to ask you, regarding your book Essential Scrum, is in regards to the dedication and introduction. It really got me thinking about the importance of relationships and software. I also started thinking about how relationships or soft-skills play into the success of Scrum. What is your insight or your advice on how relationships affect Agile teams? Ken: It’s a good question to start with. To me, the unit of capacity in Agile is the team. Even the Agile Manifesto calls that out – individuals and interactions over processes and tools. It really is about the team. So how they interact with each other, how they perform is of outmost importance. The relationships among the members of the teams is critical. If you’re going to have self-organizing teams, they have to have trust in one another. That’s one of the characteristics that, for me, distinguishes a group from a team. Group, simply being a bunch of people that I threw together with a common label. And honestly, the only thing they have in common are the T-shirts they printed out that have the name of the group on it. A team is a group that’s gone through the stages. Sort of the top most stages: forming, storming, norming and performing. And if you can make a real investment to turn a group into a team, first, they had to figure out these soft skills issues: how...