In a way I have come full circle: I started as a web developer in 1999 and I returned to being a web developer in January 2014. Intermediate steps: Studying Computer Science, creating e-learning content, usability & UX, scrum master, mashup of project manager & agile coach & product owner, and at good long last a Sabbatical.
During my Sabbatical in 2013, I figured out that supporting roles such as Scrum Master and Product Manager are not as satisfying to me as developing had been. I would have liked to thrive on serving others, but I don’t. Not yet anyway. I hope to get there one day. I’m good at it (better than I am as a dev) but not happy. Consequently I took a deep breath and switched back to being a web developer. The change of role brought along some funny changes in perspective:
Retro appreciation
I love retros. To me, they’re the most important of the agile rituals. When I was a scrum master I didn’t really get why developers were so often reluctant to attend. Now I totally get it: As a scrum master it is my job make sure retrospectives happen and result in change. When a retro tanked (no clear actions to take; talking about side issues, not the elephant in the room; …) I would look forward to the next one and plotting how to improve.
As a developer I’m a much harsher judge of whether it was a good use of my time. My main job is to create something useful for our customers, not meetings. So, I want each retro to improve us as a team and when the last one was meh, I now drag my heels as well. I could be coding in that time!
On a more abstract level, I still consider the retro incredibly important.
Obsessing over problems
When I was a scrum master, it felt like every problem anyone had was my problem to solve. It was hard to shake but I learned to let go. Now I rarely turn other people’s problems into my problems, especially if those “other people” are outside of my team. How liberating!
Changes to the backlog
In my roles as scrum master and product owner I knew viscerally that responding to change and re-ordering the backlog are an important aspect of the PO’s job. No harm done.
As a developer I still know that but it feels different. The nearer the story was to being part of the sprint or – gasp – mid-sprint changes, based on new information… I hate it now. I’m like Come on, couldn’t you have known that earlier? Although I still remember that as a PO, no, I didn’t change things late to vex devs. I just didn’t know earlier. Period.
Trying to get away with minor inaccurate design details
When my focus was UX or product I would frown about devs who try to get away with badly aligned interfaces and weird spacing. Turns out, as a dev I try to get away with it, too. And I don’t even have the “design blindness” excuse other devs use so frequently. I see the misalignment perfectly well, but I also know that it’s gonna take 3h to get that minor box to behave. (The cases that are easy to fix, I fix right away.) So I at least try to sneak it past UX and PO. Although it hardly ever works…
Some things never change, though
- I’m still quick to take initiative at whiteboards and in stand-ups – sometimes too much so
- I still often translate technical issues into the “PO-readable” impact they’ll have later on
- I “sell” technical maintenance to the POs instead of taking the usual “We just have to do it, because we have to do it” dev approach
It’s a great privilege to try on so many roles for size. First hand experience makes it easier to relate to the other roles and what’s important to them. It’s an even bigger privilege to find the role that makes one happy. Have you tried more than one role? What did you notice about how you act depending on your role?