• Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban

  • By: Ronnie Andrews Jr.
  • Podcast
Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban By cover art

Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban

By: Ronnie Andrews Jr.
Listen for free

  • Summary

  • Dedicated to Agile methodologies such as Scrum and Kanban. Home also to the All Things Agile podcast available on iTunes. Part of Team Xcelerator Inc.
    Copyright AgileInstructor.com 2014
    Show more Show less
Episodes
  • All Things Agile - Episode 011 - Ken Rubin Interview

    All Things Agile - Episode 011 - Ken Rubin Interview
    Jan 10 2015
    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...
    Show more Show less
    Less than 1 minute
  • All Things Agile - Episode 010 - Resolving Team Conflict

    All Things Agile - Episode 010 - Resolving Team Conflict
    Nov 25 2014
    Welcome to another episode of All Things Agile. In this episode, we discuss the tough subject of team conflict. Whether your Agile or not, every organization is bound to encounter team conflict. We'll discuss how to resolve existing conflict as well as preventing it from even occurring. I am also very excited to announce that the next episode will feature an interview with notable Agile author, Ken Rubin.  Ken is the great mind behind Essential Scrum. I hope you enjoy this episode and make sure you subscribe to catch the upcoming interview using this link: iTunes. Reviews on iTunes are also always appreciated. 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 010 - Resolving Team Conflict 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 on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr. Hello everyone and welcome to the All Things Agile Podcast! First off, I want to get started by issuing an apology for the delay in getting a new episode out. The reason why is because I have an upcoming guest and unfortunately, we are not able to get the scheduling worked out in time for this episode. But, I am pleased to announce that Ken Ruben, author of Essential Scrum, will be the honored guest in our next episode. That said, I want to go ahead and issue another episode. I don’t want to keep you waiting too long – and with that, I hope you accept my apologies for the delay in getting this episode out to you. Now, before we begin, a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So the topic for today will be ‘Resolving Team Conflict’. Virtually any team you will be working on is going to have some degree of conflict. It’s just part of human nature. You can’t all agree 100% of the time, even though Agile encourages more of a democratic approach to what the team is working on and the approaches that they use, there’s bound to be some degree of conflict on any team that you work on. Now, before we dive into solutions to resolving team conflict, let’s first identify the different types of conflict. One type I think is just general healthy conflict and what really we’re referring to is debate. Using the word ‘conflict’ is probably inappropriate in this particular case. An example of debate, you may have people that share different ideas and solutions and what type of technologies should be used, or different coding practices, whatever. That’s fine. Having those healthy debates, discussing ideas, is actually a good thing. In this case, it allows you to have differing points of opinion which can be discussed, evaluated and reach an ultimate decision on. And that’s fine. That’s a healthy form of debate or conflict, if you will. And, if you have a little bit of that on your team, that’s fine and I wouldn’t worry about it. What we’re really going to be focusing on in this particular episode, is unhealthy debate. And I would describe unhealthy conflict or debate as a case where it’s really impacting the team. Where it’s creating what I like to call a toxic environment. You can definitely tell it when you’re part of a team that’s having this because it just brings everybody down. It brings the morale down, and it just feels like the team has been poisoned, if you will. And you’re going to see evidence of that not only in the morale, but the conversation, the level of communication and collaboration are going to go down. You are going to see people that are going to be engaging in using a lot of inappropriate language. You’re going to have a lot of people getting into some sort of personal battles with each other or one-upmanship, and it just really destroys the overall team morale and ultimately, the productivity. And you’ll actually begin to see this long-term in the metrics where you’ll start to see a team that was doing really well, and then they start to perhaps have their velocity dip down and more and more of their stories are being accepted late, etc. So that definitely has an impact. I would definitely classify unhealthy conflict as conflict which is really bringing down the team. It may be disrespectful, and it’s simply just not in the long-term viability of the team. So that’s kind of how I would probably classify the two main types of conflict that I see, either healthy, just discussion of topics and technologies versus some things more personal and toxic. And so we’re going to talk about the latter and how do you resolve it? Now, I have personally seen these cases come up numerous times in my career, and if you are particularly in a situation – your team or teams that you’re coaching ...
    Show more Show less
    Less than 1 minute
  • All Things Agile - Episode 009 - Scrum of Scrums

    All Things Agile - Episode 009 - Scrum of Scrums
    Oct 18 2014
    Welcome to another great episode of All Things Agile. This blog and podcast is dedicated not only to interviews with Agile leaders but also to actionable and practical advice. In this episode, we tackle Scrum of Scrums. Well cover what it is, mechanics, benefits, and things to watch out for. If you have multiple Agile teams, this is an episode you must checkout. As always, please take a moment to subscribe using this link: iTunes. Reviews on iTunes are also always appreciated. 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 009 - Scrum of Scrums 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 on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr. Ronnie: Hello everyone and welcome to the All Things Agile Podcast. Today’s topic will be: Scrum of Scrums. What are they and how do you implement them successfully? But before we begin – a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So let’s get started. As part of the AgileInstructor.com blog and this podcast, All Things Agile, I like to alternate between interviews and informational content. I think it’s important to help listeners with direct, actionable advice based on hands-on experience. Interviews are great and I certainly look forward to conducting more interviews, including in the next episode – however, I definitely want to include direct content. Things that I’ve learned from my experience that I hope can help you. One of those topics that is often overlooked is Scrum of Scrums. Now, many people have heard of this, but are not really quite sure how to pull it off or perhaps they’re kind of winging it right now and perhaps haven’t seen what has worked at other organizations and are maybe looking for some additional advice. So I’d like to focus today on, again, Scrum of Scrums. So in this case, let’s start with ‘What is it?’ For those who haven’t heard that term – Scrum of Scrums – basically, when you have the individual Scrum teams, maybe in a smaller company or at a team that’s focused on a product –that team might work well and be able to take care of all the needs and that’s great. However, you may have cases when one team is just not enough to fulfill the needs of a product. Or perhaps there are multiple products being worked on and perhaps each team is working on one particular product or component, but those teams then have dependencies on each other. So just to recap: you may have cases where you have to have multiple teams working in order to get the job done on a particular product because there’s just so much work to do; or perhaps you still have multiple teams, not because multiple teams are required for a particular product or component, but just because maybe there is a dependency between the teams. You may have a product A and a product B, and you may have a case where the products are supposed to act like a suite. For example, a lot of Apple and Microsoft products are designed to work together with each other. And so, in that case, even though the teams may be working on separate products, they still may have dependencies on each other in which case there are pieces of the puzzle that still need to align with each other. With any of our project managers in the listening audience, they’ll immediately start to think ‘Well, you got to keep these teams in sync’ because if the teams are working on the same product or multiple products with dependencies, then there’s definitely the risk that the teams can end up stepping on each other. And, you run into other issues where you need to be able to release code at the same time together, right? Because if you have, say 3 teams working on the same product, that product is going to get released at one time or is going to get delivered to production. And you can’t have those teams so disconnected that they’re causing havoc for each other and making it difficult to release the product at one time. And then you also have quality concerns. You have multiple teams working on products together in parallel – there’s always a risk that one team can make a change for something and then inadvertently break another team and introduce unaccounted for defects. And naturally speaking, that’s not a good thing. So, how to overcome it? Well, there are many different practices and I’m not going to say there’s any particular right and wrong answer for this, but one of the more commonly applied principles, or practices I should say, is the Scrum of Scrums. So there’s a need for it when you have multiple teams and you have to keep them in sync, help them ensure they’re not stepping on ...
    Show more Show less
    Less than 1 minute
Economics
Show more Show less

What listeners say about Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban

Average customer ratings

Reviews - Please select the tabs below to change the source of reviews.

Audible.com reviews

Amazon reviews
No Reviews are Available