Sometimes we are having a difficult conversation with a client, where mismatching expectations happen due to unclear communication.
On top of the toxicity in encouraging and praising metrics around speed of code delivery, impact in terms of rework or lines of code added, chasing story points, glorify story points accomplishments and sprint predictability, gamifying our jobs. We would likely be better off getting rid of those altogether.
The question I like to discover is what the value is in establishing those policies.
But if that’s the metric that is associated with stating success as a developer (and consultant) at the client’s company, then the end picture is inaccurate. If the expectation is around other aspects, those need to be recognized and measured, too. Following a controversial anti-pattern of measuring, which is at least leveled across other fields.
How might we measure the value I try to bring in as a consultant? I am still learning, every day. I am new and eager to grow.
In fact, as a developer, I tend to think of the aspects that touch the code:
- how we write specs
- how we write commit messages
- how we do PR review
- how we write documentation
- how we share knowledge
- how we ask for and offer help and learn in the open
Another aspect I see great value in is communication:
- how we ensure meetings are inclusive
- how we have difficult conversations with clients
- the importance of words and language
- how do we give feedback and participate in retros and 1-on-1s
- how we keep communication in open channels
- how we are honest and talk about risks
- how we deal with deadlines and other questions around delivery predictability vs unknown
(In no particular order.)
I am not inventing anything here. As a matter of fact, I recalled the excellent links that Josh shared with me when I started at thoughtbot about 6 months ago. I am going to go through them again. –Read as many open tabs in my browser, but if I miss them, now I can come back here.
Some links from that collection: