Yesterday, at the end of the working day, our product owner approached our team area, at a point where I was the only one at the office. He goes to explain a piece of feedback from a user, and we pair to understand the feedback as an example with the product.
We think back to what we had agreed on the feature, and together we learn that while it works as specified it does not work as we intend the customer experience to be. The missing feature is kind of relevant, even blocking. And for us, with that joint learning, the feature request becomes a bug.
We don't really care about the label, we just care about the customer. And we need a change.
Appropriately, the morning after there's a regular meeting for us, the team and the product manager, to improve the world as we know it. The previous evening, I had already alerted my team on this, and we had just the right people around the table in solving it. The developer brings in the deep understanding of current implementation and we learn this will not be a minor change. However, the developer states "I can have it done by tomorrow".
I smile with the idea that he forgot to ask if I'm available for testing it with this schedule, especially knowing it will be an evening thing even if we can do bits and pieces throughout the day. The final experience, the product that speaks to me, will not be fully available before the changes have been done. But I'm not the gatekeeper here. I know that there are days after tomorrow, but I don't mind him taking a stretch goal. I know our product owner well enough to know he has flexibility when we talk about days, not this month's release vs. next month's release.
After the meeting, the dev messages me, unprompted. He tells me he realized that he might have been optimistic on schedule because we had pre-agreed collaboration with another department and a weekly meeting to interrupt the day. And that he's sorry for not thinking about my schedule. We agree not to worry about estimates (we are very much in the #NoEstimates idea) but focus on what helps us forward, without haste. Thinking over deadline.
Throughout the day, the developer mentions things he's changing, kind of as a checklist for me to see what to cover. But for me, that is a checklist of things he already covers. I give him as much ideas as I have, help him work through the minimum scope and risks.
Late in the afternoon, I know that it will be a long night before it's done. Working on it has revealed a bunch of dependencies and connections. Instead of telling the product manager that the developer was overly optimistic, I mention that I will not be available for quite as late as this would require. And it's better for the two of us to take a look at it without rush. No disagreement, work continues.
4:23 pm the developer mentions he just checked in the code in a branch he worked from and asks for help. I test, and I find 7 issues, out of which 3 have been introduced with the change. He fixes all but two. One is related to a complicated set of rules and we agree to take more time on pairing on that. The other is an inconsistency that has been there before, that I just hadn't paid attention to before. I know that addressing the one left behind is only a matter of days anyway, and we agree it can wait now to keep our eyes on the customer need.
There's a lot we could improve here. But there's a lot of good here too. And it's just a day in the life of this project. And my hat tip to having great developer colleagues.
We think back to what we had agreed on the feature, and together we learn that while it works as specified it does not work as we intend the customer experience to be. The missing feature is kind of relevant, even blocking. And for us, with that joint learning, the feature request becomes a bug.
We don't really care about the label, we just care about the customer. And we need a change.
Appropriately, the morning after there's a regular meeting for us, the team and the product manager, to improve the world as we know it. The previous evening, I had already alerted my team on this, and we had just the right people around the table in solving it. The developer brings in the deep understanding of current implementation and we learn this will not be a minor change. However, the developer states "I can have it done by tomorrow".
I smile with the idea that he forgot to ask if I'm available for testing it with this schedule, especially knowing it will be an evening thing even if we can do bits and pieces throughout the day. The final experience, the product that speaks to me, will not be fully available before the changes have been done. But I'm not the gatekeeper here. I know that there are days after tomorrow, but I don't mind him taking a stretch goal. I know our product owner well enough to know he has flexibility when we talk about days, not this month's release vs. next month's release.
After the meeting, the dev messages me, unprompted. He tells me he realized that he might have been optimistic on schedule because we had pre-agreed collaboration with another department and a weekly meeting to interrupt the day. And that he's sorry for not thinking about my schedule. We agree not to worry about estimates (we are very much in the #NoEstimates idea) but focus on what helps us forward, without haste. Thinking over deadline.
Throughout the day, the developer mentions things he's changing, kind of as a checklist for me to see what to cover. But for me, that is a checklist of things he already covers. I give him as much ideas as I have, help him work through the minimum scope and risks.
Late in the afternoon, I know that it will be a long night before it's done. Working on it has revealed a bunch of dependencies and connections. Instead of telling the product manager that the developer was overly optimistic, I mention that I will not be available for quite as late as this would require. And it's better for the two of us to take a look at it without rush. No disagreement, work continues.
4:23 pm the developer mentions he just checked in the code in a branch he worked from and asks for help. I test, and I find 7 issues, out of which 3 have been introduced with the change. He fixes all but two. One is related to a complicated set of rules and we agree to take more time on pairing on that. The other is an inconsistency that has been there before, that I just hadn't paid attention to before. I know that addressing the one left behind is only a matter of days anyway, and we agree it can wait now to keep our eyes on the customer need.
There's a lot we could improve here. But there's a lot of good here too. And it's just a day in the life of this project. And my hat tip to having great developer colleagues.
