When your product is bespoke software, a lot of process decisions are naturally case-by-case. Nonetheless, you can get valuable insight from visualizing each feature request's path to deployment as an assembly line that can be optimized.
I recommend the book The Phoenix Project to everyone who works in tech. One of its key insights is the idea of applying factory-floor optimization philosophies to software projects. On a physical plant's assembly line, it can be easy to spot bottlenecks and inefficiencies. For a software project however, we need to visualize the flow of work, using tools like a Kanban board. With a Kanban board, you can imagine each column (or work status) as corresponding to a workstation in an assembly line. Development tasks flow on the board from the left (e.g. "To do") to the right (e.g. "Deployed"). At Zivtech, we use online Kanban boards in Jira to manage our tickets.
To optimize development efficiency, you find ways to speed up the movement of cards to the right across the board, and decrease the "negative flow" of cards moving back to the left. There are a few key concepts that are handy towards this end.
In an assembly line, you have multiple workstations running at the same time with work moving in a series from one to the next. Imagine our 'workstations' are something like:
Whichever stage of the process is the slowest will define the overall flow of work. Only identifying and addressing the bottleneck will move the needle.
If your team relies on the same individuals manning multiple workstations ('wearing multiple hats'), then it's more accurate to think of the individuals as the workstations rather than the task. For example, if I'm personally handling requirements gathering, back end development, code review, and deployment, then we could potentially reduce a bottleneck at code review by making the deployment process more efficient.
In knowledge work, you will tend to find that the more advanced workers will be the bottlenecks. A lead developer or senior engineer is a likely candidate. An executive-level stakeholder who needs to give feedback or approval is another. This can be because this person's work is the most difficult to scale or because they have too many responsibilities. To reduce this bottleneck, a manager may be able to remove some responsibilities, automate some of their tasks, or help them prioritize and use their time wisely.
Work in Progress (WIP) is all of the work that has been started but not completed. Too much WIP makes a factory floor crowded. The same thing happens on our Kanban board. Flow tends to reduce when there is a lot of WIP. On the open source project Drupal (core), for example, there are currently 17,000 open issues. Issues can take years to complete, with constant re-rollings of patches. By spreading a team out over a lot of WIP, you can bring flow nearly to a halt.
If everyone on the team understands the danger of excess WIP, they can change their habits to prevent it. I like to look at my tasks like a baton that I'm passing through a relay race. When someone passes me a ticket for code review, that's a hot potato of a task that I need to complete ASAP and pass to the next racer. (Yes, I also like to mix metaphors.)
To reduce WIP, you need to prioritize tasks that are further right on the Kanban board, overcoming any personal preferences to start on fresh tasks first. You can also make smaller boards; we chunk our projects into two week sprints and only show the active sprint items on the board, working to get a batch of tasks done before starting the next batch. You also want to optimize the size of each task because tasks that are too large will tend to move through the process less efficiently.
When is the worst time to get feedback on your work? If you're saying right before launch, the day of launch, or after launch, then no doubt this is not your first rodeo. When's the best time? As early as possible - ideally immediately after you've got something to show, even a prototype.
My first post-college job was writing quality control tests for lip balm manufacturing. As the balm moved through production first, it was a gloopy mixture of ingredients and finally it was loaded into individual tubes and sealed into blister packs for retail. When do you think they first verified that the ingredient mix was accurate - before or after packaging? You always want to find problems as soon as possible in the process because this is the most efficient time to remedy them.
On the Kanban board, this means reducing the leftward motion of tickets. You don't want a task to make it all the way to the right-side deployment column and then have to move it back to the beginning of the board. To reduce this leftward motion, you need to ensure that your process includes getting feedback early and often.
I find the way some development teams live with bugs to be rather unhygienic. They may tend to allow known bugs to hang around in their work with the idea that they'll deal with them all in some bug-squashing phase at the end of the project. This is not the most efficient way to fix bugs and the final quality of the work will never be as high with this approach.
The best time to fix a bug is as soon as the bug becomes known, prioritizing it ahead of other work. Work should not pass on to the next 'workstation' with known defects.
It's no coincidence that all these concepts are interrelated. Reducing bottlenecks and shortening feedback loops decrease WIP. Less WIP leads to reduced bottlenecks. Quality is improved with more feedback and better quality decreases WIP. The ultimate goal is a faster and less expensive process and reduced stress and dependency on heroics from your team.
At Zivtech, we noticed through the years that lead developers like me were almost always our bottleneck, and that tickets tended to accumulate in the 'Needs Code Review' and 'Needs feedback' columns on our Kanban boards. We also noticed that we had trouble getting feedback from stakeholders early enough in the process to have short feedback loops, and that we were relying on our bottleneck people to do basic QA testing early in the process.
We addressed these problems by incorporating automated QA sandbox environments into our workflow by building our product Probo.ci. Automated QA sandboxes reduced our worst bottlenecks, shortened feedback loops, increased quality, and decreased WIP. I would recommend exploring automated QA sandboxes for any software team, whether via Probo or a similar tool.
I talked about these concepts and more recently at Drupal Govcon. You can watch the full presentation video below.
Jody is a full stack Drupal expert. She does technical architecture, strategy, development, consulting, and developer training. Jody has worked on hundreds of Drupal projects since she began as a freelancer in 2006 and co-founded Zivtech in 2008. Jody grew up in the Philadelphia area and graduated from Harvey Mudd College in California in 2000.
View the discussion thread.
Tell us about your project