When A Software Team Encounters Puberty

Guest post by Vincent P. North

At first, childhood is fairly simple and fairly fun. You play a lot with your friends, endure grade school, and more or less enjoy yourself. Until about age twelve. Suddenly your own body kicks into high-gear "growing up," and persons of the opposite gender suddenly become a lot more interesting.

Blissful Childhood:

Many software teams are in a state of "childhood" for a long time – sometimes forever. They're a small group of people, each one singularly responsible for one project that no one else ever works on. Whether it's a new feature or fixing a problem report, "he" does it all – identifying the change that needs to be made, or creating the design in his head. Then, he carries it out, maybe tests it, and deploys it. When the end-users find the next bug, the cycle repeats.

Many small and moderately-sized IT operations thrive on such a situation, for as long as it may last. The "managers" in such situations really don't have to manage anything – they just supervise while the work goes on around them. They represent the department at higher-level meetings, but consciously or unconsciously mostly try to preserve what is to them a very comfortable status quo. As long as the workload doesn't increase too much and as long as the clients are internal, the teams can remain "at age ten" forever.

Then Suddenly ... Puberty:

Human puberty is accompanied by a growth spurt, and this is usually what finally happens to our happy young software team. It might be the addition of an external customer, with the hard contractual obligations and expectations that go with it. It might be a requirement to work with another, larger team. It might simply be adding a project of greater complexity – or, just too many projects to enable the young "lone wolves" to continue to "own" one project by themselves.

The team always finds this disruption very uncomfortable. Some of the members will quickly leave – further complicating the situation since they take all of their accumulated know-how about the system which they "owned" when they walk out the door. The team that remains will have to grow up very fast, acquiring new skills and being forced to accept a new form of organization – which might well be described as "becoming organized for the very first time."

This is the point at which project management becomes necessary. The work must be planned-for, turned into discrete units of work that actually can be divided among multiple individuals, and accompanied by actual, enforced procedures for feature testing, regression testing, and deployment. Team members no longer have the luxury of working only on one single project, nor of "owning" any of them. They must take direction from others with whom they may agree or disagree. They must develop the ability to accurately scope and assess a new unit of work without "making it up as they go along." For lone wolves, all of this is an unfamiliar and disruptive experience.

There are many project management theories which might be bantered-about at this point, as both the team and its no-longer supervisor figure out how to organize a "post-puberty" configuration. "Scrum" and "Agile" are two that are certainly en vogue these days, but there are many others.

Tempting Traps #1: "Organization for the Sake of Organization"

The first temptation faced by such a team is to grab a convenient "Manifesto" from the shelf and to try to implement it religiously, as though it actually were the cookbook that it might make itself out to be. "Just do what we say, exactly as we say it, and your problems will disappear." If only it were that simple. But, the team plunges ahead, and soon finds itself mired in "analysis paralysis," focusing more on the newly-adopted process than the work that is to be accomplished.

Furthermore, after a little bit of time the team tries to revert back to its original comfort-zone. The new methodologies are adopted "in name only," while certain team members quietly try to "own" this-or-that part and to, as they are accustomed, "do all of it themselves." The amount of formal planning and communication, the amount of "design in advance of implementation," quietly decreases. Even though the team continues to stand in front of a white-board, coffee cups in hand, pushing yellow sticky-notes around.

Tempting Trap #2: "Self-Directed Teams"

In addition to this "compartmentalization" within the team, adolescent software groups will try to compartmentalize the team away from all outside management influences, describing themselves as a "self-directed team." Unsurprisingly, there are software-management manifestos that specifically condone this practice.

What actually occurs, though, is "lone wolves, in a pack." The teams promptly merge the task of figuring out what to do next with the task of actually doing it. They tend to work in short, overlapping cycles and to look no farther ahead than the next cycle. Such a team is frequently "surprised" by a new complication that no one looked far enough ahead (or, widely enough) to properly anticipate. Schedules slip, and the scrap rate is high.

What Do I Mean By "Scrap Rate" And Why Does It Matter So?

In manufacturing parlance, "scrap" is anything that you manufactured that you can't sell. It may be defective, improperly machined, or, as in this case, improperly designed. You put materials and labor into it that you cannot then profitably get out of it. To an accountant, it is a sunk cost.

