All Things Agile - Episode 004 - A New Hope

Today's episode is centered around some exciting news. I am launching a new venture, Team Xcelerator Inc., which will focus on Agile team software. The AgileInstructor.com blog and the All Things Agile podcast will be moved under the Team Xcelerator umbrella. I am very excited about the possibilities. Please checkout the podcast and send me your thoughts and product feature input using [email protected]m. Also, don't forget to please post a kind review in iTunes. We really appreciate your time and support  :)

All Things Agile - Episode 4 - A New Hope

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 4. Today’s title is ‘A New Hope’. This is paying homage to the classic Star Wars title, 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 an Agile coach, I’m frequently searching for tools to help myself and others utilize Agile methodology successfully. Candidly, I haven’t found many tools which truly reflect the needs that I have seen over the years. Rather than let this frustration remain, I decided to start a new company: Team Xcelerator Inc. to tackle common challenges for Agile teams.

You have undoubtedly heard references to Team Xcelerator a few times already. I want to take a few moments to talk about it in more detail. Everything is still very early stages, but I’m hopeful that many Agile practitioners will come to love it. A goal of mine is to develop a product which reflects the global nature of today’s workforce. Almost all development teams are now spread across the world and this trend is only continuing to rise. The use of Agile itself is also on the rise. However, many organizations are still struggling with learning and how to adapt Agile, including the fact that teams or departments may implement Agile differently.

Many of the products that I’ve seen on the market are really just project management tools. We still have a lot of work remaining, but it is a goal of mine to develop Team Xcelerator into a cloud-based web tool which will enable teams to specifically focus on Agile success. I also intend for Team Xcelerator to be affordable. I want to encourage teams to utilize the tool and achieve success. It will be targeting organizations of all different sizes, including young startups to industry veterans.

I can’t release too many specifics at this time, but I did want to take a moment and let my audience have advance notice of this new platform. I’m also interested in your input to ensure that it better conforms to your needs. 

As the episode title alludes to, it is a new hope for me and for the world of Agile; an opportunity to create a platform for Agile professionals, by Agile professionals. And I hope that you’re excited about this recent product news as I am – and remember: you can check out my blog using the website agileinstructor.com and feel free to contact me using [email protected] and feel free to include product comments that you may have regarding Agile tools. I would love to be able to take in your input and ensure that we have product features that will truly meet the needs of our audience.

Also, don’t forget to visit our previously discussed sponsor: TeamXcelerator.com which makes this podcast possible. And thank you once again for joining me for this quick podcast – join me for Episode 5, we’re having an exciting interview with Mary and Tom Poppendieck who are the innovators of Lean Software. You don’t want to miss it! Remember – it’s time to accelerate your team, today!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!

All Things Agile - Episode 003 - Use of Overtime

In this episode, I discuss the subject of overtime. I provide my recommendations based on solid experience and explain the reasoning behind it. During the episode, I also reference Rework by Jason Fried. Please take a moment to subscribe now in iTunes. Provide your own feedback or recommendations by writing to me using [email protected].

All Things Agile - Episode 003 - Use of Overtime

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 3. Today’s topic will be ‘The Use of Overtime’. 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 blog and this podcast, I like to cover topics that are often overlooked by traditional Agile books or articles. So in this case, I want to focus on the application of overtime within Agile teams. It’s a topic which can certainly illicit strong emotions. There are some that advocate that overtime should never be used. In contrast, many teams engage in overtime occasionally or perhaps even routinely as part of their reality.

I would like to take a moment and share some insights from my hands-on experience which I hope that you will find very helpful. I think there are 3 general viewpoints: the first opinion is that there should never be overtime. That we need to build sustainable teams. The use of overtime violates that principle. The second group often believes that we have to do whatever we have to do in order to deliver the project on time. If that means overtime, then that’s what we have to do. Perhaps you’ve heard that language from one of your project managers before. Lastly, there’s another opinion that lies somewhere between the two spectrums – that the use of overtime is not sinful, but should not become a regular habit.

Through my experience, if there’s a need for overtime, it’s because there are underlying problems that haven’t been addressed. This is an insight that 99% of businesses simply do not get. They don’t see overtime as a warning signal to an existing problem. It’s used to overcome issues with estimation, over commitment, technology, processes, etc. I understand that occasional use of overtime might be justified for events which are not predictable, such as national disasters. However, most uses of overtime are related to things which could have been predicted. Overtime does not fix the core issue which caused the team to get behind in the first place. It’s treating the symptom, not the problem. The biggest source of issues related to overtime is expectations.

