I've been trying to find a very reasonably scalable process for creating, estimating, tracking, and ultimately delivering work at a digital agency in my current role. As noted before in my posts about leading developers at digital agencies, a lot of the advice out there is aimed squarely at product focused companies and startups. Even seasoned leaders such as Jakub Chodounsky who compiles the excellent Leadership In Tech newsletter told me that while they don't have a lot of background here, issues that I raised seems to be very common in the space.
The agency model has a lot of challenges around how to do things between many different projects that have somewhat unstable teams, deadlines more than roadmaps, and a list of milestones and capabilties that might not have a lot of flexibility to them depending on the type of contract you have with the client. To me this says that we need a process that
Vadim Kravcenko's Process DebtThe Best Process Is No Process. Unless you're more than 1 person in a team.
We often have teams of one working on projects, and oftentimes just two. A frontend developer and a backend developer. I completely agree that in isolation that a single dev or a duo can really manage the overhead of working on a project without writing everything down. No tickets? No problem.
Except that it is a problem. Teams in the agency model are hardly stable, especially when it comes to the one or two dev sized engagements. Oftentimes you have someone more senior working on the initial parts of the project and then they move on to a completely different project, and now you've got to onboard a new person. Obviously the answer is to have the original person do the complete scope of work, but the reality is that it's often not possible due to capacity and capability constraints.
This really ruffles the feathers of the affected developers. The person who was on the project, and is coming on to the project, probably hates having to write out work tickets. It's unnecessary overhead, and we should be minimizing that overhead! One of my more talented, but challenging, developers told me during a 1:1 that "[they] just hate having to write out tickets and documentation. [They] just want to work and get things done". Another developer of mine who was missing out on requirements, had no idea how long what they were doing was going to take the, or didn't have a strong grasp on what the acceptance criteria for what they were making was said "I know, it would have helped to fill out the template on the tickets, and it might have made me think about these things, but it's this time intimidation, y'know?? Like, it takes time to fill them out". I offered to go through the process with them, and after they accepted, we filled out two weeks worth of work in about 30 minutes, and had a small list of questions that needed responses from the client and a couple that needed to be brought up with the team.
I think the word "ticket" has gotten a bit of a bad rap among developers. One of the things that I've heard is something along the lines of "yea, we don't do tickets, we're using Kanban to manage our work". My thoughts there are what do you thing an item on kanban is? A ticket, by any other name, would be so much sweeter?
Normally you'd think this is the group that would be all about task planning and work management. Well, in my current gig, this is very much not the case. They also don't like tickets because they have to fill out the template and they also feel like taking the requirements from the client and putting them down in to a structured template is just too time consuming for them.
We've had all sorts of strange ways that this has manifested itself.
One PM's team developed a Notion page that listed out the things
that they wanted to get done each week with a very short description
of what they wanted. Priorities were set using the text highlighting
feature (with no legend), completed items were marked by changing
the text to be strikethrough. The ultimate in TODO lists (a
TODO item is a ticket by the by).
Another way it presented itself was that they created a whole new spreadsheet that they got the customer to fill out collaboratively with them, putting a lot of that burden in the hands of the customer. This included a lot of "internal" work specific to the implementation. This, of course, caused a lot of strife when things were changed and not communicated. It also compounded the issues because when devs and/or PMs were not disciplined in their updates, the customer got upset. They would check the work table before anything else, and then come to the team quite upset that there had been no progress for several days.
This is where I'm sitting, and I love work management. I love Kanban for work that can be done solely in priority order, and when the team doing that work is capable enough that they can just grab things off the board, clarify anything that is unclear, and then implement it. Sometimes you want both! You might want a heavier process during feature development to capture dependencies, communicate timelines, and demonstrate that you've done enough design and thinking ahead to capture most, if not all, of what the requirements are. Yea, it's a little bit "Cover Your Ass", but it's also showing your work. When doing bug stomps, tech debt sprints, or working on a release candidate, I'll often switch over to a more Kanban style of work. Those work items often need less detail, or sometimes the title of the work item is enough to get it done.
The other thing for me is, again, somewhat specific to my current company's business model, but it's that when details aren't written down in a fairly structured format, prompting clarification and questions where necessary, people can't move between projects without higher levels of friction. I've got limited capacity to fulfill the demands of the sales team, and it's never going to get better. No matter how much planning around the availbility of my team's time, demands will be made that necessitate the movement of team members between two different projects. Asking them to paradigm shift without a clutch is only going to harm us long term. That clutch is the structured ways in which work is organized, planned, and communicated. As an added benefit, it also helps when working with satellite workers, or offshoring teams.
Lastly, as someone who has also been a software developer, it gives me insight in to the way that the team thinks about the problems we're solving, how effective we can be working asynchronously and/or remotely, and how well we're designing and planning the software we develop before delivery as leading indicators of problems. It saves me a lot of embarrassment, apologizing, and ultimtely allows the business to secure clients for longer and more beneficial engagements. Customers are happy only when they get what they paid for (or more specifically what they were expecting). We can manage those expectations, but if we only do that long after problems should have been visible, we're going to have dissatisfied customers and a dying business.
Authored by: Mal
Written: 2024-01-014