The well-known, well-established killer
– Do I have to write release notes? Maybe they can be generated instead?
– If you don’t want to manually write release notes you’re incompliant. It’s developer duty – maybe those weren’t exact PM’s words, but it’s what I read in between the lines.
It was small thing, and I felt like I proposed the improvement of the process – automating one step of documentation: I’ve asked if it can be generated (unfortunately by someone else I had no rights to generate the documents automatically from the tracking tool so there’s no other way – I had to write it). The answer was blatant ‘NO’ so I spend hours analyzing what I did over the release phase: all functionality changed/implemented, all bugs fixed and so on… However, the final nail in the coffin was when the PM told me that the release notes must be approved by him and QA Lead before the actual installation on the test environment.
How would you feel in a situation like that?
More efficient and accountable? Like you helped to avoid issues, and increase the quality from very low to high?
I didn’t. I felt extremely discouraged and ineffective. Like I wasted hours of my time.
It may be just a part of a process.
But I questioned the status quo and I’ve heard I’m incompliant. Sounded like lack of openness.
And approval before testing? It gave me a vibe of lack of trust.
I also felt like the process was more important than my job and my responsibilities as a developer.
When somebody’s job depends on maintaining the status quo that person can feel reluctant to expend an extra energy toward creation and invention.
And creation and invention is what the developer’s job is about.
Kill the killer
So don’t hinder the developer job more than you need.
- Look carefully at your process and don’t blindly follow it, rather adjust it as needed – it will improve the efficiency in a long term.
- Remove all redundant tasks that are done only for the sake of the process.
- Look at:
- Long chains of obtaining permissions – it slows down, not empower
- Overloaded meetings, when half of the team is not needed – it’s not productive, I don’t think I need to elaborate…
- Your focus on the process: do you value your process more than your people and follow the process to the T. even with the cost of the team?
- Documentation: does the project need all the documentation it produces? Maybe it can be done in more iterative way? Maybe not all of it is needed? Consider who’ll ever read that documentation?
- Your openness and perspective: Do you let people speak up or do you tear them down when they propose new ideas? Do you view “different” and “new” as bad?
Remeber “That’s not the way we do it here,” is a synonym of “We prefer to let someone else do it that way and succeed in figuring it out so that they can take our customers away” but the second one doesn’t sound as comforting.