Simply put, the team is either over-committed or has impediments which are not properly accounted for. Schedules are defined based on everything working out perfectly. However, most projects have bumps along the way. If teams and ‘leadership’ communicate the situation to stakeholders, the difficulties can often be accounted for by either reducing scope or extend the expected delivery timeframe, etc.

However, that rarely happens in most organizations. Why? Well, because most members of leadership are not truly leaders. It’s brutal, but it’s true. They are individuals focused on their career and their reputation. They don’t want to lose face and admit that their group is behind schedule. They think that it will tarnish their reputation among their peers. That’s the real truth. Most deadlines given to teams are artificial. A project manager somewhere looked at a calendar and picked a date for their release to be delivered. Stop and think about it. Will someone be physically harmed if the release is delivered on a Friday instead of a Monday? No! Will the company go bankrupt? No!

Those PMs and other managers may treat the projects as life or death, but it’s not. They’re just dates! Let’s not make the dates more significant than they truly are. It is often the case that the subject of overtime comes up due to artificial dates that the team didn’t even influence. This environment often breeds routine overtime. So why is that so wrong?

Well, first – regular overtime exhausts team members, leading to burnout. As a result, morale and ultimately, productivity drop dramatically. This in turn, leads to attrition. I can promise you that your best team members will be the first to leave. And, that will devastate the team. A second reason why overtime is a bad idea is margin. If you have someone already working 12 hour days, there’s little or no margin for them to absorb future or further work. If you have someone working 8 hours who needs to temporarily work late, they have the energy and stamina to do so. But, if the team member is already exhausted, they have no additional energy and reserve to handle that issue. There’s simply no margin to absorb further bumps in the road. This adds additional risk to the team and to the project.

Third, the organization is just continuing to treat the symptom and not the underlying problem, which is just foolish and downright stupid. It takes guts. But true leaders must take a step back and ask ‘How did we get in this situation?’ Then, actually solve those issues to prevent future occurrences. Organizations such as Toyota are famous for this principle and enjoy the financial success of their wisdom.

If you’re a business leader, I sincerely hope that you will take this message to heart and implement it in your organization. If you are a Coach or ScrumMaster, please try to convey these points. Perhaps you can refer your leadership and team to this podcast episode. If your ‘leaders’ can’t or won’t change, then you may be forced to adapt. One way is to take action yourself. Do what you can to tackle the underlying issues behind overtime. Retrospective improvement items are a great place to start. If you’re unable to make the changes necessary, perhaps because you’re not empowered or just don’t have the availability, at least you can account for it in your initial estimates.

Now, I will say that I will hate adding excessive padding, but it may be necessary if that’s your reality. I sincerely hope that you’re a part of an innovative organization or starting one yourself, that you can make sure to avoid routine overtime by addressing the ‘Why?’ A great book to underscore this point is Rework by Jason Fried and David Hansson. I highly recommend picking it up on Kindle or Audible. It’s a quick read, but very enlightening. I trust that after reading it, you’ll also come to the conclusion that conventional wisdom is inherently flawed, and there are better ways.

That summarizes a few quick points about the use of overtime. I sincerely hope you found them useful. Remember, you can check out my blog using the website agileinstructor.com. Feel free to contact me using [email protected] and also don’t forget to visit our sponsor: teamxcelerator.com, which makes this podcast possible. It’s a cloud-based Agile team software package, designed for small and large companies alike. Thank you once again for joining me for this podcast, please join me for Episode 4 for an exciting product announcement. You don’t want to miss it! Remember, it’s time to Accelerate your team, today!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!

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 same reasons.

Now, I hope these points have made it abundantly clear that an understaffed team is a bad idea for everyone involved, including the customers receiving the product. Adversely, a team size that is too large can also be a challenge. Simply put, the larger the team, the more coordination is required to provide sanity. In my experience, the effectiveness of a larger team is directly proportional to the savviness of its Scrum master. A talented Scrum master may provide more effective, shall we say ‘glue’ to hold the larger team together.

That said, an extremely large team is still a bad idea. And not one that I endorse. For example, as the size expands, so does the team’s Scrum ceremonies. The daily Scrum meetings or standups become a tiresome chore. It simply takes more time to process so many team members and what they’re working on, which applies to all the team ceremonies. So with very large teams, there’s also a greater risk for destructive conflict. A lack of unity, or cohesiveness. I have seen large teams form factions within the team. That situation breaks down trust and ultimately, destroys productivity.

