Enterprise Agile Adoption
Join peers from the Agile Community in discussions about what makes uptake of Agile successful within the Enterprise.
Post
During a recent course on Agile Fundamentals for Leaders and Stakeholders I was asked – paraphrasing – ‘Isn’t it counterproductive for someone to interrupt me when I’m heads down coding? I mean, if a tester walks over to ask me a question and I’m working on something complex won’t it effect my results?’
What is the recovery time of an interruption? I’ve read anywhere from 5 – 25 minutes. It depends on how complex the item is that you are working on. Is the recovery time of the interruption going to be more than the 5 or so minutes it may take to answer a question? If the interruption is more than just a quick question, then there should be a session scheduled.
My answer to the question was that it is Ok to say “Not now please.” As long as its not delaying someone else and potentially causing a backup.
Saying “Not now please” should be the exception, not the rule. The beauty of agile is in the collaboration and the near immediate response we get to keep production flowing smoothly. If the team/someone is regularly saying “Not now please”, that is a smell. Something is not right and needs to be investigated.
As a Business Analyst, Tester, IM and PM (never been a developer) I know how frustrating it is to keep getting interrupted. But once you realize that you are likely learning from the interruption as well and that it does ultimately benefit the team as a whole to give/get that immediate answer, you learn to work with the interruptions.
As a Leader, actions speak louder than words. Be available for your team. Take the time to answer questions, listen or otherwise accept interruptions to keep production flowing.
Comment
Patti, thanks for bringing up the distraction factor. Let me offer a different view.
In my last assignment I led a couple of teams using SrumForTeamsystem. We followed the process guidance religiously. We had the teams located in open bays with full line of sight to each member. We thought we saluted and followed the spirit of agile pretty closely. We were productive - much more so than before we switched to an agile format - and much more predictable in release punctuality. But, then we stopped improving after about a year and plateaued. I wondered why.
Last January, I got everyone (20 people or so) into a room for lunch and a rap session. I planned on an hour and we went two and a half. I wanted to know "How is it working? Are you happy with how we do things? Are you happy with our pace? What can we do better?" Far and away the biggest complaint was the interruption factor. Time and again people complained that the open office format was too distracting during coding and construction when distractions are particularly harmful to productivity and quality.
The emphasis there is important. I believe there are times when communal living is hurtful to forward progress in software development and actually harmful. Yes indeed, private offices are a good thing when it's time to get "in the zone" and code. Elaboration is done. Design is done. Implementation approaches have been hashed and rehashed. Now it's time to lay bricks. Coding is generally not a community project.
What's that sound? I think I can hear the "agile community" writ large howling from the rooftops. The XP people are seething. Nevertheless, I'm convinced controlling the distraction factor is something we in the agile community need to recognize as a real problem. Sometimes interruptions are best left until later.
How do we deal with it? My team had a couple of ideas. One was that people simply hang a "Do Not Disturb" sign for all to see. By the time you say "not now please" it's too late. You've been interrupted. Another was to separate a "quiet area" in the office just for uninterrupted work. Working from home is also a good isolation tool for the right people at the right time.
A high level conclusion I drew from this feedback was to remember that the team needs to feel comfortable. If half of them are fighting the environment then it's something to fix. One of my roles as a leader is to tear down the obstacles inhibiting my team. I'm completely comfortable doing things outside the lines of "the book" if the team wants it that way and produces more that way.