User:Noscrum/sandbox

Noscrum is a strategy by which individual developers respond to what they consider to be a misapplication or corruption of the Agile Development process. The basic practice of noscrum is judicious and discreet avoidance of organizational procedures considered to be ‘bloated’ or unproductive. Despite the connotations of the term, noscrum is not against Agile, but rather against perceived hindrances to productivity.

Though some may identify noscrum as a development process or methodology, it is not a development methodology unto itself. Noscrum is more correctly identified as a strategy by which individual developers may operate within their organization’s official development process.

= Origin of noscrum = As Agile gained popularity, some organizations were forced to adopt it, despite having entrenched advocates for alternate methodologies. In some instances this lead to corrupted variations of the Agile process (see also Wagile). In many circles, the application of Agile has transitioned from a culture, to a set of rigid practices. As this distortion of Agile expanded, so did the resistance to it, even among original signatories of the Agile Manifesto. Eventually some of the resistance became known as noscrum.

= Successful Participants in noscrum = Developers who successfully participate in noscrum tend to be high performers who’s performance and passion is significantly reduced by the corrupted Agile process of their organization. For these developers, noscrum provides guidance for how they may more safely thwart the policies hindering their productivity. However, extreme caution should always be exercised, since there are unavoidable risks of systematically violating organizational policy.

When such high performers successfully master the covert principals of noscrum, their out-performance relative to their peers becomes more dramatic and visible. This can create a virtuous cycle, enabling further adoption of noscrum principles.

= Organizational Adoption of noscrum = Noscrum principles are viewed as inappropriate for widespread adoption across an organization. In a general sense, successful noscrum in simply a discreet avoidance of policy by the individuals who can safely do so. If we may assume organizations attempt to tailor their policies to align with their organization, that implies the policies are reasonable for the average person within that organization. It naturally follows that any time noscrum is thought to be appropriate for widespread adoption, an official revisiting of formal policies and procedures is more suitable.

= Inappropriate noscrum = When someone ill-suited for noscrum attempts it, the result is typically visible issues (such as software bugs and schedule slips). The visibility of the resulting issues invite reprimands for their procedural violations. For this reason, inappropriate noscrum is likely to be short lived.

For the sake of noscrum, it is incumbent upon all noscrum practitioners to never defend an inappropriate use of it. Moreover, per the manifesto, deliberate use of must not be acknowledged.

= Poorly Executed noscrum = Some developers well-suited for noscrum may experience issues if attempting to adopt noscrum practices too rapidly. This creates undue risk of being mistaken for Inappropriate noscrum. It is imperative that developers new to noscrum pay careful attention to rule 2 (link). Rapid adoption of noscrum strategies can permanently jeopardize noscrum within an organization. These risks arise primarily from mistakes (such as bugs) or from a sudden change in productivity. Proper adoption of noscrum principles will be perceived as rapid personal growth, without prompting questions of “what changed?”

= Well Executed noscrum = When noscrum is well-executed, outsiders may suspect procedural compliance is a bit strained, but no flagrant violations should be externally visible. Progress reporting tools should be followed, at least nominally. Code should be visually clean and consistent. Debug or tracing tool usage should be thorough and well thought out. Externally identified software defects should be rare. At a casual glace, practitioners of noscrum should appear to be prime examples of everything the corporate policies seek to accomplish.

= Combating noscrum = Aversion to noscrum can occur for several reasons. Understandably, corporate leadership generally expects policies to be followed, so deliberate noncompliance is unwelcome. Inappropriate noscrum can become a serious issue, if not dealt with promptly. Poorly Executed noscrum is likely to be mistaken for Inappropriate noscrum, and is likely to be treated as such.

Well Executed noscrum can be difficult to identify, and therefore difficult to combat. However, organizations should carefully consider their situation before attempting to eliminate well-executed noscrum behaviors. Noscrum is sometimes a coping mechanism of high performers in reaction to what they see as “big company” policies. Cracking down on the practice risks frustration among the top talent.

= Noscrum Manifesto =

The first rule of noscrum is: there is no noscrum
Discussing noscrum only serves to entrench the issues it seeks to address.

Long term, is the most important.
A misapplication of Agile sprints sometimes seek to create excessive urgency. The pressure causes some to rush to the point of sacrificing long term health of the software. As noscrum strategies are employed, the time savings should not be simply devoted to schedule acceleration. First, schedule savings should be devoted to the long term health of the project. By prioritizing the long term, faster delivery will come in time, and be more durable.

Talk, and procedure, are like water.
One can die of dehydration or drowning.

Unfortunately, in some organizations, those who control the faucet may not understand it. The natural tendency is to focus on dehydration problems among the masses. But drowning is the dominant cause of death for productivity among top performers, and sacrificing their performance is a high price to pay. Pairing a dehydrated developer with one who’s drowning exacerbates both challenges.