Process by Management
Alice's team was thirty developers, taking up most of the floor of a nondescript office building in yet another office park. Their team was a contractor-to-a-contractor for a branch of the US military, which meant a variety of things. First, bringing a thumb drive into the office was a firing offense. Second, they were used to a certain level of bureaucracy. You couldn't change a line of code unless you had four different documents confirming the change was necessary and was authorized, and actually deploying a change was a milestone event with code freezes and expected extra hours.
Despite all this, the thirty person team had built a great working relationship. They had made their process as efficient as they could, and their PM, Doug, understood the work well enough to keep things streamlined. In fact, Doug did such a good job that Doug got promoted. Enter Millie, his replacement.
Millie had done a stint in the Air Force and then went back to school for her MBA. She had bounced around a few different companies, and had managed to turn every job change into a small promotion. This was Millie's first time overseeing a pool of software developers, but she had an MBA. Management was management, and there was no reason she had to understand what developers did, so long as she understood the key performance indicators (KPI).
Like the quantity of defects. That was a great KPI, because it was measurable, had a clear negative impact, and it could be mitigated. Mitigated with a process.
After a few weeks of getting her bearings, Millie called a meeting. "Alright, everyone, I've been observing a little bit of how we work, and I think there may be some communication and organization issues, so I wanted to address that. I've looked at our current workflow, and I've made a few small changes that I wanted to review."
On one side of the white board, she drew a bubble labeled "In Production". "This is where we want our code to be, right? Working, quality-controlled code, in production, with no defects." On the opposite side of the board, she added a bubble for "PCCB Ticket." "And any code change starts with one of these- the Product Change Control Board reviews an open ticket. They'll then turn that ticket into a Functional Requirement Document." Millie added another bubble for that.
Alice had some questions already, but not quite about the inputs or outputs.
"Great, okay, so" we need to iterate on the FRD, and once the PCCB signs off we'll convert that to a System Requirement Document. Either a PM or a SME will decompose the SRD into one or more Work Packages."
Millie continued scribbling furiously as she explained exactly what a work package was, as this wasn't currently a term in use at their organization. Her explanation wasn't terribly clear, as Millie explained it as the set of steps required to implement a single feature, but a Functional Requirement was a feature, so how was the Work Package (WP) any different than the FRD?
"Please, hold your questions until the end, we have a lot to get through."
Finally, once the Work Package was analyzed, you could create a "Ticket Lifecycle Document", a new document which would hold all information about all of the efforts put towards the PCCB ticket. Which meante the TLD contained all the WPs, which raised questions about the point of adding work packages. From the TLD to a new PCCB ticket- a "Ready" ticket, then finally those requirements could go onto a Release backlog and a release management plan could be created.
"Finally," Milile explained, "we're ready to write code." In the center of the board, she added a single bubble: "Code".
And on and on the meeting went. The diagram grew. Lines kept getting added. Bubbles got inserted between existing bubbles. Arrows pointed to labels, or to bubbles, or maybe to arrows? By the end of Millie's meeting, it looked something like this.
"There, that lays out the correct pattern for getting our software to production, with a feedback loop that prevents defects. Any questions?"
There weren't any questions at the meeting, no. But boy, were there questions. Loads of questions. Questions like, "What font should I use on my resume?" and "is it time to stop listing my VBA experience on my resume?"
Over the next few months, under Millie's leadership, 17 developers from the 30 person team left the company, Alice among them. Every once in awhile, Alice checks the job listings for that company, to see if those developer positions have been filled. They're still hiring for software developers. Unfortunately, Alice hasn't seen any openings for a PM, so Millie is probably still there.
[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!