User Stories are Temporary

It's obvious, but warrants mention: What we do in the future is likely to be different from what we're doing today. The implications for user stories should be obvious: User stories are temporary. Saving them for posterity doesn't serve the primary purpose of user stories, and doing anything that makes them less temporary can turn user stories from benefit to detriment.

User stories are a bit of semi-refined raw material that systems are created from. They're a way to represent users' needs. Most importantly, they communicate an understanding of users' context to the people who are building the software. User stories help to make it more difficult for software development teams to succumb to the ever-present threat of losing track of the user's bigger picture.

Aside from raw human ideas that user stories represent, they are the most flexible artifact in software development. Then can be created at any time. They can be changed at will. They can be combined. They can be subdivided. They're not intended to become fixed, and anything that serves to make them fixed is a disservice to the value they offer. User stories aren't fixed in a point in time, just as needs aren't fixed. They change because conditions change. They change because our own understandings change and improve as we gain the clarity that comes from working with user stories, and from building the products that satisfy needs.

When we realize new clarity, our responsibility is to reflect that new clarity in the form of new stories, or new subdivisions of existing user stories, or through the combination of existing user stories, and even from the removal of user stories from the product definition entirely.

The user stories that describe our needs tomorrow are going to be different from today's. Knowing this as we do, we have we gone from recognizing the transient, temporary nature of user stories to the point where we now tend to capture them in tools that make them harder and to change, and harder to take in at a glance and to glean new clarity from. When we do this, we're increasingly unlikely to update user stories to reflect the improved understand we cultivate as we work with them, with users, and with the software that we're developing.

The more that we calcify user stories in ever more concrete media, the less we make necessary course corrections along the way. There is little that so obviously contradicts "Agile" more than inviting anything that adds to the calcification of requirements. A principle duty of user story management in Agile development is to protect them from becoming encumbered by the notions of permanence that obstructed software development methodologies that predate the effectiveness of Agile methods.

We pat ourselves on the back for having evolved beyond the quintessentially-primitive "300-page requirements document", but often all we're doing is bringing some of the same old problems forward to our "new" requirements formats. Sure, we've outgrown the massive, big-batch requirements doc, but the genetic material of the disease that infected those documents have evolved into a newer problem for newer artifacts, and ultimately, the problem is still the same essential problem. We're so pleased with ourselves for our new Agile ways that we fail to see that we're repeating the same mistakes, except with new material.

Here are some things to keep in mind that can help with the relapse into the same old mistakes:

1. When you forget why you're doing something the way you do, the answer isn't in a user story archive. The answer is in revisiting what you're doing to make sure that it still holds true. Do this with interactions and with people. Use tools and processes to support the human interactions.

2. User stories are not artifacts for regulatory compliance. User stories are a scratch pad of human understanding at the present moment. They are chuck for the software development grinder. What comes out the other end should be the software that itself explains why things are as they are. If you need a permanent record for the purposes of regulatory compliance, go ahead and create one. Nothing in Agile stops you from doing that. Just don't hang a stasis anchor around the neck of user stories. If you do, you'll strip them of the benefit that they bring to software delivery.

3. Have one master copy of a user story while that user story is in-progress. The master copy should be the one that is most immediately accessible to the most people who are involved in turning ideas into software products. They should be be posted using the most visible medium possible - one that requires the least amount of human interaction to casually-scan a project's gallery of user stories.

4. Throw user stories away once you deliver the working software that addresses the needs expressed by user stories. The software and its supports are enough to describe why it is the way it is. If you no longer remember, and if the software and its supports and the mechanisms and practices of institutional memory aren't sufficiently self-descriptive, revisit all of these issues as an opportunity to improve the production system in a way that doesn't invite more tool-centric bureaucracy.

Here's a bit of a side note to consider: The principle sponsors of the Agile 2010 conference are both "Agile" tool vendors.

If one of Agile development's primary tenants is to value people and interactions over processes and tools, how is it that the only Agile organizations producing enough disposable income to support Agile development itself are tool and process companies specializing in Agile requirements management and requirements compliance? Somehow, we've walked in a circle - yet again. And one of the things we've left on the trail behind us is the understanding of how things went wrong last time, as well as our commitment to avoid expediencies that don't serve sustainability.

