Your Team Isn’t Planning Enough, And It’s Your Fault
The beauty of those first few days of a new project, clacking away on never-before-seen code, entering that blissful zone where everything is possible, listening to your most killer jams fades slowly into a peaceful indifference of time over the next few weeks, steadily reaching a boil near the end of a project’s lifecycle where everything seems to be extreme and nothing is fair.
Deadlines. They always show up. In early development, they seem so distant, but a week before the drop-dead date, there’s a scramble to fix all of those bugs that pesky QA Engineer found and add that one feature that you forgot about.
You are the team lead. If the project is of any size and importance to the company, you are probably choking under some stress, working a few late nights, and you just want to be done.
Eventually, you will be finished. You will ship the project, probably with a few more bugs you and your team need to patch over the coming weeks. But you know what? You did it. You’ve learned some lessons, hopefully had a retrospective, and are ready to move on to that next big project. Good job, you.
Actually, let’s rephrase: good job, team.
You see, it was your job to keep the team from feeling stressed, to keep them cool under pressure, to make sure the project was finished in the amount of time promised to the client. And yeah, sometimes it’s out of your hands: clients and bosses are demanding, despite your arguments and attempts to keep projects in scope. But, if I had to guess, you and your team suffered from a classic software development dilemma: the Snowball Effect.
And guess what? You’re probably never going to avoid it entirely, because it comes from a simple fact of human nature: we’re flawed creatures. However, you can sure as hell mitigate the effect.
The Snowball Effect
In software development, a series of decisions are made, possibly by an array of different people. Every decision that is made, every line of code that is committed adds to a growing collection of complexity that makes the job harder. Every team starts with a precious snowflake, and eventually, it rolls and rolls and rolls until eventually a large snowball is rumbling down the mountain, threatening to devastate that village of team morale in the valley below
Really, software development is as prone to the Second Law of Thermodynamics as anything else: chaos increases as time moves along.
So what can you, a development/engineering team lead, do to fight back?
Strategy is Preparation
There’s a laundry list of possible solutions to the Snowball Effect, with no one solution providing complete coverage: project management strategies like Scrum, architecture decisions not being dictated by tech leads, stronger code ownership, effective scoping and estimating, etc. All of these solutions (and more) have had tons of great talks given and articles written concerning them, but there’s one major piece of the puzzle that’s mysteriously absent. I remember it being a key point in my CS classes, but throughout my time working professionally, there doesn’t seem to be much importance placed.
Planning. Not just architectural discussions and documentation, but planning folder structure, linting, frontend layout approaches, application structures and diagrams, diagrams, diagrams.
Diagrams. I feel like anyone who’s taken a CS class has been taught at some level what a function diagram is. Diagrams aren’t just useful for functions. Think about asynchronous control flows, complex application communication, logic that surrounds business requirements. I use Lucidchart pretty readily, both at work and at home. Lucidchart is super collaborative, allows a ton of sharing, and has a boatload of built-in diagram blocks to choose from.
I always tell my junior developers to plan before they code. I try and drill it into their heads, and sometimes I succeed. I tell them to draw out on paper how they’re going to approach containers with HTML and CSS, to jot down their step-by-step function actions, and to map out their schema. I remember being a junior developer (despite all the beer) and I remember how exhilarating it was — and still is! — to just jump right in and code while on the edge of your seat, not really sure what would come next, what awesome solution you’d break out next. The idea of wasting my time planning when I could be coding was ludicrous to me. But you know what I discovered, once I started planning before I touched a line of code?
That the fun stuff, figuring out a solution and effective solving a problem, was all done with effective planning.
A Note About Good UX
Hire a UX engineer if you do any sort of serious web development as a shop. If you’re just the tech lead, beg your boss. Hands and knees, just start begging. Good UX does a lot for a project, but in terms of what it means for the subject of this article, good UX informs good dev. UX through BI/BA, wireframes, functional specs, anything. If you have some solid UX, chances are most of the difficult, abstract, non-technical work has already been done by the time coders even get involved.
Plan to Plan
In summary, planning is crucial. Planning every step of the way, not just the beginning of a project, is essential. Too often, developers will plan before they start to code a project, but by the time they’re a week in, chances are you’re not going to see a ton of focused planning. So what can you do?
- Realize that effective planning isn’t going to add time to your scope. Drill that into the heads of your Project Managers. Planning is good. A solid, experienced PM will be drooling when you mention developers planning.
- Sit your whole team in a room, or open a channel in Slack. Ask them why they don’t plan as much as they should, and then show them this article. (Shameless promotion, I know.) Ask them how you can help enable them to plan more.
- Expect planning. Tell your team that you expect them to plan, and that effective planning sessions can impact their performance. And then hold yourself, and them, accountable.
- Be part of planning exercises. In the beginning, depending on how your team operates, you’re going to probably want to be in a few planning sessions to help them get going and to encourage collaboration. Figure out what diagrams, lists, charts, and exercises work best for your team, and then make them a part of your culture.
- Teach new hires how y’all do thangs. It’s a cultural thing that’s expected of everyone, so make sure you don’t leave your new hires in the dust! They’re, in theory, your next gen devs, so make sure you’re instilling the right ideals into them from the start.
- Make sure planning sessions are documented. This is probably the most critical. What good is effective planning if the results of that planning session are left in the room when everyone leaves? What if half the team gets hit by a bus and you have to ramp up X/2 developers on a project after the team had already completed two-thirds of the build?
- Make sure planning sessions are collaborative and conducive to idea sharing. In my experience, there’s only a few subsets of developer personalities, and one of them is quiet, and the other one is loud. Make sure you, as team lead, are keeping the balance.
It’s not going to be an easy road, goodness knows that I’m still working to see what I can and can’t do with my team. You are going to be at this for a while, but once planning becomes a part of your culture, everyone can move faster while all being on the same page.
You have to promise yourself something, before you even start trying to implement some kind of planning culture, though. You have to promise that you will help shape, inform, and nurture planning. You can’t just tell your team that they need to start planning more and walk back into your office/cubicle/corner-desk-underneath-the-daffy-duck-velociraptor-on-a-skateboard-painting. You owe it not just to your team, but to yourself, to see this through. Because, in the end, you know who’s going to be stressed out the most when that project deadline is looming, and none of project management’s finest tools can save you? You, tech lead.
So grab your team, pick up that paper and pencil, uncap that whiteboard marker, and open up your favorite diagramming software and get to it. Get planning so that you can get coding.