So why do I recommend a total team count of 10? On average, for Scrum, candidly – it’s a middle ground. It mitigates most of the downsize discussed earlier; there are enough members to reduce risk and prevent burnout. However, there are not so many members that it becomes unwieldy. It’s also a great size for conducting team ceremonies and co-location. It’s very doable to locate the 10 members together, such as a row of cubes or a conference room they can share. In my experience, proximity really does matter. Wise organizations understand this point and make the effort to do so. By keeping people close together, you’ll be amazed at how it improves team communication. And I’ve heard stories in the past about ‘Oh, well we can’t afford to relocate people where they’re sitting because it will cost too much’. That’s simply not true. In fact, it will cost you more money not to, in terms of lost productivity and software quality. It is absolutely worth it to try to co-locate your teams as much as possible.

Now, I won’t say that the team size absolutely has to be 10 members. It’s simply a target to aim for. A rule of thumb, derived from my personal experience, along with the opportunity of watching literally dozens and dozens of other teams in their Agile journey. Selecting a team size at or around 10 will enable the teams to succeed, rather than setting them up for failure. Now, we can’t 100% guarantee success, but we certainly can position the team to win.

That summarizes a few quick points regarding ideal team size. I certainly hope you found them useful. Remember, you can check out my blog using the website agileinstructor.com. Feel free to contact me using [email protected] and also don’t forget to visit our sponsor: teamxcelerator.com, which makes this podcast possible. It’s a cloud-based Agile team software package, designed for small and large companies alike. Thank you once again for joining me for this podcast, please join me for Episode 3 where we’ll discuss the use of overtime, such as scrambling to meet those crazy deadlines. You don’t want to miss it! Remember – it’s time to accelerate your team today!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!

Facebook Profile

I am still getting everything setup, but I took another small step. I created a Facebook page for the blog. You can find it and Like it using:  https://www.facebook.com/AgileInstructor

I hope to see you there  :)

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

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 also including experience at different sizes of companies – that’s how you’re making sure they have experience with a company that’s of your nature.

Next up, I’d like to talk about knowledge. The instructor or coach should definitely be certified. And I’d definitely prefer a strong alliance or similar organization. The effectiveness of an instructor is often based on who taught them. So the source of the coach’s knowledge is critical. The quality of an instructor can make or break a training course, or significantly impact the success of an Agile adoption. I definitely recommend knowledge across implementations such as ‘Scrum’ as well as ‘Kanban’. If you have someone who only knows one way of doing things, that may or may not translate well to your organization or your team, based on your company’s industry. So being able to have someone with background in multiple different Agile implementations, allows them to configure and approach as a better fit for you. Again, that’s also where knowledge and experience combine to help provide a better fit for you.

Let’s also talk about, again the quality of the training that the instructor, the coach themselves received. I definitely like to know that, because we can only impart what we possess. And how the person was trained or taught is going to be a direct reflection on how they will teach. And so, by finding out the quality of the person’s original trainer, that will help you better gauge on how this coaching instructor will work with you or your organization, or your team.

Let’s move on to communication. Communication is of course also very critical and your coach or instructor needs to be a good teacher or a good mentor. The coach should have an open personality and be warm and invite all questions. Soft skills make the instructor more effective. If you have someone who is very unapproachable, then the team members may be intimidated or just not comfortable asking questions. And that can then lead to bitterness and passive-aggressive behavior. I’ve certainly seen it in organizations before, so I definitely recommend someone with that open and warm personality, because then people will feel comfortable asking questions and what that provides you with is buy-in. It’s when people are able to ask their questions, they feel good about it, they have buy-in regarding the adoptions of Agile or maybe you’re already using Agile but you’re bringing in a coach or instructor to help you get to that next level: again, if they’re able to participate, it increases their motivation and the likelihood of success for the adoption or for the further improvement in Agile.

So those are some quick tips regarding selecting a coach or instructor. I certainly help you found them useful. Remember, you can check out my blog using the website: agileinstructor.com. Feel free to contact me using [email protected]. Also, don’t forget to visit our sponsor: teamaccelerator.com which makes this podcast possible. It’s a cloud-based Agile team software package designed for small and large companies alike. Thank you once again for joining me for this podcast. Please join me for Episode 2 where we’ll discuss ‘Ideal Scrum Team Sizes’ – it’s a popular topic. People always ask what’s too small, what’s too large – so we’ll definitely address that and you don’t want to miss it. Remember – it’s time to accelerate your team, today!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast in iTunes and leaving a kind review. Thanks and God bless!