All Things Agile - Episode 001 - Selecting a Good Agile Coach

04/24/13 • -1 min

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

In this episode, I will start the podcast discussion by providing tips to help you select a good Agile instructor or coach for your organization. It's a tough decision facing all organizations when the begin their journey with Agile. I have also added a transcript of the episode below for your convenience. If you have suggestions for future topics, please send an email to [email protected]. Also, please take a moment to subscribe to this podcast in iTunes using the icon provided on the right.
All Things Agile - Episode 001 - Selecting a Good Agile Coach

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. Hello everyone and welcome to the All Things Agile podcast, episode one. Today’s topic will be ‘How do you select a good Agile instructor or coach?’ 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 – large and even small companies may want to hire a coach or instructor to help them start their Agile journey. In my opinion, key aspects to look for are: experience, knowledge and communication skills. So let’s start with experience. You really need to take a good look at someone’s background. It’s more than just the number of years. I recommend instructors with experience at different companies and different types of teams. That provides a more varied and useful background which can provide additional insight and experience. Let me elaborate. Say you have someone who has been at one company for say, 5 years, and that’s the only company that they worked at regarding Agile. In that case, that person realistically probably just knows how that company does things, okay? Therefore, their experience is a lot more limited. And now compare that with a coach or instructor who’s been at literally dozens of companies. They’ve seen all kinds of things work and not work – and also across different industries; that provides them with additional insight that they can leverage at your organization. Please keep that in mind. Moving on. Experience in larger companies requires scaling. A company with billions in revenue and thousands of employees is a totally different ball game than a start-up. An instructor with only experience in teaching Agile in a young company may have difficulty with a corporate giant. Quite frankly, the larger the company is, the more any mistakes or errors or ineffectiveness in their processes or their practices – it only becomes magnified as the company rose and is larger and larger. So if you had a smaller company, let’s say 10 people, and the practices you’re putting in place don’t work out as well, it’s probably more recoverable. You know, maybe they lose a couple hundred dollars or thousands of dollars – maybe. But at a larger company, if there’s things that go awry, it can cost the company billions. And instead of a few people perhaps – if things really went south – they may lose a few people a few jobs; at a larger corporation, if things really go awry, thousands of people could potentially lose their jobs. That’s a huge responsibility! And so, when you’re working at a larger company, it has more integration points and many, many more people and larger scale teams – you really have to be at the top of your game. And also, in terms of working with those larger companies, in order to get things done, you really have to automate. You have to automate as much as you can – things like minute gathering and metrics, etc. It forces you to really take a good look at what you’re spending your time in, time on, and be able to automate that as much as possible. However, those same principles that apply at trying to streamline larger organizations also apply to smaller companies as well. Being able to leverage some of those automation principles, even at a smaller company, can certainly produce huge benefits. But let’s move on. If you have a coach or instructor who is perhaps familiar with younger companies, they can provide additional insight regarding how to achieve Agile with fewer resources. Because if you’re in a company who doesn’t have a bigger budget, they may not be able to spend as much funds on training and other types of programs. So when you’re looking to bringing in a coach or instructor, see if you can find someone who again has experience at different companies, different types of teams and al...

Transcript:

Next Episode

All Things Agile - Episode 002 - Ideal Team Size

In this episode, I discuss the ideal size for an Agile/Scrum team. It is a frequent question when organizations first begin adopting Agile. I will provide my recommendation based on solid experience and explain the reasoning behind it. I have also added a transcript of the episode below for your convenience. If you have suggestions for future topics, please send an email to [email protected]. Also, please take a moment to subscribe to this podcast in iTunes using the podcast icon provided on the right.
All Things Agile - Episode 002 - Ideal Team Size
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. Hello everyone and welcome to the All Things Agile Podcast Episode 2 Remix. Today’s topic will be ‘Ideal Agile Team Sizes’. But before we begin, quick reminder that this podcast is for informational purposes only and accepts no legal liability. So let’s get started. For the context of this episode, I’ll focus on Scrum, since it’s a very popular form of Agile. We’ll cover other implementations, such as Kanban in separate episodes. That being said, Ideal Team Size is a popular subject and many newcomers ask about team sizes when they’re first learning Agile. Corporate leaders also struggle with the topic when they try to roll out Agile and form team in their organization. People are curious how big is too big? Or how small is too small? What are the implications? I’ve often been asked what team sizes do I personally recommend? For Scrum, the longstanding recommendation is 7 team members – plus or minus 2; so that’s 5-9 members. However, the product owner and Scrum Master boost the total count to 9-11. Now, some coaches may or may not include the product owner and Scrum Master when factoring in the team sizes. But I certainly do. So what specific size do I recommend? Well, based on a hands-on experience across numerous teams, I believe that 10 is a great number to be at. That is 8 team members, plus the Scrum Master and the product owner for a total team count of 10. That is a number that’s in-between the recommendation and one that I have found to be a sweet spot for Scrum teams at many different organizations. If your team, however is too small, it can certainly cause problems. The reason is that people are wearing too many hats. For example, I do not recommend that Scrum Masters and product owners double up on roles. So for example if you have a product owner or Scrum Master who’s also a critical path contributor on a story, it can be a disaster. So an example would be the Scrum Master working on a story and that story gets in deep trouble and they need to dig deep into it, and then what do they do? So an example would be the Scrum Master working on a story and that story gets in deep trouble and they need to dig deep into it, and then what do they do? Maybe let go of some of their other Scrum Master duties? And then the entire team suffers and other stories suffer. People need to be able to concentrate on their given role. It’s been my personal experience that if you allow the product owner and Scrum Master to focus on those roles which they should, they’ll be good at them and the entire team benefits because those roles act as multipliers. Now, I especially don’t recommend that the same person serve as both the Scrum master and the product owner. It’s a conflict of interest and I have rarely seen it work out well. Most of the time, it’s also a disaster. It is a constant temptation by business leaders, foolishly trying to cut corners by understaffing the teams. When the team is too small, people may not be able to focus on their core gifts. They also get burned out quickly. Please remember that one of the principles of Scrum is to build a sustainable, well-functioning team. If you undercut your team, don’t be surprised if you end up with attrition. And I can promise you this: the most talented people will be the first to go, because they have options and they will exercise them. Now, there’s also yet another great reason why you should not shortchange your team size and that’s risk. If you have a small team, it increases your risk profile. If a single team member departs, goes on vacation, has a flat tire, whatever – the team can be in deep trouble. There’s no margin for the team to absorb bumps in the road. If a team is too small, it’s also more likely to have ‘siloed’ knowledge which is an additional risk for the sa...