I recently spent weeks reviewing more than three hundred session proposals for the Agile Dev, Better Software & DevOps East conferences. We only have space for fifty-six on the program, so we had to make some tough choices about which to select.
While discussing her submission, one speaker asked, “Do you see any common themes in the proposals?” After reviewing all of them, I looked at each proposal again—this time in a broader context of common themes. The major one that popped out was the classic “Everyone wants change, but no one wants to change.”
A number of proposals asked what to do with development and test managers as teams move to agile. Agile encourages self-organizing and self-directing teams, so the traditional manager’s duties of assigning tasks, managing workflow, monitoring the quality of work, and keeping higher level managers informed is all done by the team itself.
Yet the speakers were not ready to change either the job titles or the responsibilities. Rather, they clung to the old way of thinking that managers need to be accountable for implementation. They want change, but they don’t want to change.
One proposal promoted the idea of a modern project management office that would replace current PMOs, which require multiple steps of upfront planning and are too slow for agile organizations. Perhaps the entire concept of the PMO is no longer relevant and should be replaced rather than repaired.
Another described how to be agile with manual testing. This idea flies in the face of providing rapid feedback. I can’t say for sure, but I’d guess this approach has been championed by manual testers who want change but don’t want to change.
But some speakers get it. One proposal described how the traditional roles of functional QA managers are changing thanks to agile environments. It suggests new domains for the QA manager to be responsible for, including owning quality, release management principles, technical solutions, working with a smaller testing operational team, and advancing new testing areas within the agile lifecycle. This proposal does not cling to the old approach, but instead acknowledges that a change in focus is required if the QA manager title is to remain relevant.
Another proposal told the story of a senior QA director running a team of fifty who was “demoted” to the ScrumMaster role. He describes his journey, including fears and uncertainty as the organization decentralized testing and moved toward more agile self-organizing teams. He reinvented himself in order to stay current and best support the organization’s mission. He says keeping a good attitude led to a new invigoration late in his career when he was forced to re-evaluate the landscape, refocus, and take a chance on a new and exciting way of working.
The moral of this story and the pattern I’m seeing in issues important to software teams boils down to this: If you want change, you first need to be willing to change.