The process methodologies that predate Agile are often roundly dismissed by agilists. But there wasn't really inherently wrong with them. Things back then started getting silly when tools started getting silly; when we began to defer to tools as authorities rather than to the people needing and the people solving needs.

One of the first definitive steps into the downward spiral of mindless process bureaucracy hell is the calcification of requirements. And no matter how temping it is to succumb to the materialism of hardened collections of user stories, we don't get to hell without passing through those gates.

---

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Workplace Safety for Software Developers

Software development managers make sure that their workers' physical safety is secured - assuring that office ergonomics are up-to-spec, and in compliance with the prevailing laws and regulations. On the other hand, managers verily require that software development workers undertake some of the riskiest behavior in the contemporary workplace. It's entirely common that software managers require workers to undertake work the crosses the line of being merely questionable, and moves squarely into the territory of negligence. It's not because software development managers are nefarious, but because they are too-often far enough removed from the work of software development to differentiate negligent and hazardous decisions from safe and sound decisions.

Without a tangible understanding of the work undertaken by software workers on a day-to-day basis, and an understanding of that work in great detail, software managers are not equipped to know when they are requiring software workers to supplant safety with expediency.

Workplace safety is an issue of productivity. Lack of safety breeds low productivity. In the case of software development, "safety" is an issue of undertaking work in a fashion that doesn't expose the software worker to unnecessary risk - especially risk that is easily avoided. That is, it's easily avoided for someone who understands the work of software development at a high-enough level of expertise and detail to guide workers away from unsafe practices.


An unsafe practice in software development is any work done in the present moment that makes work in the next moment take longer to complete. A reasonable analogy for this is the notion in physical materials work of a clean workplace.

The purpose of a clean workplace is to remove the clutter that hides unseen, unsafe conditions. It's a lot easier to trip over an errant piece of material in the workplace when its surrounded by a profusion of other errant materials. When hazards are so common that they blend into the background, we simply stop noticing them, and this is how we come to be put at greater risk.

The more unsafe clutter we have in our workplace, the more we have to work around. The more we have to work around, the more time it takes us to do work.

If a manager can't detect the conditions that makes work take longer to accomplish than expected, he doesn't adjust his expectations for cycle time accordingly. This means that he expects more to get done - the original work, plus the workaround work - in an amount of time that would be reasonable for the completion of the original work alone.

This makes workers even more careless, exacerbating the accumulation of obstructions and hazards in the software development workplace as a result. It's a vicious cycle that usually only happens because someone with the authority to avoid problems in the first place doesn't have the experience to recognize the problems and to deal with them.

In the words of the ancient Chinese workflow master, Lao Tzu: "Confront the difficult while it is still easy. Accomplish the great task by a series of small acts."

Although, you can only do those small tasks if you can detect their presence. The finer your ability to perceive counter-productive deviations, the quicker you can respond to them. The longer you wait, the further off-course you'll be when you finally realize that you need to make a course correction. Someone who doesn't do work can't recognize when that work is off-course. Someone who isn't an expert in the work can recognize when the work is off-course, but his will only recognize it after it has become more expensive to deal with than necessary.

And this, as the average software worker would tell you, is the day-to-day conditions in which their work is done. Software work is a constant battle fought against the accumulation of hazardous clutter. Software workers rarely get ahead of the clutter curve, and have to invest significant effort to keep their workplace free of hazards. Paraphrasing Taiichi Ohno, if you're not moving forward, you're falling behind.

Each individual scrap of hazardous material in software development is typically quite small - small enough in fact to be easily deemed negligible - even by people who do the work. The hazard presented by two iota of hazardous waste in software isn't the sum of the hazards - it's the sum of the hazards compounded by some multiplier. Hazards in software don't exist in isolation, they interact with each other creating a higher order of hazards that is greater than the sum of their parts. Two pieces of hazardous software that interact with each other don't create two hazards, they create two hazards compounded by the amount of interactions between these modules. To make matters worse, all modules that interact with hazardous modules in close adjacency also get infected. Lack of day-to-day expertise in software work often leads to negligent underestimation of the risks associated with the "design hernias".

