How to Build the Perfect Agile Development Team
I’d like to offer my thoughts on finding and hiring great people to build a great agile Dev team. Much, if not most of what I offer may not be new or transcendent, but finding and acquiring the
best available people is essential for composing a great Dev team.
When it comes to hiring, go for great. Two backup quarterbacks are not equivalent to one Tom Brady, nor do three Bs make an A in school. If you want a great team, hire great people. It’s that
Well, if it were that simple everyone would be doing it, and if everyone was doing it, there would inexorably be a shortage of great people, and we would have to choose between good people and OK
people and try to make them great. I don’t mean to wane philosophic, or overthink the concept, but hopefully, you get the drift. It is as simple as it is difficult to hire great people.
Going for Great
What makes a great Dev team member? Over my experience, I have boiled down an extensive list of qualifications to the following list of questions that are always in the back of my mind when each
candidate walks through the door. Mind you, I do not pose these questions to candidates, but I seek to determine their answers through the course of the interview. This list assumes any candidate
meets or is close to meeting the required technical skills to perform the job.
- Is the candidate a problem solver?
- Is the candidate willing to ask for help?
- Is the candidate able to communicate his or her ideas effectively?
- Is the candidate too binary, too cerebral or too technical?
- Is the candidate coachable?
- What personality strength or expertize is my current team in need of that this candidate can provide?
- Do the other team members get along with the candidate?
I can answer the first three questions on my list by asking just one question of the candidate. I will not provide my question, but I will provide an outline for that question at the end of this
article. You can use it as a framework to derive your own “telling” question.
The Humility to Ask for Help
The first and third questions I suppose are obvious, but I don’t find the second one as obvious: Is the candidate willing to ask for help?
Anyone who has written code for a few years knows you are going to get stuck or face problems for which you do not have the answers.
Admitting this quickly and seeking advice or help is an essential developer trait. If a candidate is afraid to ask questions or for help, they do not make the cut. I want more than a curious
person. I want someone who will not spin their wheels for days stuck on a problem that might otherwise have been solved more quickly with a little help.
With the fourth question (Is the candidate too binary, too cerebral or too technical?), I attempt to determine what the Vulcan-to-human ratio is for the candidate. Trust me that misdiagnosing this
character trait can have a substantial impact on your team. I have been with propeller-heads who do not eat well with others, are too literal to collaborate creatively with others, or whose only
sense of humor is at the expense of everyone but themselves.
Coachability Overcomes Incapacity
If a person is coachable, they can improve and grow. I will almost always take a coachable B candidate over an A know-it-all. It is often impossible or requires too much effort on a continual basis
to reason with an immovable know-it-all. Without exception, we all need to be told we are full of it when we are full of it.
When you are building an agile dev team, it doesn’t do to have a bunch of clones. In team sports, no team is successful when each player can only do what the other members do as well as the other
team members. Imagine a football team with all linemen or all quarterbacks on the offense? What a disaster that would be! The same goes for your team. Hire for strength. Hire someone who will
enhance and improve your team.
The Right Piece for Your Puzzle
During the interview process, I believe it is important for your team members to meet each candidate. They don’t necessarily have to interview them per se, but they do need to interact with them to
some degree so they can determine if the candidate will fit in and get along with everyone else.
In my experience, comradery and trust increase the productivity of Dev teams and lessens the strain caused by long evenings and short weekends that pile up as deadlines loom. Contention on top of
normal development pressure can cause your best and brightest to leave; this is too steep a price to pay.
So often I watch geeks use the interview process as a way for them to inflict a candidate with a line of questioning meant only to reveal the massive dimensions of the interviewer’s cranial cavity.
I know of software companies who have not hired qualified people because they came from the “wrong” school. If you want to build a great Dev team, leave snobbery and your ego at the door. Go for
great. Hire for strength.
Silos? We Don’t Need no Stinking Silos!
The best agile Dev teams I have been a part of were like Navy SEAL teams. There was a certain amount of shared knowledge about each other’s jobs, but we were all specialists in our area. This kind
of Dev team is organized cross-functionally meaning, that if possible, every tier of an application has a corresponding representative on the team.
I know this is not always possible or feasible, but if you can organize your team this way it pays a huge dividend. I have seen teams like this whose whole becomes greater than the sum of its
parts. It is inspiring. You may be able to find threads of continuity within the architecture of your applications that will allow you to organize Dev teams along these threads.
Many years ago I had a fantastic Dev team. My team was composed of a UX developer, a middleware developer, a backend developer, and believe it or not, a business analyst. We also had two part-time
team members: a QA tester and a database admin. The part-timers were not just a round-robin role; these were individuals assigned to our team and our team’s projects. We knew each other well and
sat close to each other.
Healthy Cross-Training for an Agile Dev Team
Cross-training happened organically within our team. For example, the UX developer learned SQL and the middleware developer learned Flash (I know I am dating myself a bit). The middleware developer
did not have the design eye the UX expert did, but when the UX person was on vacation or sick, the middleware person knew enough to maintain the UI and troubleshoot problems. The same was true if
the backend team member was out of the office. The UX expert could hold the fort down until our backend expert returned.
The business analyst never became technical enough to maintain code, but she did become quite good at troubleshooting problems – not to a technical level, but to a useful causality level. Our QA
tester eventually became a developer within our organization. Many years later our UX expert took the programming knowledge he gained with us to build an iPhone app when the devices first came
I know that cross-training is important, but I have been one who is inclined to follow the interests and inclinations of my team members. People are more apt to remember what they are interested in
than what they are not. I only forced the issue when I didn’t have appropriate coverage.
Having cross-functional Dev teams breaks down silos and organically encourages cross-training. Cross-functional teams expose all team members to the concerns, challenges, and constraints associated
with the roles that support all the tiers and environments of an application.
This, in turn, provides greater empathy and responsiveness from other SMEs on the team and outside the team. These kinds of teams humanize everyone. That person is no longer the @#$ %!@# on the
other side of a wall, email, or phone call. This individual has a name, personality, sense of humor, and he or she is accountable for a particular set of criteria, that you now understand, and you
now know how to speak to this person because you communicate with them (and their kind) all the time.
Team Building and Bonding
Numerous books are available on the subject of team building, building trust and so forth. Some businesses or camps exist to provide formal team building exercises. For me, team building and
bonding all boil down to three principles:
- It is important for everyone on a team to interact with each other on non-work related activities.
- Laughter is important, so find healthy ways and circumstances to encourage it.
- Respect people’s personal time.
I am not saying that attending some formal team-building boot camp is not useful, what I am saying is that you do not HAVE to attend one of these to build cohesiveness within your Dev team.
Sometimes it is the simplest things that provide the greatest value.
Pay for a group lunch at a nearby restaurant or park. Go bowling for lunch. Start the day with some kind of whimsical office Olympics (e.g. wastebasket basketball circuit around the office) or play
a smartphone social game (e.g. Ellen DeGeneres’s Heads Up!). Be creative and have fun!
A portfolio of such activities is valuable because not every activity is for everybody and every circumstance. For example, I have been with startups that have a ping-pong table, so obviously, we
played a lot of ping-pong, but not everyone liked playing ping-pong.
Mixing things up provides something for everyone. Additionally, the type of activity also allows you, as a manager or team lead, the ability to be spontaneous when stressful circumstances demand a
healthy distraction. Team building/bond does not, and in my humble opinion, should not always be formal. I have found that spontaneous activities can take a life of their own and can end up
building a cultural identity for your Dev team.
One last thing to consider when planning extracurricular group functions is to be respectful of your employees’ personal time. They may have spouses, children, pets and other responsibilities and
interests that demand their time and attention. The default should be not to hold these planned activities in the evenings or weekends unless you intend to involve/invite your employees’ families
Breaking the Routine
At one startup I worked for we organized a softball team to join a league and everyone had to participate. This was a bold and out-of-the-box idea. Not everyone played, but everyone had to take
part in some way. For example, the roles assumed by those not wanting to play were: t-shirt designer, team manager who was responsible for food and drinks at games, equipment manager, and social
media manager. Nearly everyone had a role, and everyone’s families attended the games.
It was surprisingly a lot of fun – free food and drinks helped too. Once a week we would hold a practice – during the work day – which contributed to breaking the monotony of the work week and
provided a healthy disengagement from fixating on problem-solving.
Speaking of disengagement, when I was younger and starting out in the software business I was on a team where our manager regularly took us all outside to play hacky sack. We all sucked, but that
simple activity required me to focus on hand-eye coordination which distracted my hyper focused mind from fixating on codifying the world. Some of my best ideas for solutions came to me when I sat
back down at my desk after playing hacky sack with my team. I learned a valuable lesson from that experience that I have applied throughout my career.
It should go without saying that one of the jobs of a manager or team lead is to insulate his or her team from upper management politics, rantings, and pressures. Another attribute of a good
manager is NOT to micromanage his or her people. I have told my team members that if I have to be consistently on top of them or micromanage them, then there is a problem.
I train, mentor and empower people and then trust them to get the job done and autonomously make decisions within the constraints their job/role. I have always felt that the job of a manager is to
not only protect people but to grow them. I want my employees to surpass me; I want them to become better than me. I want them to have career growth opportunities.
My interest in personal and career growth for my employees is also why I like to have Navy SEAL-style teams that are slightly diverse in skill and background. Not only is this kind of team more
productive, but I am also old enough now to see the long-term career impact this kind of team has had on its members many years later.
I have already mentioned how my QA tester transitioned into software development. This opportunity would likely not have been so easily afforded him if he were just part of a siloed QA team.
Participation in my team not only changed his career but obviously impacted his year-over-year W-2s as well.
Extra Resources Don’t Always Solve Problems
I cannot count the number of times I have had to explain why a deadline was going to slip and that adding more manpower was not the solution to keep on schedule. An axiom that has helped me help
management understand my constraints concerning the app-architecture-to-productive-developer ratio is this: nine women cannot make a baby in one month. It is what it is.
Application architecture determines the maximum number of productive developers. Just adding more people to a project will not ensure we meet a deadline. Even when you are understaffed on a
project, adding people late is as ineffective as adding too many people. One of your jobs as a manager is to help educate upper management to virtual ‘RPM’ limits of their software factory. I have
found once management understands the production cadence of your team, many tensions and frustrations go away.
One out-of-the-box idea that occurred once in my career has its obvious downside and risk, but it did work out for me. I remember a critical deadline approached. A particular VP was frustrated with
my team. I can no longer remember why that VP joined our team on our sprint to the finish. Did I have a stroke of genius or stupidity? Did the VP insist? Who knows; what I do remember is the
apprehension I felt at the beginning of this two-week period and how the demeanor of that VP changed during that time.
As he watched us work together, panic together and lose sleep together, he came to appreciate the intensity of the drama that unfolded before him. To me, he seemed to be watching the closing
minutes of a basketball game whose outcome can go either way. Like most fans, he was unaware of or misunderstood many of the finer details taking place before him. However, he fully comprehended
the pressure, the effort and real drama that unfolded as we climatically met the deadline. We won the game with a last second buzzer beater.
This VP shared our highs and our momentary despair. In the end, he became our biggest advocate and champion. He became vested much the same way fans do for the favorite sports teams. From that
point forward we were his Mission Impossible team. He took great pride in “his” er, my team.
The One Question
Ok, so what is that one question I ask candidates that provides me with so much insight into a candidate? Like I said I will not divulge the question because as soon as I do, people will game the
system and my question can become inept which will force me to devise a new one. Granted there probably is a better question I can ask. I would love to learn what questions any readers create
(please tell me in the comments section!).
My question to a candidate is a logic problem. I tell them that they can ask me (or us) any questions. I request that they solve the problem on a whiteboard and that they explain their solution to
me/us. Here is what I am looking for:
I am looking for someone who is willing to ask questions and even state that they do not remember XYZ concept. I do not care whether or not they understand the premise as much as I care that they
can solve the problem once they know what the problem is and that they ask questions. I want to hire people who are willing to ask for help when they are stuck.
I am looking for someone to can break down the problem into pseudo code or a logical outline and can effectively communicate their ideas to others. Perhaps you will want a candidate to provide
their answer in the code language they will be writing. I have always let the candidate draw the solution in whatever markup they are comfortable – this is an interview, they are nervous, and I
want them as comfortable as possible, so I have a small chance at talking to the “real” them.
I am not necessarily looking for the candidate to demonstrate the most efficient way to solve this problem, however, depending on your needs this may be a necessary qualification to add. I am
looking to hire good problem solvers and communicators. If a candidate cannot effectively convey their solution to me then hiring this candidate can introduce an inhibitor to collaboration in my
If I’ve missed a vital quality you look for when building your own DevOps culture, feel free to tell me below.