Implementing Development Processes
20 July, 2021
When I took over my team three years ago, I helped them scale from twelve engineers to forty-five. Part of that involved introducing development processes to our workflow. We wanted to make sure that everybody on board knew what they were supposed to be doing at any given time, as well as to provide context into why they were doing it.
This was one of the biggest things that I had ever had to do for the company; I spent a lot of time during my first year doing this. We wanted to bring everybody into alignment over the work. This was challenging, as we had to achieve this alignment across multiple teams who were all focusing on something totally different. This included our QA team, who also reported to me.
The engineering team used one tool to track the bugs that needed to be addressed; there was no real process outside of this tool. We were releasing weekly, so there was always something to be done in front of us.
The teams were not used to relying on a process when it came to the work that they were doing together. We ended up trying out kanban boards, adding an element of Agile to our workflow. Kanban boards are great because they allow the engineer to work at their own pace. Adapting this tool eased the transition between departments as they passed off work to one other.
We also started using JIRA, creating tickets for every task to be done. This goes beyond fixing bugs and things of that nature; the system also includes feature work, as well. Everything has a place on our Kanban boards, and it’s made our work together much more efficient.
I wrote a lot of documentation explaining the processes that we had implemented. I wanted to make sure that everybody who was utilizing the system understood how to do so. There was some disconnect between QA and the rest of the engineering team, so I wanted to lay out their needs clearly in the documentation. This provided others with the context of what they needed to test the product on their end. One of QA’s biggest challenges was planning what they needed to test before our releases every single week. This process gave them the visibility that they needed to carry out their work effectively and autonomously.
When all that a person has to do is refer to a ticket on their Kanban board, they know exactly what they should be doing, immediately and without question. We diverted our releases into branches using Git branching, stabilizing our main release branches while still making progress elsewhere. I let the team figure out their pain points so that we could get together and talk about resolving those issues.
My message to my teams: nothing that we do is set in stone. We try things, and if they don’t work, we collaborate on ways to improve them. This is how we evolve as an organization.
- I think it’s really important to earn buy-in when trying to instate processes like this. If I’m just telling people what to do, I run the risk of implementing “solutions” that cause more trouble than they solve. Some leaders work blindly in this way. Feel the team’s pain and work together to resolve it.
- We have many more managers now than we did before. For feature work, each team follows their own personal Scrum board. We plan our sprints in two-week intervals. The work is now so much smoother. We are more able to orchestrate releases and to work with our product managers and my QA team. They have all of the visibility that they need to do their part; we even invite them into our sprint meetings. We ask to hear all of their challenges first-hand.
- Listen to your entire team and remember their pain points. Guide them through the process of solving them. Let them be an active participant when finding a solution. It’s a lot of talking and understanding, but it will be effort well-spent.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.
Director of Product at Startup
William Bajzek, Director of Engineering at Sapphire Digital, compares and contrasts a team structure that utilized siloed skill sets and one where everybody’s duties overlap at the edges.
Director of Engineering at Sapphire Digital
Neelima Annam, Sr Director Information Technology at Outmatch, shares how something as minor as collaboration tools can be a BIG issue during mergers and acquisitions.
Snr Director Information Technology at Outmatch HCM
James Engelbert, Head of Product at BT, shares how managing up is all about being an excellent manager to bring the best out of a team.
Head of Product at BT
Piyush Dubey, Senior Software Engineer at Microsoft, shares his journey of climbing up the career ladder through awkward times dealing with an introverted manager.
Senior Software Engineer at Microsoft
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.