Projects, Process effeciency | Oleg Braginsky, Maksym Golub
Product development seems straightforward on paper. Practice reveals cases that prevent it from being efficient. Employees would say that they have a “specific case” and build workarounds. With founder of School of Troubleshooter Oleg Braginsky and student Maksim Golub we figure out the way to make it right.
When working with multiple teams on various projects, it might be getting hard to control everyone’s output. Moreover, it is better to have a system in place, so that you only look into the final result without getting into the specifics. While in the book’s product squads starts and finish together, it may not always like that.
The company’s product development process consists of two major parts: defining and designing features and then developing them. For the simplicity, the rest will be omitted. We will focus on the first stage. The main problem we saw that with the current settings is that it was hard to see who does what exactly.
It was quite a sad observation that when there’s no clarity in status and flow, or there’s a room for the misinterpretation, people willingly or not tend to bend reality in their favor, hide behind the trees: saying it’s too much effort, they were working on various things, delivering only handful tasks by the end of the day.
After gathering intel both from speaking to team members and pulling the data, there was a realization – current flow is a mix of statuses and stages. At the initiation part we would have stages like “Idea”, “Description”, “Design”, while at the development there were statuses from “Todo”, “In progress” to “Done”.
Apparently, there was a little of a struggle and bunch of back and forth. But thanks to the change management techniques, team overcame this fast by providing clear communication, crisp presentation and acing internal negotiation. They defended the approach in no time and were ready to start cracking.
After brainstorming, doodling and contemplating different options, such as adding more statuses, renaming or even creating different projects for each team, we found an elegant solution: if the process is conveyor with different levels of production, why can’t we open this black box and set mini-conveyors for each stage?
The idea was: instead of having a long tail of tasks, add new types of the sub-tasks for design and product folks. Each issue had a status: Idea, Planned, ToDo, In Progress, Review, Done. The draft was quickly prepared, presented to other teams to get their buy-ins, as we were not planning to sit at our ivory tower.
New tasks were added along with the status model. Next step was to create a workflow. Made it pretty flexible to allow variations and not limit teams too much. After small consideration added the “Reopened” status, that should help contributors to check return items and manager to understand a success rate.
Next step was to say goodbye to tool rules and break the dependency. We introduced linking, allowing put tasks into random times and set the type of relationships. Otherwise, all of them should be in the same sprint, requiring a work to be finished at once. With teams working at different paces, this was not an option.
There was another dimension that required an attention. We cut down the number of priorities from seven to five, and there was also an explanation given of how to set them right leaving us with: High, Medium, Low. Urgency was left for anything extraordinary. Highest, Lowest were benched as unnecessary ones.
The upgrade also touched hierarchy. Epics would not be sufficient. Therefore, Milestones took a higher place in line. There was a hesitation to call them “Initiatives” and using releases feature instead, but then an explanation was made to resolve it: Milestone means not releasing, but achieving a significant change.
To optimize creation of tasks, we leveraged an Automation. Every time a user story would be created, there was an option to add child issues of different types with all necessary details. And vice versa, if person would work on a product or design-related task, it was quite easy to add a parent in just few clicks.
As team started working with a new flow, two more problems evolved – there were many things in progress. It would create a multitasking mess, leading to slow progress of work. The solution was to introduce design grooming for evaluating scope in advance and limit the number of tasks in pipeline to increase focus.
Another measure was encouraging team to provide estimations in time during the grooming or after it. We deliberately walked away from story points and chose time instead. Apparently, in business everything is measured by real-world units, otherwise owner will end up paying creative people who just float around.
To make sure there is no unmeasured work sneaking into the pipeline, there was set a rule that the field should not be empty to pass the task through. Although, it got “hacked” by smart people, who just started putting one minute. Although, it did not last for long due to good internal communication within the team.
There are always things to improve here and there. In our experience, most of them comes when you trying to build processes taken from the material world or just put people, their time and focus first, but also think about the entire company. This mix of things, with a bit of luck and experimentation, could yield great result.