Software hazards compound very quickly. It's very easy to arrive at an explosive accumulation of hazardous software materials. It can happen within the first few days of a software project. If subtle hazards in the tools and frameworks that programmers are slated to use are not recognized immediately, the accumulation begins before the first line of code is even written.


When we ask software workers to continue to work in such conditions, we might as well send them into a mine filled with coal dust and require them to hyperventilate for several hours each day. Sooner or later they are going to have to escape the job to escape the hazards, or they are going to acquiesce to the irreconcilable differences between a manager's expectations and the realities of the working conditions that the manager himself feels entitled to not be exposed to for having already "paid his dues". This creates dispassionate cynicism in software developers. They come to learn that no matter what they do until they escape the work, they are more than likely going to end up on the losing end of the software work proposition. They learn that they'll get hung with the detritus of negligent software development decisions and direction because decision makers are too far removed from the work to see that it is these critical decisions and directions (or the lack thereof) that are the root cause.

In these working conditions, workers constantly face obstructions that are only in-place because they weren't recognized when they were mere seeds of problems rather than towering oaks of looming counter-productivity.

The accretions of hazards into founts of the depressed productivity that is status quo for most software teams is fully and completely avoidable - if only the hazards are dealt with when they are small. To see looming hazards when they're small, you have to have detailed knowledge of the work in the here and now. This is simply not possible when managers have removed themselves from the work.

It's far too common for software development managers to feel entitled to be removed from the work of software development - as if removal from the work is a reward for having done the work for a number of years. The reward for doing software development work for a number of years is not an escape from the work, but an immersion into a far deeper understanding of it so that its expert insight can guide software work away from hazards. Of all the escapes that can be orchestrated by software workers, an escape into management is indeed and in fact an act of pure negligence.

Software work is works in intangibles. Software hazards go unnoticed because they are physically invisible. Taking a bit of liberty with Donald Reinertsen in The Principles of Product Development Flow, we don't see the manifestation of software development safety issues "when we walk through the engineering department." They're "bits on a hard drive, and we have very big hard drives in product development."

Managers often try to compensate for their lack of detailed understanding through the use of summary representations like software diagrams. But software diagrams don't show the looming problems while they are still small; still manageable gathering storms that can be dissipated through judicious application of minimally-invasive countermeasures. Only flagrant hazards can be detected in summary representations. Small, detailed course corrections can't be plotted from coarse, summary information. And yet managers who feel entitled to be removed from the work perpetuate the fantasy that summary representations like diagrams are sufficient to bring their purview into action on the software projects they manage. This is pure folly, and software tool vendors are quite happy to continue to exploit it.

By the time you've detected a software hazard that can be seen in a summary representation like a software diagram, you're looking at a problem that has festered for far too long. You should be able to detect the chemical markers of the disease long before you notice that lump in a vital organ.

Programming work is almost entirely mental. Its effectiveness is influenced by psychology, cognition, awareness, and communication far more than by any material concern like ergonomics, an ultra-fast workstation, or multiple monitors. Software systems are far too large and far too complex to be held in entirety in the conscious focus of any single software worker in any single moment. The devil is always in the details. Summary representations are secondary to the actual raw materials of software: the code. You have to be in the code, and to know enough about code to understand which subtle design differences are looming problems and which aren't.


The average software system is a dark coal mine filled with the poison particulate of tomorrow's case of black lung. We ask developers to work in these conditions every day. We do this because at some point in our careers as managers, we believed that we were entitled to be removed from the details of software work.

Sooner or later, enough hazardous software material accretes in a software system that managers step in, and often the first thing they do is look for a root cause in the workmanship of the software workers. The workmanship is rarely the root cause. The absence of informed, skilled, and insightful software management and guidance is always a preeminent cause to unattended workmanship. The workmanship is, of course, a problem, but it's a side-effect.

This is like blaming miners for an underground explosion due to the accumulation of day-to-day hazards that result from institutionalized negligence of clear and present dangers that should be managed the moment that they show their first signs. We ask workers to undertake work that they know is not in their best interest. We ask them to do this from our organizational perches far about the hazardous conditions of software projects. And then we hang them with the inevitable costs of this kind of mismanagement.

