Internal Customer Service and What I'm Doing to Be Agile | Tim Barcz
I’ve been spending a lot of time in the last six months retreading myself in Agile as we are rolling out Agile to several organizations. During this process, we’ve talked with our internal developers a lot about the Agile Manifesto and the Principles Behind the Manifesto. As we share these principle with our team, I’m finding it very healthy for myself to go back to these basics which are so easily forgotten or inadvertently pushed aside.
As a refresher The Agile Manifesto reads:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
And, what I believe to be the most important principle from the 12 principles behind the manifesto:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
In looking back in my nearly ~10 years of “being Agile” I’m ashamed to admit that I’ve never really sought out the customer to find out how I, or my team, was doing. I’ve likely asked casually how things are going in an ad hoc fashion, but I’ve never taken deliberate and disciplined steps to checking in with my customers.
In our current Agile adoption we changed that, and my encouragement is that you to consider doing the same if you’ve lost sight of your customer. We built a simple survey (takes only 90 seconds to fill it out) to inquire how we’re doing. We initially circulated the questionnaire on a monthly basis and then backed off to quarterly which gives us a regular cadence on getting empirical feedback.
Here are the questions we ask to ~20 key stakeholders of our development process and software:
Q1. How eager were the representatives of our department to help?
Q2. When discussing project requirements, how satisfied are you with the interaction with the team?
Q3. How satisfied are you with the communication of project status during the entire process?
Q4. Would you say that our team solved your problem or answered your question quickly, slowly, or neither?
Q5. How well did the output from the team meet your business objectives/needs?
Q6. How knowledgeable did our team representative(s) seem to you?
Q7. How clear was the information that our representative provided to you?
Q8. Overall, are you satisfied with the service you received, dissatisfied with our service, or neither satisfied nor dissatisfied?
Open Ended Questions
Q9 (Optional): What’s the most recent example of how we have exceeded your expectations on this project?
Q10 (Optional): Is there a recent example where we have not met your expectations?
Q11 (Optional): What is one thing none of devs do but wish we would?
Q12 (Optional): Additional comments?
When I push these surveys out I anxiously await the results to see how we’re doing.I review each one personally. I’ll be frank, it has been a mixed bag of emotions. Sometimes (read:often) what I read isn’t easy to read; while we have drastically improved internal customer service, our stakeholders ask for more (and rightly so).
In the past, I may have been too quick to use the Agile manifesto and underlying principles selfishly for my own gain when it suits me and when it plays to my advantage in furthering my cause. As of late, I’m challenging myself and the team to continue to refer to the manifesto and it’s underlying state-of-mind/ethos, especially as it relates to the human side of development (customer satisfaction, changing requirements, working together, and communication).
As you head into the week, consider your own situation, might you be able to adhere to the Agile principles just a bit better? The survey is what is working for us and it may or may not work for you. If you desire, please feel free to copy and use the questions we’ve used (we picked them very carefully).
I’m curious…what do you think? How could/should we be more “Agile”. Please post your thoughts, suggestions, and results of your own survey’s in the comments below.