All Things Agile - Episode 003 - Use of Overtime
Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban - A podcast by Ronnie Andrews, Jr.
Categories:
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! Normal 0 false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:8.0pt; mso-para-margin-left:0in; line-height:107%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:Calibri; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}