It's the software worker that is required to spend extra time in the mine to balance productivity that is lost to management negligence. It's the software worker who is required to take on the duties on sanitizing data by hand without the safety of the proven automation that should have been built right to begin with. We ask them to validate the decisions that we've made about the tools that they'll use in their work based on little more than a compelling sales pitch from a tool vendor who claims to knows more about the day-to-day work of the software developers in our organizations than we do - vendors who are even further removed from the work than we are.

We ask software developers to work against their own interests and the interest of our organizations because we don't understand the hazards that our decisions create.

Software workers suffer disruptions to their lives and their livelihoods when this kind of institutionalized negligence drives work policy on software projects. They shoulder the accumulated detritus of uninformed and unskilled management decisions. And they suffer the humiliation of blame when lack of management insight can't see it's own reflection in the root cause mirror. And institutions lose the invaluable institutional knowledge when workers escape the organization altogether. It's always a no-win situation. Everyone loses. And it's completely avoidable.

If you're not willing to be in the day-to-day work of software development, you're declaring loud and clear that you're not qualifying yourself for the authority to make decisions that direct software work. Every decision you make risks adding to the accumulation of software hazards. When you do this, you deplete the workplace safety for software workers. You ask them to take risks that the workers themselves know that you can't see, and they know that because you can't see them, that you will likely not understand that the accumulation of avoidable hazards into full-fledged, clear and present dangers is your fault to begin with.

Workplace safety is a serious productivity issue. It's a serious issue for the health of workers. It's a basic expression of human respect for the people who work for software development organizations. Understanding workplace safety for software developers requires a high level of expertise in software development, and it requires day-to-day currency in software development. A manager who is not willing to have insight into the details of the work that he is responsible for is patently disrespectful of his workers. He constantly puts them into harm's way by presuming to express authority without knowing whether his expectations are hazardous to the health, well-being, and viability of software work and software workers. Beyond disrespectful, it's dishonorable.

The software field isn't at risk of programmers forming a united front and leveraging collective bargaining, and frankly such a thing isn't likely what anyone wants. But dealing with the root cause issues that have driven other industries to such actions is a win for everyone when obstructions to productivity are removed in the process. Addressing software development workplace safety is a good place to start - especially in our current economic conditions, where a massive boost of unimaginable untapped productivity would be a welcome change indeed.

---

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

The Unfortunate Case of Agile Coaching and Servant Leadership

The need for coaches, and especially servant leaders, is a side-effect of an unfortunate organizational pathology.

Consider this quote from James P. Womack: "We've got too little management and therefore need too much leadership".



Someone who has become specialized as an Agile coach necessarily benefits from the perpetuation of Agile coaching. This doesn't mean that Agile coaches are nefarious and interested in suboptimal outcomes, but perpetuated specialization typically creates narrowed perspectives and thus overly-narrow interpretations of conditions and needs.

The result is often the very same counter-productivity that we observe when someone is given the exclusive job of capturing requirements for a software project: they fill all of their time exercising their specialization, creating an inventory of work that is out of sync with the progress of the team.

When we bring Agile coaches into software development efforts, we should recognize the underlying problem that is being signaled: that software development managers are not presently equipped to manage the software development work that they've been tasked to manage.

By failing to recognize the underlying problem, we often go too lightly into engagements with Agile coaches, and we end up failing to use them to solve the root cause problem, and this perpetuates the need for longer engagements with Agile coaches. This, in turn, drives Agile coaches further into the reaches of specialization, and narrower perspectives, accelerating the erosion of their usefulness.

To break this cycle, we need to recognize the most important reason to bring on an Agile coach: The purpose of an Agile coach is to transform managers and the management system so that managers, in turn, can transform their organizations.

Coaches initially take on responsibilities that ultimately need to be the responsibilities of a manager. Even if the outcome is an improvement, when a manager's job is split between an authority position (the Boss), and a guidance position (the Coach), the outcome isn't as good as it can and should be. Nonetheless, if a manager is in a position to need a coach, then the coach is inevitably going to take on some of the manager's responsibilities for teaching and transformation while the manager undergoes rehabilitation of his own.

