This post serves as a living collection of ideas. Some ideas, I agree with. I bring up these ideas in meetings and advocate for them, but I understand if a decision gets made the other way. The ideas I’m talking about in this post have grown far beyond that point. I believe the ideas below are so crucially important to the success of a software development team that fighting for them daily is an obligation. These are ideas I champion.
Fail Early and Often
Teams can’t avoid trying new things because they’re afraid they might not work – it’s a philosophy that directly causes stagnation and stifles innovation. By making it OK to fail and by realizing that lessons learned from failure actively improve future work, teams can be opened up to creative and iterative change.
Spread the Knowledge Around
Siloing developers based on their perceived strengths and weaknesses is a terrible idea. The more I know about what my teammates are doing, the better I can do my job and integrate with theirs. Modern practices like code reviews, pair programming and lunch and learns help break up organizational silos and encourage teammates to obtain a wider view of the big picture.
Having everyone know something about everything is great, but there is unmistakable value in having each person know a lot about one thing. Asking teammates to focus part of their time on small areas of knowledge that are critical to the team’s success means that each person feels ownership and responsibility over being an expert in their chosen field.
Iterate, Analyze, Change
Performing clearly-defined work in time-boxed increments, then empirically examining the outcome of that work and improving the process for the next increment is something that is fundamental to software development. The fact is, we as developers are not great at estimating more than a few weeks into the future. By building in constant re-evaluation we can make sure our plans are constantly in sync with reality. Scrum and Kanban are excellent tools developed through years of iteration, analysis and change that give teams a great starting framework for implementing this idea.
Don’t Go Backwards
Once a team has completed an iteration of clearly-defined work, the “done” status of that work should not change. If “done” work can suddenly become “undone”, then the entire understanding of what it means to be “done” is put in jeopardy. There is no way I know of to pin down done-ness other than writing good tests around the agreed-upon functionality. By continuously running those tests while adding new features, teams can guarantee their work stays done. The plethora of reasons testing is great could fill an entire post, which I intend to write at a later date.
Build Your Team Right
Hiring and firing are the two most critical actions of building a great team. We’ve all seen the impact one person can make on a team’s success, both positively and negatively. Taking the extra time to hire and fire right is the most face-slappingly obvious thing I’ve seen many teams gloss over.
Always be Hiring
In software development, the market is always tight. Talented developers are rare, and it can take a very long time to find someone when they’re needed. To counteract this effect, always be hiring. Have job descriptions for critical positions listed at all times, even when you don’t plan on hiring someone soon. This practice ensures you’ll always have the best chance of finding talent, with the worst-case scenario being that a good candidate doesn’t get hired. The cost of hiring the right person is minuscule compared to the potential loss of mis-hiring.
Communicate Reasons for Firing
When someone isn’t working well with your team, covertly letting them go under the veil of darkness sends a message that anyone could be next. Instead, openly communicate exactly why that person isn’t working out and make sure teammates understand that the team’s values are at stake if the person were to stay on. By getting buy-in from teammates on someone who isn’t working out, you can strengthen your core values and build trust with those who are doing a great job.
This is a cliché saying, but no one can avoid the fact that teams who work together and communicate openly will always out-perform teams that don’t. I recommend The 5 Dysfunctions of a Team as a resource for anyone who is interested in understanding how to drive healthy collaboration in their own team.
Nothing bolsters a culture of innovation quite like hosting regular events that encourage everyone to make their ideas a reality. Everyone at your company has great ideas (that’s why you hired them!), and spending a few days exploring those ideas tends to result in an explosion of creativity and benefit to the company as a whole. Here’s how I like to run these events:
- People bring their own ideas, which must relate to the success of the company. Teams should be kept small.
- Teams work on their ideas for somewhere between one and three days.
- On the final day, there is a demo where teams present their work to a panel of judges who have been selected from across the company.
- The winning team receives fabulous prizes and a small trophy.
These rules allow for a time-restricted, open-ended sandbox for everyone to implement their own ideas while still being asked to think about the impact of those ideas on the company as a whole. In addition, the team size restriction means people of varying specialties are more likely to work together (see: Spread the Knowledge Around).
Making a documented set of standards for your team, be it for code styles, minimum test coverage, or something as simple as how decisions are communicated, helps bring your team together and make goals more clear. Newer teammates will use the standards to get up to speed quicker. The important thing to keep in mind is that standards are living – they must be adaptable according to the iterate/analyze/change cycle. When standards become stale teammates start to ignore them. Keep standards relevant and up-to-date.