By Brian Lucas
This one is for Denise. See I told you so!
“The time to relax is when you don’t have time for it.”
Don’t be misled! Agile methods are mainstream! Forrester Research reported in 2010 that “Agile methods rapidly joined the mainstream of development approaches.” Productivity increases are the number one reason organizations adopt agile. For example, a 2012 study reports 91% of respondents cite increased productivity as the reason for adopting agile. In this study, 69.21% report their productivity significantly improved or improved. Another study conducted by QSM Associates on over 8,000 projects confirms agile software productivity is at least 25% higher than traditional methods.
However, even agile successes are not without problems. I had a very interesting conversation about two months ago with a friend who works for a west coast company about the stress developers are under during an agile iteration. She is a CSM and an experienced and effective scrum master. Her company has been working with scrum for over 5 years and quite successfully. Productivity was up over 45%.
The problem they were having was developers were burning out. At times they took too much work into the pipeline. The most interesting aspect of this was the developers were the source of their own burnout! Motivation was very high and the developers were driving themselves too hard. They were working 60+ hour weeks. Management was forcing a reduction in the amount of story points an iteration was allowed to consume and sponsoring reward trips and outings. Unfortunately, this was not having as much of an effect during the iteration planning and execution as expected. Developers were exceeding the level of function as specified in the user story. So far quality had not suffered, but it was only a matter of time before things would begin to break down.
I know many of you in management are saying to yourselves, you wish you had that problem. However, sustainability is a very important factor in maintaining a stable and productive workforce. Most progressive and profitable companies recognize this. For example, Google’s policy is if an employee has to work more than 40 hours a week, management is doing something wrong.
My friend asked me if I had a suggestion, and in order to live up to my reputation of being agile, I came up with one on the fly. I suggested that she implement a variation on the “gong” technique which is used for team members that wax verbosely during daily standups. I called it an “Agile Timeout”.
The implementation is simple. Everyone on the team gets a set of cards that have the word “Timeout” printed on them along with spaces for a name, date and time. The timeout period is one hour. Anyone on the team can give fill out a timeout card for anyone else at any time. The rule is that the person receiving the timeout cannot touch any computing device for the hour or converse on any project related matter. A team member can only receive one timeout a day.
What gave me the idea for this was the need to address some aberrant behavior in a three year old, I am acquainted with that was very spoiled and has tantrum issues. The beauty of a time out is that the child can resume their normal activities when they settle down. This puts them in control of the situation and actually helps them master their emotions. Similarly, I reasoned that giving the team a mechanism to police their own over zealousness would be successful.
My friend was mortified at my suggestion and said I would be responsible for getting her fired. My response was it was up to her, but I had confidence that it would work. Two months later, I received a very expensive thank you card in the mail along with an incredible box of See’s Candy.
It seemed that timeouts were a huge success. They made a big hit with everyone and the company was even considering implementing the concept outside of the IT organization. Team members were handing each other timeout cars during planning sessions when they thought someone was taking on too much work. Timeout cards were also used during the sprints when someone was pushing themselves too hard. The timeouts helped the team members bond even closer together and even drew the workforce closer to management as development team members were able to give stakeholders like the project sponsor or product owner timeout cards. Only one person, abused the timeout cards once and this was quickly dealt with.
The moral of this story is twofold. First, the most important aspect of successful agile is adapting to new challenges with novel and simple solutions. The second is that more management is not the solution, but more empowerment of the team. Remember that empowerment does not mean the absence of guidance. Remember till next time Keep Agile!
 See Melo C.O. et al
Brian I hate it when you are right! And you always are RIGHT! But I can’t be mad since you dedicated this to me. 🙂 Thanks for being a great source of information, support and inspiration! Glad you enjoyed the candy! I still owe you! 🙂 – D
This is a great tip, Mr. Lucas! It is very simple and appears to actually work according to Denise. We have experienced this issue of our SD teams taking on too much work. Our solution of limiting the teams by second guessing them, has led to arguments and conflicts in our planning sessions. The post sprint reviews were regressing to finger pointing. What exacerbated the problem was the product manager encouraging the development to “add the little extra” to the sprint. It sounds like a basic failure to follow the agile principle of no changes during an iteration, but the issues was introducing itself during planning. My intervention was seen as interference and resented by the development team and the product owner. I am going to offer up this suggestion to our team. I will let you know how we fare. Thanks for the idea!
Hi Brian! I have to apologize! It has been far too long a time since I commented on your blog which has helped me so much! Things are definitely moving faster now that we have embraced agile. That is very much a good thing for all of us here. I have not noticed exactly the problem that Denise reported, but I have a similar one in that we have a tendency to underestimate our story points. Do you have any helpful suggestions on how to combat this problem? Thank you so much for being a continued voice of reason and clarity and a tremendous oracle of knowledge and ideas!
Good one Brian! You ARE a genius!! 🙂
Brian, I would be interested in your response to Jack as well. Underestimating story points and underestimating is a chronic problem for us. We have tried many things like simply doubling estimates, which makes the schedules more accurate. None fix the underlying problem and we feel this is holding us back. Any help would be deeply appreciated.
Super idea Brian! I am going to implement this right away! Just as an idea, I think I am going to create a little tracking system for it to record who gives what to whom and when. I am also going to track the KPIs we use for projects and see what improvement happens.
Hey Brian! Do you ever take a timeout? 🙂