I was recently voluntold to take over management of a software development team that was struggling — by no fault whatsoever of the individuals on the team. In fact, the individuals are all stellar — super smart with great experience. So I did what you do when you’re voluntold and you want to be a team player: I dove in. Below is an account of what I did (and continue to do) to get the team productive and excited about their work.
But First…
- I don’t claim to be a great manager. I’m an OK manager. I’m a big-picture guy and pretty creative. That means I’m not nearly as strong on the administrative side, but I know how to solve problems.
- I like being an individual contributor. I’m happy to be a leader, but middle management is not my desired occupation.
- I did not accomplish what I’m about to convey by myself. I had a TON of help and support and accountability from my teammates. The decisions and patterns I’ll outline are mine. The implementation and the path to those decisions are not wholly mine.
- I have lived through a pretty dogmatic implementation of Agile. I learned a lot about why and how it works, even if it does sound a little hippy-dippy. I know without a doubt that it builds speed over time. Some of what you’ll read below reflects that experience.
- You’re welcome to rip off everything that I write below. You’re also welcome to politely disagree with any of it.
Be the Calm
Coming into the team I had a little bit of context, but I assumed nothing. I did not come out swinging. I entered the flow of the team as it was and spoke with a calm voice. I gathered data. I spoke with various leaders on the team to get perspective on their situation, which had just changed abruptly. I acted with empathy. I planted seeds of ideas of change that could be pondered in a completely hopeful, not fearful, way.
Change can be hard, but when it’s needed it’s a relief. Though I did not introduce change immediately, it did come quickly.
Bring the Team Together.
The team had split into backend and frontend groups, which had dependencies on one another. The first problem to solve was that these groups were not acting as a team. The groups had separate stand-ups and depended on a key leader from each group to coordinate efforts. So, even though the team was kind of too big for it, we moved to a single stand-up with 18 developers.
Stand-up Expectations
With a group that large, the stand-up has to be crisp. It wasn’t when I arrived. So I kicked off our first stand-up together by setting clear expectations:
When we give our updates, they should be clear, specific, and concise. We have a lot of ground to cover. Just say what you did yesterday, what you’re doing today, and blockers. Any discussions beyond that can be had in an after-party.
Stand-up is limited to 15 minutes to force the issue of being concise.
We also introduced the idea of popcorn-style stand-ups. This means that when you’re done giving your update you call on the next team member to give their update. Why is this relevant? Because it keeps folks engaged. Rather than just waiting on their name to be called, team members have to pay attention to who has been called already. It also is a small way to spread out ownership of stand-up across the team.
After-parties
Sometimes called “parking lot”, the idea is to identify deeper discussions that need to happen based on stand-up updates. The time directly after stand-up has a hold on everyone’s calendar. The team is responsible for identifying and coordinating after-parties. Explicitly calling out deeper discussions and focusing on them outside of stand-up has the following benefits:
- The stand-up serves its purpose without bogging down the whole group.
- The group benefits from knowing that the conversations are happening, allowing individuals to get involved if they feel the need.
Two-pizza Teams
18 developers is a LOT to have on a single work stream. Sure, it can be done and it is often done, but it comes with some diminishing returns. We split the team into two “squads” (don’t get hung up on the term). Each squad has a staff engineer leading it, and the squad is cross-functional. The benefit of this approach is that we now have the ability to work on our top two (or more) priorities in parallel with two optimally-sized groups of engineers.
“How is this team size optimal?” you ask. In my experience, having 5–10 developers working together improves coordination and context sharing and increases individual ownership. When teams get bigger, there tends to be more “lob it over the wall” mentality — just do what’s in the ticket and mark it “done”. Two pizza teams create just the right amount of pressure and camaraderie.
Create a Rhythm
Predictability is the opposite of chaos. To the degree that we can create predictability in the things we can control, we will feel calm, secure, and ultimately we will be productive. As a software developer, chaos is the killer of productivity and job satisfaction. I always tell my team that if we’re doing things right, our jobs will almost be boring. That is, the problem-solving will be interesting, but everything around the problem-solving will be conducive to problem-solving.
So I aligned with team leaders first, and then with the whole team on a meeting cadence that creates a predictable rhythm:
- Stand-up
- Group: Squad
- Frequency: Daily
- Purpose: Context and progress sharing…Yesterday + Today + Blockers
- Time: 15 minutes - After-party
- Group: Squad subset
- Frequency: After stand-up as needed
- Purpose: Address items needing deeper discussion than stand-up
- Time: 15–30 minutes - Pointing Party
- Group: Squad
- Frequency: Weekly
- Purpose: Go through tickets, ask questions, assign points
- Time: 60 minutes - Sprint Planning
- Group: Squad
- Frequency: Bi-weekly
- Purpose: Decide which work will be committed to in an upcoming sprint
- Time: 30 minutes - Sprint Kickoff
- Group: Squad
- Frequency: Bi-weekly
- Purpose: Confirm committed work. Ask questions. Set goals.
- Time: 30 minutes - Work Breakdown
- Group: Squad
- Frequency: Ad Hoc
- Purpose: Look at mock-ups and/or requirements documentation and create tickets.
- Time: 60 minutes (usually) - Work stream prioritization (a.k.a. Lead Sync)
- Group: Leads
- Frequency: Weekly
- Purpose: Align product and engineering on priorities. Feedback mechanism between engineering and product.
- Time: 60 minutes - Retro
- Group: Whole team
- Frequency: Bi-weekly
- Purpose: Reflect on previous two weeks. Figure out what’s working and what needs to change.
- Time: 60 minutes - Demo
- Group: Whole team
- Frequency: Bi-weekly
- Purpose: We all gather to celebrate the functionality we’ve created and the bugs we’ve squashed. Nothing is too small to demo. Take pride in your work!
- Time: 45 Minutes - Social (we’re a remote team)
- Group: Whole team
- Frequency: Bi-weekly
- Purpose: Get to know one another. Chill out.
- Time: 60 minutes
That’s a lot of meetings, right? Well, yes it is. But all of them happen very predictably and have specific purpose to ensure that the time we’re not in meetings is productive and that we enjoy what we’re doing. The team ends up spending enough time together that shared context and decision-making frameworks (implicit or explicit) create autonomy that works like constructive interference.
Explicitly Align on Process
Do not assume that everyone implicitly agrees on the way we work — no matter how long the team has worked together or how much experience anyone has in the industry. Make a picture and walk through it with the team. Here’s the one I shared with this team:
I was shocked by how many questions I got as we walked through the flow above. They were all thoughtful questions. They were all the right questions. What I learned is that everybody has their own concept of how work should (or at least does) get done. Being explicit created instant alignment.
Foster Team Ownership
One of the key issues that I identified early on was that there were two members of the team that were responsible for knowing everything about every project and making sure that everyone else on the team had work to do (i.e. tickets). This approach had a couple of problems:
- Most importantly, it was a LOT of responsibility for two people. It was super stressful and it was too much to manage effectively for the individuals.
- The rest of the team had no ownership of the solution. Because they’re not involved in the solution, individuals have little-to-no context about the big picture. This results in developers’ jobs just being about completing tickets rather than building a product.
So we introduced a few key changes to address these issues (already hinted above):
- Popcorn stand-ups give team members control of the flow of stand-up. It’s small, but it’s meaningful.
- Work-breakdown meetings involve the whole squad in creating the solution and get everyone collaborating with UX and Product.
- Pointing parties give everyone on the team a say in estimating work rather than being handed expectations in a ticket.
Story Points != Time
99% (or some other made-up statistic) of software development teams estimate work in units of time. It’s completely natural. It feels like we should have enough understanding to be accurate. Well, we’re not. I have yet to meet a developer that isn’t over-confident in their estimations — myself included. The problems with this system are numerous and well-documented, the most hurtful of which is that time-based estimation creates implicit expectations with our product management partners and their bosses.
The team that I became a part of was no different than the 99%. And the frustration among the team and product management was high. So we changed our work estimations to units that developers are actually good at: relative effort and uncertainty. Choose whatever scale you want (I prefer 0–3) and then measure points/time to understand work capacity. The team now feels in control rather than under constant pressure.
Two Knobs
Creating great (or even acceptable) customer experience takes time. As I just wrote, developers are terrible at estimating how much time a task will take. All we know is that it will take time.
Since we can’t really control how much time things will take, I set about fostering a relationship with my product management partners emphasizing the ideas of “scope” and “priority” and talking about how much control they have over these two “knobs” with respect to deadlines. The idea here is to not be frustrated by what we can’t control but to act on what we can control. We always work on the highest priority task. We can change the priority of subsequent tasks at any time. We can also reduce scope on a feature if we want it out faster.
The one other related subject that I tackled with product management was that rushing work today simply creates tripping hazards for future-us. So we have to understand that moving artificially fast today means moving slower (and experiencing more frustration) tomorrow.
Be Humble and Enthusiastic
We (most of us at least) spend way too much time at work to not have fun doing it. Enthusiasm and making things light goes a long way toward creating a culture that folks want to be a part of. I purposefully named meetings “parties” (which I totally stole from a good friend and product manager). I intentionally smile a lot in conversations (which people tend to mirror). I’m often self-deprecating in meetings. This serves the dual purpose of getting a laugh but also showing that I’m just another human doing my best. I offer direction to the team, but I’m happy to “defer to the experts” (i.e. the team) more times than not.
I’m just some dude that has gathered a lot of experience in 45 years. I’ve made a lot of mistakes, and I’ve learned from some really smart folks. I’m not the boss. I’m the guy that gets to help the team succeed by drawing on my experience.
Results
We’re about 6 weeks into the above formula with the team. The results have been positive:
- Projects are arriving on time with minimal defects. That’s not to say things are perfect. There have been speed bumps. But nobody’s freaking out.
- The last retro board was dominated by “continue” items and there were no “stop” items.
- We’re still collecting data on the new pointing system. It was the last change that we made. I know from experience that it works, but it will be interesting to see exactly how it pans out with this particular team.
- Ownership is trending up. The team is asking the right questions and making the right requests to make sure that the work they do is meaningful and impactful.
In the end, everything is an experiment. There will be modifications as we go. The goal will remain the same, though: A methodical approach that yields satisfied developers and satisfied customers.