The coach and the manager must recognize that these conditions are a necessary evil. The goal is a transition away from the split direction of a team between a manager and a coach. The longer that this split is in place, the higher the likelihood that the new behaviors learned by the team will be undone by the manager when the coach moves on.

Agile coaches can find themselves as removed from the work of software development as the managers that they are called to rehabilitate in the work. For an Agile software development coach to remain effective, he has to be an active software developer. Just as managers fall into the trap of losing software development currency, so do Agile coaches. An Agile coach who doesn't also do software product development for a living is a ticking timebomb of counter-productive guidance for a software development team.

Consider this quote from Daniel Markham: "If you're going to train something, you should be able to do it. And I mean do it to a very high level of expertise. An agile coach should be able to code, perform analysis, manage the project, test -- anything that needs doing on a project. If she can't, then how can you talk to her about your particular situation? If your agile trainer was a BA last week, or never slung code in his life, or is a professional trainer, or -- let's be brutally honest -- is making less than the members of the team are, you've got a dud. It seems like common sense but it bears repeating: you can't train something you haven't done. And "done" means a bunch of times, not just on the pilot project."

The qualities and abilities that Daniel outlines are qualities and abilities that we need to expect from software development managers. If they don't have those qualities and abilities, they need to get them, and a coach might be a way to get there. If the coach doesn't have those qualities and abilities, most of what's produced during the engagement doesn't become lasting, transformative value.

Agile coaches who themselves don't know the work of software development can't teach managers to know the work sufficiently to manage it. They can only teach them to become other disconnected Agile coaches. This is how the second half of the first decade of Agile came to be dominated by the doctrine of Servant Leadership. As more senior leaders in the Agile community spend more and more time in roles that are ever distant from the work of software development, Agile itself is becoming more robotic, more mindless, more of an orthodoxy, and even more of a liability than a benefit.

Servant leadership is one approach - one tool - fit for the organizational conditions that it serves best. An Agile coach often embraces the edicts of servant leadership as a universal panacea when his duty to stay sharp in the full curriculum of software development is dulled by the ease of Agile coaching specialization. But any tool used indiscriminately is going to undo any benefits that it provided in the circumstances where it was an appropriate choice.

A servant leader's typical proposition is that an organization's ability to meet expectations will be transformed if only its inherent creativity can be tapped and unleashed. While tapping and unleashing unused creativity is transformative, it's extremely rare that doing so is either sufficient or sustainable. It often creates conditions that not only lead to unmethodical exploration of ideas, but also makes teams feel that they have a right to this kind of behavior. In other words: "self-determination" rather than "self-organization".

Servant Leadership as a panacea is also a real side-effect of past experiences with bully management. It's an over-compensation reaction to some very real and very tangible painful experiences of abusive directed authority. It's an equal and opposite reaction to an extreme. It, as well, is an extreme. It's as much an undesirable specialization of behavior as abusive directed authority. It's often a programmed predisposition, rather than a conscious choice informed by circumstance.

The Servant Leadership doctrine often patently dismisses the greater goal of balance between directed authority and creative enablement, almost entirely eschewing the value of informed directed authority and skilled directed authority in favor of an over-indulged creative enablement.

A job in creative enablement is a lot of fun, and many Agile coaches have come to feel entitled to these kinds of engagements. They're light, they're fluffy, they can come with no measurable expectations, and they're often damned lucrative - especially in software organizations in the thick of the detritus of an unrecognized management crisis.

The increasing prevalence of Servant Leadership also presents a great opportunity for consultants with little real experience in Agile to re-brand themselves as Agile consultants. It allows for anyone with even a modicum of summary knowledge of Agile development to have a role in the Agile bonanza. But we all lose when this happens.

If you don't already know what your problem is, then pre-supposing an Agile(tm) solution further deepens the mindlessness of robotic management, and it diminishes the Agile body of knowledge. And ultimately, it exposes our organizations to the risks of bringing in help that may only have the ability to talk the talk - which is often all that is required of Servant Leadership - and often all that servant leaders assert is required of them.

