Jan 11, 2021
Lessons From the Field
Part 4: Setting Expectations
Written by Craig Vosper, Chief Delivery Officer
Today’s lesson learned revolves around setting expectations. One of the points I drive home with our teams is that they must set expectations and then meet them. We all look to people who we can depend on and who are reliable in doing what they say they will. I would even venture to say that reliability is the most important characteristic a team can have!
We were three days into a sprint and one of our developers had signed up for what he believed was a 6-hour task during sprint planning. He had reported needing more time after 2 days of work and finally, on day 3, reported it would be done that day. After one of our daily meetings, I went to him and asked what was going on. The task had taken him nearly three times the initial estimate.
In our discussion, I found out that he had identified and resolved multiple issues in the page he was working on in addition to the original task. I asked if he had discussed these issues with the Product Owner or at least documented what he had found and fixed. He was a bit taken aback by my questions and replied, “did you not want me to fix the issues I found?”. I simply answered “no”.
I explained to him that we were two days over our original commitment, and we did not have any way to explain to the customer how their money was spent for those two days. All we had was “we fixed some pretty good stuff, I’m sure you’ll love it”. Most of us have had the car or house repair in which we get the bill at the end of the service only to find a bunch of additional things tacked on that they felt needed to be fixed. This is not a good situation.
Of course, we want our developers looking to improve quality in any code they are working on, but we need transparency about the issues and what they mean to the customer before we act on them. All changes cost time and therefore money; we must ensure customers are willing to pay for those changes regardless of their origin.
This lesson drove home the need to understand where a project is every single day and how scope changes can quickly spin a project out of control, even if all the changes have the noblest of intent!