Bespoke Agile

To co-opt a quote by E. O. Wilson “No administrative phenomenon can be fully understood without attention to it’s evolutionary history.” This is from ‘The Superorganism: The Beauty, Elegance, and Strangeness of Insect Societies’: I hope the humor is not lost on anyone - and yes, the quote actually reads “No biological phenomenon…”

Problem statements

Problem: The solutions we care about are large in scope

Enterprise projects are complex, and by far the most complicated is the human side. An agile approach facilitates points of contact - but it does very little to provide actionable collaboration driven by the respective department heads. Yes, there are ‘scrums of scrums’, and other attempts at hierarchical solutions - but this runs into ‘computational irreducibility’: there just isn’t enough time for the relevant problems to be surfaced and solved in this way.

Problem: The perspectives from all departments must be taken into consideration

The interactions between like knowledge domains such as Development and Quality Assurance are complex enough; in addition, departments such as customer Support, finance, Sales, and IT are often under-represented within the teams, and so parallel and inefficient process evolves to address their concerns…

Problem: Ownership of solutions is difficult to craft

Implementing the intra- and inter-department adaptive processes that CAN lead to predictable development and deployment is simply more complex than most people can address without going beyond the bounds of their day-to-day responsibilities. There is often disruptive cognitive dissonance when real people grapple with requests from other teams to do extra work, or believe the work at hand is above their pay grade.

Problem: Unexpected events can be impactful to the business

There are serious business consequences if the impact of a problem is not recognized, or once recognized, there is no run-book available to help craft solutions. Events such as stop-ship bugs, or drop-everything-and-fix-a-problem-in-production defects can roller-coaster over the best of develop and deploy expectations, and certainly derail delivery of new feature milestones.

There are upstream and downstream impacts when reported problems require an unexpected amount of development and test time. Upstream - executives may need to adjust financial projections. Downstream - Marketing needs to be told their favorite new feature may not be ready for a scheduled advertising spend.

Customers may require immediate assistance to prevent erosion of brand loyalty. Worse - if the problem relates to security or data leakage - the viability of the company might be at risk.

Design Goals

Goal: Allow specialization within teams, and require greater personal responsibility in completing distributed clerical tasks

A primary design goal of bespoke-style program management is simple: have everyone opt-in to doing just a little bit of extra work in addition to their career focus. Implicitly this assumes that most developers really like to develop, many people with ‘quality’ in their names may not love to code (yes - QA is dead, long live QA): for example, if those who make code changes opt-in to curate and version manual test cases directly related to each pull request for a feature - the world is a better place for quality-focused team members. QA can ask ‘How do we optimize automation in our feature-branch and release testing?’ instead of ‘Why do I have write a bug because this widget is not implemented to product and design team specs, or the coder did little exploratory testing?”

Goal: A single source of truth (in progress)

There are several concepts combined to deliver ‘truthful data.’ The first is that variables are immutable at any point in time. As time moves forward and values change - we can look for rules related to change. From the variable’s perspective, local rewrite rules (closures or lambdas) move it from one state to the next. This idea applies to information in sets and graphs. This concept is related to mutation and redux in functional programming models.

The second concept is that there is one canonical instance of the variable that is rewritten, and all other instance of the variable are just that - immutable instances embedded at a point in time, updated as needed from the canonical instance. This idea also applies to information in sets and graphs. This concept is related to consistency in distributed database models.

The third relates to scope and namespaces. Variables do not stand alone - they take on life and meaning in time and context. They have their own perspectives, indelibly related to the filters used to create reference frames. We generally use names to identify variables, but it’s useful to reuse those names, and copy variables. With more than one variable with the same name, scope is the region of local process space where a name is available. Namespace is how we ‘look up’ the name associate with a unique variable in the region. This concept is related to maps: I live in Cambridge Massachusetts, USA and not in Cambridge, UK…

Goal: Transparency

This covers the agile initiative to have all information available to everyone at any time. Transparency exists in the context of reference frames. A reference frame is a filtered view through which the exact set of information needed for a specific perspective is available. The promise is that all information is available to all frames of references, as close to real-time as possible. For example, anyone who looks at the value of a variable, set, or graph is guaranteed to see the same values in any instance at the same point in time and scope.

Goal: Degrade gracefully

Everyone has been in the situation where there’s more work to be done than can realistically be met with the resources available. The bespoke approach recognizes this is always the reality, and the focus is on best practices to plan collaborative projects. The relevant goals can be stated as:

- Mitigating areas of high risk with incremental and small changes to both deployed products, and the processes themselves used to develop and deploy the products

- Empower product management to adjust the scope of deployable features to keep schedules in balance with available resources

- Create effective plans for unexpected events and practice them: have a process run-book for the unexpected…

Ideally teams can change the scope and focus of current tickets on demand. Historically scrum teams must complete a sprint, bound to those tickets sized and accepted… but this approach can lead to poor outcomes.

To accommodate these business realities, an adaptive approach to sprints allows current work to be put aside, backlog items reprioritized, fires tended to, and then a smooth recovery to the previous stories… The normal flow is interrupted by design for the time needed, and not ad-hoc with all the mayhem that usually entails.

This approach is often labelled ‘ScrumBan’, as a melding of strict Scrum rules for sprints and Kanban, an approach focused on serialized ticket completion. For both, sprint boundaries are useful for metrics and to track story completion. For those who who view deviation from sprint rules heretical: consider the model of a 3-day sprint, with day-1 being a spike; and days 2-3 being reserved for clearing all active tickets above the backlog… rinse and repeat.

In fact, degrading gracefully can be a sustainable approach. It’s a catchy phrase - but the more accurate description is ‘adaptive development.’