Again from Daniel Markham: "One guy (famous author again) basically put it like this to me when I told him the team wasn't succeeding: I'm here to demonstrate certain practices and to show that they work, not to just stop everything and attend to what the team is dealing with today."

To move forward through this crisis, we need to set new goals for software development management: To be close enough to the work to be able to manage work, and to use directed authority in service of helping the team meet expectations when creative enablement turns "self-organization" into entitlements for excessive experimentation.

And we need to re-define the role of coaches from servant leaders to temporary co-managers, helping the team to meet expectations while bully management and its detritus is transformed into effective software development management.

---

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Manager or Bully?

Management in the large: managers set expectations for their workers. Of course there's more to it, but "setting expectations" covers a lot of ground.

Management is central to the productivity crisis we face in software development. It's a crisis that pervades software development so profoundly that we usually don't recognize it. It's like water to a fish - not something that our attention is drawn to, not something that we notice. It's the environment that encloses everything we do. It's not that we see it as normal, we just fail to see it at all. Frustration, burnouts, blown budgets, missed expectations, and dissatisfied customers; it's just the way that most software development is done.

We start with the best of intentions, and despite our intentions, we usually end up in the weeds. We end up in the weeds most of the time because that is where software development teams are directed. It's because of one salient, painful truth about software development:

Software development managers don't understand the work of software development sufficiently to be able to direct the work of software development, and the value of hands-on work experience they've had in the past decays so rapidly that it's increasingly unsafe to make new decisions based on it.

Said more plainly: at a time when senior staff should be best informed by their lengthy and varied experience, they remove themselves from the work of software development long enough to lose the understanding of how day-to-day software development work is done. They lose the knowledge needed to direct the work of day-to-day software development. A certain egoic mania takes root that leads senior staff to feel entitled to believe that their insight has moved beyond the necessity of mere practical work experience.

