The Agile Development Methodology is a fairly well known, proven method for taking a large deliverable and breaking it down into smaller pieces (Sprints). Then, using an iterative, incremental approach, each Sprint is completed in a relatively short period of time. This allows the goal to be reached in tiny, flexible, responsive steps instead of one long, protracted assembly-line effort that typically takes longer and doesn’t allow for changes in requirements along the way.
That is an embarrassing oversimplification, but it lays the groundwork for a situation I found myself in recently. Our teams use Agile when managing large development projects and our SharePoint teams use a modified agile approach in their SharePoint Center of Excellence Methodology.
In this case, I needed to interact with a particularly challenging customer. I’ll call her “Gina” – not her real name. None of my previous encounters with Gina resulted in a satisfactory result. Miscommunications, misunderstandings, and misaligned expectations made encounters with her very stressful and always left me wishing I could find a way to successfully meet her requirements without things spiraling out of control.
I’m fairly skilled when it comes to communication. I listen, I’m patient, I pay attention, I ask questions, and I try to make sure I understand the goal as well as the reasoning behind it. But Gina somehow manages to push my buttons. None of those things seem to work on my previous interactions with this customer.
Gina’s “requests” usually follow a pattern. She stomps into my office (yes, she actually stomps) and comes to an abrupt halt at my desk. With a stern frown, she demands that I deliver a specific result to her, immediately. Usually, she does this about 3 minutes after having sent me an email with the exact same requirement spelled out in conflicting detail.
I realized what I really needed was a new communication tool. I decided to create my own, which I call “Agile Email.”
I was actually reading Gina’s email when she made her customary appearance at my desk. After she announced that she had just sent me an email, but before she could begin making any demands, I immediately thanked her, informed her that I was reviewing that email right now, and that I would respond as soon as I had a chance to finish looking it over.
It took more than that to get her to go away and give me time to read her email, but once she left I decided it was time to change the way I handle her requests.
My approach was very simple, and surprisingly effective.
I began by assigning a number to each and every request, demand, or requirement that she listed in her email. She actually had started doing this herself, but was inconsistent in breaking out each item, some items didn’t have any numbers, and some of the numbers were out of order. I corrected those things and began my reply.
This is where the simple magic came in. All I did, over and over, for the next few days while we each hit Reply and Send, was to only provide status updates on the numbered items. No other comments. No additional information.
I always copied the numbered items to the top of my reply then responded directly to those things.
I gave her status, I asked questions, I provided clarification. But most importantly, once I indicated that I had completed a numbered item I asked her to confirm. Once she confirmed I NEVER referred to that item again for the remainder of our email conversation. NEVER.
All subsequent replies that I made only referenced the remaining (open) items on the list. I continued to give her status, ask questions and provide clarification, but only on the tasks that I had not yet completed.
This had a very interesting series of effects.
- I was able to focus on just what needed to be done
- My questions would often uncover a need to adjust the requirement and the deliverable
- She was getting what she asked for and was agreeing (in writing!) that I had given it to her
- The list kept getting smaller
At one point she latched on to two items that could not be resolved. Both were due to scope creep. One due to her misunderstanding, the other due to her wanting more than I could give.
Due to the extraordinary detail in our email thread I was very easily able to route her remaining concerns to my manager. He promptly informed her that we had fulfilled (and actually surpassed) her original request, and that her supervisor was welcome to contact him directly regarding any additional concerns.
I realize this approach isn’t really all that amazing. It’s not even a complete Agile method. But it sure was effective!
- Break down the request into small, Sprint-sized bites
- Focus on just what needs to be done
- Provide frequent status updates
- Keep asking questions
- Adjust your approach to meet any changes that come up
- Get confirmation when you’ve completed something
- Let completed items “fall off” the list
- Bring the open items to the top and keep working on them
- Don’t let scope creep prevent you from fulfilling the original request
- Let upper management cover your back
If you would like more information, please contact us.
Author: Jeff Hepner
Editor: Alex Finkel and Kurt Greening