With everything we’ve done wrong, if we ever want to do software development right, we need a plan. First, a review.
With what we know, we stipulate the following:
- We’ve been doing it all wrong for longer than most in the industry have been alive
- Management has failed to fit the square developer peg into the round manufacturing hole
- Software Developers must possess a wide range of innovative and leadership traits or at least have the potential
- Software Developers must self-organize
- An outcome is the product; software is not the product
According to a conference paper by the Project Management Institute in 2010:
The competency level of the least competent project participant is the best predicting variable for project success; it is the weakest link in the project chain.
Although it explains only 3.82% of the variance in project success, improving any other variable represented in this study will only increase the project cost, it will not lead to greater success. [emphasis mine]
:: Berger, M.E., 2010
Berger, M. E. (2010). Contribution of individual project participant competencies to project success. Paper presented at PMI® Research Conference: Defining the Future of Project Management, Washington, DC. Newtown Square, PA: Project Management Institute.
Project managers will debate the best methodology, frameworks, tracking software, ceremonies, and all other manner of religious fervor. But the least competent person in the software development group will have the greatest effect on likelihood of success.
And remember: we must define success as outcome not output. When software success depends on an almost-ethereal measure, people become the most important investment.
Berger studied the effect of competency on project success. And if the experiences of the icons of the Agile Manifesto mean anything, Individuals and Interactions over Processes and Tools. Obviously Kent Beck and Ward Cunningham thought that individuals were important enough to take “top spot” on the manifesto. Let’s interpret that as meaningful.
We’ve devised a way to eliminate a lot of very good people before they even show their faces. They don’t fit our contorted view of software developers (meek, mild, and wearing Superman capes underneath their Monster Energy drink t-shirts), so we reject them before we know their skills.
Given two data points – the individual is important, and, the weakest link becomes the greatest predictor of success or failure – a series of studies about traffic safety provide some food for thought about software developer safety:
- Those driving just ten miles slower than the rest of traffic are six times more likely to be involved in an accident.
- Regardless of the speed limit, drivers go their own speed limit – what they feel is safe.
- When it comes to automobile accidents, the difference in speed causes more accidents than just going fast itself.
We should consider this analog very carefully; taking from it only indicators, not facts. Still, personal experience about assembled groups of differently-skilled developers lends some veneer of truth were we to apply these considerations to assemblies of software development groups.
So It’s Settled
So it’s settled: We only assembly groups of equally-highly-skilled, senior developers (the fastest drivers) if we want our projects to succeed.
Two huge impediments stand in the way of that policy:
- The CFO won’t pay for it, and
- We can’t even find enough average developers to staff all our projects
Now, there’s nothing wrong with average developers. (When you look at the bell curve, most developers are average.) But every team needs a star, don’t they?
Well, not really, but every team needs a senior developer (at least one) and a leader (at least one) and all of the developers must be motivated and have the best environment and support available.
Now we have three, interrelated-yet-separate pressures on software developers:
| Agile Manifesto | Motivated developers who have support and the best environments |
| Berger | The least-skilled developer sets the pace and likelihood of success |
| National Traffic Safety Administration | Differences in skill (speed) cause more accidents than if everyone is skilled (fast) or not (slow) |
Well, Here’s Another Fine Mess You’ve Gotten Us Into
These seem like an impossible set of criteria for any group of software developers. Yet, other groups have tackled similar issues and have learned methods of addressing each. The military remains the most successful of all, so let’s put down our animosity for the military and seriously consider the best of the best, sir: elite forces.
Right off the start, we must admit that we cannot flunk two thirds of the candidates who apply for software development positions. But wait! We do, don’t we. We have adapted highly-contorted systems of recruiting, interviewing, and hiring that would chase off all but the most adamant candidates.
Disqualifiers don’t include lack of skill, lack of experience, or even previous failures.
Well done! We’ve devised a way to eliminate a lot of very good people before they even show their faces. They don’t fit our contorted view of software developers (meek, mild, and wearing Superman capes underneath their Monster Energy drink t-shirts), so we reject them before we know their skills. Well done, HR. Well done, hiring managers. Let’s fix that, too.
From the start, then, let’s agree to look for talent along with experience and skill. So let’s define an ideal group of software developers first. We can look to elite military teams for some guidance on that, first. No analog to the software world will be made just yet. Don’t jump the gun. (Military pun.)
Simply put, elite forces may have between four and eight members in each operational unit. (This doesn’t count “Command,” who don’t fight/develop.) An experienced officer leads each operational unit. A senior enlisted provides direction and guidance to the officer. Other members of the unit will cascade in rank and experience down to the “trained-but-inexperienced” member.
Let’s Define Experience
Nobody in an operational unit has experience until they’ve had experience with that particular operational unit. A seven-star GenerAdmiral could fall out of heaven with gold armor and the unit would look at each other with the knowing groan, “NOOB.”
Elite teams consider all needs and inadequacies a whole-unit problem; not just of the individual.
Experience means trust. Everyone earns trust one person at a time; one decision at a time; one deliverable at a time. Nobody cares how your previous manager thought of you. When a new member arrives to an operational unit the first steps determine 1) where is the NOOB in terms of skill, 2) does the NOOB have the temperament to fit in with the rest (humility, adaptability, respectfulness, tenacity, and dependability), and 3) in addition to the unit’s ability to train the NOOB, does the NOOB bring anything to the unit that makes them better than they already are without him?
Disqualifiers don’t include lack of skill, lack of experience, or even previous failures. This establishes the first of the ways a software development team, mimicking the military elite, can provide one of the most important facets of a supportive environment: emotional security.
Elite teams consider all needs and inadequacies a whole-unit problem; not just of the individual.
Skills come from training. Experience comes from using that training. If the NOOB has the qualities proven to make them good pupils and teachers (and good leaders in their particular form of leadership), then they make good unit members. Skill will grow. Experience will naturally happen.
How Do We Make That Happen?
Remember? People become the most important investment? Yeah. Here’s the catch. Senior administration officers (managers) who want the best people invest in people: in their training, in their drill, and in their self-and-unit assessments. Unlike the rest of the world, though, these elite units bond in training, drill, and self-assessment. One failure is a unit failure. One success is a unit success. When one needs training, all need training. When one drills, all drill.
Training, drill, and assessment must happen All. The. Time.
This is not boot camp where the unfit get weaned. This is not school where the professor judges by the grade. This is life where the outcome (remember why we’re in this?) is the measure of success or failure.
The elite units would call this “the mission.” The mission is the only measure of success. Will there be heroic feats? There always are. Will there be setbacks? There always are. But before we assign medals or blame, the mission must succeed. That means the unit must succeed. That means cohesiveness, dependability, diligence, and trust bind every member of the unit to the other.
Interpretations, Please
Gratefully, software developers don’t have to dodge snipers and roadside explosives; just their trivial equivalents in the project. They don’t have to deal with bad commanders; just bad managers. But “the mission” must remain the goal: delivering the outcome desired by the client or customer.
Training, drill, and assessment must happen All. The. Time. This includes training in the business or technical domain in which the unit will work. If the topic is sales and marketing, some sales and marketing training will advance the outcome more than most will imagine. If the topic is OAuth2.0, then identity and third-party auth make great training or refreshers.
Even when the topic is REST or SQL queries, some training improves the entire unit’s chances of “completing the mission.” That could mean nothing more than five minutes of some online training, but training must occur constantly.
Then there’s drill. Drill differs from training because it refreshes, improves, or reminds about something the unit already understands (or used to). Drill in software development often comes in KATA, but it can also come in refactoring, and TDD. Drill should be done in pairs or with the whole unit.
In We Were Soldiers Once: And Young, Colonel Moore addresses all his young officers and says, “I hope you like to train. I love it!” That should be the attitude of every software developer in a successful unit. And that should extend to drill. Doing the same thing over and over turns it into muscle (brain muscle in the developer’s case) memory.
I hope you love to train… and drill. I love it and so do all the successful software development units.
Previous: Training Schedules