Today, we received a client request to improve a page’s load time while in the midst of making major aesthetic improvements to another site. When I suggested we switch gears to help the client, I was met with resistance in the form of frustration that the new project was being interrupted.
This gave us opportunity to have a long overdue discussion that probably would not have taken place if we hadn’t had recent staff changes to our programming team.  The crux of our talk:  our recent past will not dictate our future.
For the last year, we have followed agile development practices that offered remarkable improvements to how we scheduled and executed work.  Though the scrum master’s philosphies dramatically differed from my own, I allowed a fundamental shift in how we operated our business. The biggest change lay in our responsiveness to client requests for bug fixes and improvements which were increasingly pushed to the back burner so as not to disrupt weekly sprints or programmers who were “in the flow”.
At some point, I began to realize that the way we practiced agile centered on how we could keep the development team happy.  But they weren’t happy. And neither were the project managers. Worse, our clients were not getting the attention to which they were accustomed and deserved.
Despite my knowledge that our practices were not benefitting our business or clients, in lettng the programming team to dictate our business process, I was essentially allowing the tail to wag the dog. It was during one sprint meeting when I asked a question that I got my wake-up call. Why, I asked, are we focused on how we could improve the programmers’ jobs, but no one is interested in how to improve our jobs as the primary contacts to the customer?
The answer was telling: Â “We don’t even know what you do.”
So this morning, we talked about change to our collective mindset. I explained that I meet with a group of professional women every six weeks. Virtually all of them have fallen victim to the recent economic climate. Separately, two of the women indicated that we must be doing something right: in their minds, we seemed to stand apart as a business that is profitable and growing despite the downturn.
I told the staff that our success didn’t happen by chance. Before this past year, we’d put our clients first.  Today, I stood firm: from here on out, we stand second to our clients. If they are our priority, we cannot help but succeed.  The cool thing is, they will, too.
Interesting blog post. Here are some comments (btw, it’s too bad you have to be logged in to leave comments on the blog. You might get some interesting interaction with clients or potential clients or (more likely) potential future TDS employees if it were otherwise :-)
Why wasn’t anyone happy?
Do you think this falls out of agile practices in general or just the way that TDS was doing agile?
Hmm. What do you mean here? Are you saying that agile practices don’t put the clients first?
If the dev team was already doing work for client A when you asked them to switch gears to help client B, are they still not putting the clients first? In this case, they would be putting client A’s needs over client B’s needs because they’ve already invested some time in satisfying client A’s needs and an interruption would damage their productivity for client A.
But it’s really a question of priorities at that point. And developers don’t set the priorities, the project manager does. So, if you determine that client B’s immediate needs are more important than client A’s maybe not-so-immediate needs, then just tell them that. That’s your job. :-)
Pingback: Thunder Data Business Ideas Blog, Software Programming, Web Design, » Can Management Understand Employee Needs?