How long does it take to become unqualified to set expectations for software development work? Not long. It happens as quickly as six months and often not longer than two years. This is why the proposition of Self-Directed Work Teams that has been popularized by new, opportunistic interpretation of Agile Methods has become so attractive in software development - even though SDWT is a well-known failure mode in most development industries and is known to be sustainable for no longer than a couple of years in the majority of cases (there are exceptions, but exceptional organizations usually aren't the rule for unexceptional organizations, despite our best hopes and ideals).

Plotting software development management on a continuum between the extremes of Managers and Bullies, we don't find many managers who are only either extreme. A software development authority is rarely either only a manager or only a bully, but software development managers are usually weighted more toward the bully end of the spectrum. It's an innevitable consequence of having lost interest in the details of software development work, and having become quickly dated as a consequence.

Someone who sets expectations but who isn't able to show workers how to fulfill expectations isn't managing, he's using the implicit threat of crossing an authority to make demands without knowing if those demands can be met. And he's hoping for the best. But we need more than hope to manage software development. We need to know that the work being done every day is the work that leads to the desired outcomes.

Setting expectations without knowing how to meet those expectations almost always leads to unqualified or unrealistic expectations. Using authority to require unrealistic expectations to be met always creates a compounding accumulation of obstructions to subsequent work. It's a sure-fire path to lower productivity. Most software development organizations live perpetually under this cloud of depressed productivity.

A bully sets expectations for workers but doesn't have the relevant and necessary capacities to help those workers fulfill the expectations. A bully has been disconnected from work for long enough that he (or she) is no longer able to personally act to ensure that his workers meet his expectations - to show them how the work is done, and to qualify the work that they do.

In other words, the person who needs to be the most experienced and most expert software development worker on the team is often the least capable.

A direct manager knows how the work should be done. He may know this better than his workers. When necessary, a manager can sit down with the worker's current tools, and teach the worker how to meet expectations, and to teach the worker how the specifics and tactics are tied to a greater whole. A bully hides behind assertions that his time and intellect are too valuable to be spent on such trivialities as the "how" of doing the work in his purview.

It's fair for a person with authority to no longer have the capacity to ensure that workers are materially able to meet expectations, but then that authority must defer to someone who does have the necessary and relevant capacity. And this is an entirely undesirable circumstance. It might be the circumstance that you're dealing with, but it's not the one you should settle for.

An authority who isn't capable of knowing whether and how work can be accomplished and whether expectations can be met is qualified to set only summary expectations. An authority who over-steps the material bounds of his capacity will continue to inject productivity obstructions into his organization's workflow by causing workers to make unsafe and counterproductive decisions that innevitably lead to rework, overwork, and relearning.

A bully believes that his workers are soft and lazy, and often puts extra pressure on workers believing that this is what it takes to get merely nominal productivity. A manager recognizes that workers who retreat from work are likely facing some distressing obstructions in the workflow. He uses his skills as a teacher and his insights into the work as an expert worker to help his workers to recognize and clear obstructions.

It's often hard for us to accept the cold reality of the depressed productivity in our organizations. We fail to manage software development as a product development discipline and tend to manage it as a manufacturing discipline (usually without even understanding or recognizing the difference), undermining productivity at every turn by tuning the wrong variables and turning the wrong organizational and procedural knobs.

In an environment where management leans more to the bully side of the continuum, we see work teams stretch the intentions of "self-organization" into the realm of "self-determination" or "self-direction". It's not necessarily an unwarranted reaction, but its a reaction to a root cause that should be the focus of organizational and procedural improvement. It's in these environments that we also see a need for coaches to fill in the management void, but this is also a lesser palliative that doesn't necessarily get to the heart of the matter.

A manager is someone who balances qualified and expert worksmanship with the ability to teach and is comfortable with using directed authority when necessary. He goes with his team into new learning and new understanding, and re-directs the team if the creative drive for experimentation starts to occlude the imperatives of delivering material product.

Doubtlessly, it's sensationalistic to divvy up the software development management landscape into extremes, but doing so is meant to frame the issue so that we can begin to recognize a real problem and begin to do something about it.

The way that software development is practiced at large, it's perfectly understandable for software development workers to become burned out on software development, and to look for a change. Unfortunately, moving upward to software development management isn't where people who are burned out on this work should go. It's little more than an escape, and it needs to be more of a deeper commitment to the work rather than a means to justify avoiding the details.

Ultimately, software development work will remain palatable for much longer when it is managed much better. But we are where we are, and the general population of software development managers will remain skewed heavily toward refugees from the work of software development for some time.

This is the software management crisis: software development managers at large aren't experts in software development work now, and they often weren't expert workers in the days when they were hands-on. They were the people who came to dislike the work enough to want to escape to software development management. They usually don't know enough about the details of the work to understand how subtle decisions can result in tremendous outcomes, and which decisions lead to tremendously good outcomes, or tremendously poor outcomes.

Today's software development managers largely haven't made a study of managing software development and the principles of product development work and work management. Software continues to be managed as one would manage material assembly or manufacturing. Our current generation of managers isn't aware of this problem because software development management hasn't really been a field of interest for most of them - it's just the job that they have, and it's one that keeps them from having to work in the painful niggling details of poorly-managed software.

None of this suggests that we need to wipe the halls of software development management clean and start from scratch with newly-installed personnel lifted from the rank-and-file. One of the worst mistakes that our current management ideology continues to make is the failure to recognize the material cost of losing institutional knowledge when we lose any worker (NOTE: the flip side of this problem is the colloquial horror of not knowing who to hire, and bringing people into our organizations that we dismiss in short order).

The software development mangers that we have today may have become burned out on the details of software development, but those details can be changed to make the work less tiresome, and make the work less like an uphill battle being fought on a cliff face rather than a gentle slope. Their institutional knowledge is far too valuable to lose. Their many years of experience - if paired with a sharper understanding of which decisions make software development good and which make it bad - provides a perspective of the whole of the effort that is invaluable.

It's entirely reasonable to expect that we can transform the software development industry. The root of the problem is in the software development management system. When software development managers are willing to look without flinching into the reality of their situation and the circumstances that have led to their positions, then we can begin to rehabilitate the system. When that happens, many of the software development industry's most futile pathologies will fall by the wayside and we'll begin to tap the potential that is this industry's unclaimed birthright.

---

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com