Have you ever been on a development team that just didn’t “click”? One where you knew something was wrong, but just couldn’t put your finger on it? Where you felt like you carried all the weight, or worse, felt disconnected and adrift?
As I’ve mentioned in previous articles, software quality is directly related to the quality of the team. It’s more than just the skills of the members; it’s really about the personalities of each person, and the environment in which the team operates. Sometimes the best way to figure out why a team isn’t working is to think of the best, most high-functioning teams we’ve been on. What stands out? What made those teams, or those projects, seem so good?
Here’s what comes to mind when I think of the most high-functioning teams I’ve been on:
Developer Freedom
On my most successful teams, we earned our management’s trust by how we worked and what we accomplished. Our estimates were reasonable, and sometimes conservative (the Scotty Principle) so we were usually able to deliver early, or at least on time. When problems arose, we raised them right away and proposed solutions at the same time. Since the company trusted that we would deliver what we promised, they adjusted some of their business plans around us – quite unusual, especially since this was a massive, multi-billion dollar company. When they did have to impose a deadline, they let us decide the scope of that release.
Having earned the company’s trust, we were able to devote time to things that often get squeezed out by time pressure – UI tests, architecture, training, etc. Management fully supported our efforts to improve quality and reliability. And when we were blocked by external factors (missing UX requirements, for example), we had the freedom – and support – to make decisions ourselves.
Scrum/Agile Habits
We understood the difference between “Doing Agile” vs. “Being Agile”. We didn’t just show up to the meetings because they were on our calendars – we valued those opportunities to communicate and make adjustments. We shared the same vision, and knew we all needed to work together and support each other to get there.
In terms of process, we were diligent about not wasting time. Scrums never lasted more than 15 minutes. Retros, demos, and planning never lasted more than an hour. Anyone was welcome to chime in when they thought the meetings were getting off-topic. If a meeting wasn’t going to be productive, it got canceled. We made sure that any non-coding time was worth it.
Attitude
We were all engaged and excited to learn from each other. Chat rooms were active, and people eagerly shared things they’d just discovered. New members could ramp up quickly because people were almost tripping over each other to help them. Questions were answered within minutes. We had iOS meetings twice each week that became so popular that other teams asked to join. It was commonplace to pair up to tackle a problem, and I never once felt like I was inconveniencing someone when I asked for help.
It’s good to learn from teams that have struggled, but it’s even more useful to remember what worked, and why it worked. If your current team is missing the mark, keep that high-functioning example front and center in your mind every day. Find constructive, positive ways to guide your team in the right direction. Every little nudge can have a huge impact.
Got any thoughts to share about your favorite high-functioning teams? I’d love to hear them!
——
Did you enjoy this article? You’ll find a lot more helpful entries in my blog. Be sure to download my free eBook, “Building a Career in Technology Leadership”, too!
Recent Comments