In software manufacturing, then, "scrap" is any source code that you added to the system, intending it to be a part of the finished software machine, that you later had to remove, re-work, or redesign. 100% of the labor cost of this component is sunk – but, it gets worse.

Computer software really is "a machine of staggering internal complexity." It consists of thousands or millions of "moving parts," all of which potentially interact freely with one another. It's an infinitely complex Jenga game. Every time you have to remove something that has been added and rework it or replace it, this has the potential of de-stabilizing something else, anywhere in the structure. Including something that someone overlooked. This is one reason why defects can remain hidden for years.

The Need for Multi-Level Project Management in Software Teams:

Activities within a software production pipeline must occur at many different levels at the same time. On the most micro level, software developers must focus myopically on the exact function, procedure, or query that they are writing "right now." On a slightly higher level, the team must focus on a small number of tasks that it has collectively committed to completing, say, "this week," shepherding each one through an organized but short-term process of design, implementation, unit testing, and merging. But more levels are needed beyond this.

"There must be a navigator on the bridge." Someone who is taking a longer-term view from a higher perspective. The one who knows where the rocks might be and how to look for them. The one who is considering technical alternatives and technical implications "well in advance." This role must be supported by others who draw the actual lines upon the charts, communicating the next steps to the appropriate team(s) at the appropriate time.

"There must be a team representative representing a single point of contact between the team and the enterprise." This role has been called by many names, the most common being "Project Owner." This is the person who is working with the stakeholders who are external to the team, ensuring that the navigator has up-to-date information about where the project needs to go and when it is expected to be there. This person also communicates project status to those stakeholders.

"There must be a development cycle." A formal process that each completed unit of work is subjected to after the teams believe they have completed them. These are the QA analysts, the documenters, and the persons responsible for deployment. A well-defined process must exist for identifying defects in the work, both to identify them for proper repair, and to quantify them since these, too, are "sunk costs."

"There must be those who don't 'look at their feet,' alongside those who necessarily must." A software developer spends a lot of time looking myopically at one-or-three pages of source code while writing it. When searching for the solution to a "bug," that developer's attention is 100% focused on a step-by-step workthrough. Such people cannot be looking up to see "the bigger picture." They have to be looking at their feet so they don't trip and fall. Therefore, others must be looking around. At the lowest level, these roles might be called "team leaders." But quality-assurance and integration testers must be taking a larger view, usually regarding the completed software units as a black box.

Employee Retention and "Teaching the Benefits of Adulthood":

When a small, "lone wolf" organization is forced to begin to grow up, some of the "lone wolves" will leave, because they prefer to remain as they are. But there are others who thrive only in larger organizations where the work is shared and the roles are more formalized. Many of these people "graduated" from former careers as lone wolves, and they have tales to tell. (Most of the people I've talked to have quickly said that "they'd never go back.")

It is very important to emphasize to every member of a team that is "going through puberty" what the new organizational structure will be and why it is actually "better ... much better." A lone wolf shoulders the entire burden of his task, all the time, and directly faces the consequences of his slightest mistakes ... often directly in front of the internal customer, unless his supervisor (not "manager") is willing to shield for him, which they usually aren't. Every lone wolf has had the experience of leading himself or being led "down a primrose path" only to be obliged to retract his steps under usually very-disadvantageous circumstances. Every lone wolf has woken up at 2:00 AM, staring at the pager, having dreamed that it just went off again.

A well thought-out software management plan improves this situation by creating "many hands make light work" in an actually-meaningful way. Construction of the software machine now becomes more of an assembly-line, with more than one pair of eyes looking at short- and long-term plans, contributing to the actual execution of the work, and looking for problems, defects and omissions. The inexorable pressure is still there, but now it is born by more than one person in a process that actually works to the mutual benefit of everyone.

My E-Book: "Managing the Mechanism"

Thoughts similar to the ones I've given here can be found in my e-book, Managing the Mechanism, which is available both at Amazon (Kindle) and in Apple Books at nominal cost. The premise of the book is that "computer software is an autonomous machine" of great complexity, which does everything that it is tasked to do without any possibility of direct involvement by the team that built it. They're in the locker room while the robot plays the game.