Lines of software, like different colored spools of yarn woven to make a tapestry, are artfully blended by software engineers to make individual features and, eventually, a larger cohesive software product.
Just as the mindful guidance of each hand that works a loom or skillfully manipulates knitting rods contributes to the overall creation of each piece of finished fabric, every software developer, manager, tester, and product champion contributes to the software product that emerges.
This process of mindful contribution by means of careful accuracy to create an emergent property is a systems process.
Aldo Leopold, a forester, wrote in his work Round River,
“If the land mechanism as a whole is good, then every part is good, whether we understand it or not. If the biota, the course of eons, has built something we like but do not understand, then who but a fool would discard seemingly useless parts? To keep every cog and wheel is the first precaution of intelligent tinkering.”
This is not to say that systems organizational models (applied to software engineering or not) do not come with their confusions despite best intent.
Harvard Business School, a source of several quotations and references on this blog, published a paper in 2002 titled by Baldwin and Clark. In this paper, the authors define economic process, value representation, rankable outcomes, and expected cash flows.
A concluding statement of the authors — and to be fair it is uncertain whether this statement is in fact a conclusion or an assumption — reads, “many large design processes can be split into smaller units of activity, and thus design processes are not in general indivisible.” Ironing the academic sidestep of the double negative, the suggestion (although not an assertion) that divisibility into design processes can yield micro-aggregations of value propositions.
Translating into software development, Baldwin and Clark suggest amidst the auspices of economic systems theory that economic processes, of which software development is surely one, can be broken down into discrete units and universally assigned value operators and be placed into economic operators as if they are so many levers that can be pulled and pushed to adjust software development lifecycle efficiency.
Many business and budgetary plans for software development insist — and rely upon — exactly this. Unfortunately, many managers are so intelligent that they come up with super complex excel formulas to make sense of the madness, and the blind push into oblivion continues.
QA, it is assumed in the control model, can be henceforth applied in rigorous modularity along with project management metrics to control and compact the software development process for optimum outcome with engineering input trimmed to a just-barely-enough-to-work model. What a backwards view of QA if ever one existed.
This view of “if it exists, humans can take it apart and make it better” is a human-centric view of the world. It is a view that insists human intellect reigns supreme and that if we do not understand it, it is not optimized. This is a limited and weak view of the world, and especially of software development. Simple systems exist in the world that create their own behavior based on their structures — as opposed to human-thought-controlled software development teams that attempt to control behavior of teams through careful staffing and placement of rules.
There is a fine differentiation to be made between Agile Scrum as a set of rules to control behavior and the Agile Manifesto as a set of values to be honored. There are scenarios in Scrum where you cannot uphold both the rule and the value. Agile Scrum evolved from some very intelligent minds that invented the Agile manifesto as a result of specific circumstances with specific software products with specific types of minds and people. Various flavors of Agile and XP exist all over the world, with both purist proponents and radicals who advise on slight changes to adopt to differences in organization and goals. This has introduced a number of challenges to software QA organizations, project management, product management, and the VP/CIO level.
Tying these levels of responsibility together is the commonality of the Secret Complaint. The elephant in the room of Scrum is that deployment engineers, support engineers, developers, QA, project managers, product managers, VPs, CIOs, and CEOs all have the same problem. They’re all slightly (or very) unhappy about the strictness of the process, the time they have to wait to ship new features, and the productivity churn inherent in the rules set up to deliver the software. Are the controls of the SDLC failing?
Evidence and experience may be showing that it is the control itself that may be the issue at hand. (Authors note: most of the clip art for Control also references Violence. Coincidence?) By and large, systems (in the context of natural systems) manage quite well under optimal conditions, edge conditions, and under stress.
The difference between a true systems organization and a control-based structure is this: Under conditions of extreme duress, control-based structures are brittle, fail, and may experience periods of weakness (exhibited as low morale or distrust in software teams or relationships between development and QA, or product and technology teams.) Under these same conditions of extreme duress, systems-based organisms or teams experience a period of weakness and then grow stronger over time.
Donella Meadows writes in her book ,
“This is the beauty of systems: they can work so well. When systems work well, we see a kind of harmony in their functioning. Think of a community kicking into high gear to respond to a storm. People work long hours to help victims, talents and skills emerge; once the emergency is over, life goes back to ‘normal.'”
Of course, “back to normal” in the systems sense isn’t back (there really is no back, only forward), and it isn’t normal. Normal implies a temporal comparison, the likes of which systems dynamics has no need for.
It’s a step forward in the sense that limits are stretched, boundaries are pushed, the best of us shines. We do what we think we can not until we do. We challenge our belief and grow as individuals and as a people.
In the team sense, throughout and after the experience, each member of the team re-adjusts their boundary cognition to a new value. Each member of the team literally re-cognizes, or recognizes, their real (vs imagined or limited) value and ability, and resets to the “new norm”. So in a sense, when the challenge completes (the emergency is over, the software is deployed, etc) yes the team “returns to normal,” but it is now a new normal.
This phenomenon does not happen in control-based structures, where each member of the team is selected for the net present value of a series of expected cash flows in the future as a well-defined asset price.
Horribly, this is exactly how most software development and QA teams are in fact formed.
Printing out an Agile Manifesto on the wall and forcing software process as a function of voluminous decree rather than collective sensibility in no way creates a systems approach.
C.S. Holling, an ecologist, writes,
Placing a system in a straightjacket of constancy can cause fragility to evolve.
If QA is the check mechanism to audit, question, and encourage flexibility in a software development system, then how can QA build resiliency and a systematic approach to design-first sensibility? anyone would agree that this sort of elastic longevity in software development is much preferred to a brittle process that fails under the slightest of duress.
The key to a systems approach is the complex web of feedback loops within the system.
A control structure is often marketed or sold as a feedback loop; this singular loop can in fact restore the software product to tracking to key project metrics if the system is perturbed.
But don’t be fooled: control structures can only wear the sheep’s clothes for so long. Continued bombardment of a control structure with more complex purturbations will result in repetitive failure that will at some point no longer be able to be tolerated by business champions. Agile Scrum implementations often suffer this fate.
A true software development system will actually rebuild feedback loops when they are damaged or create new loops with greater strength. These values of learning, creating, designing, and evolving ever more complex restorative structures as a function of the difficulty and duress applied to the system is a key indicator of a systems approach to quality and software. True systems actually grow weaker with constancy, whereas control-based teams use constancy as a refreshing break from the next sure panic attack. How are your development teams treating down time? What are your QA teams doing when they are not in receipt of a new build?
Systems: Development team downtime
- Refactoring methods for increased speed
- Building cleverness
- Writing more TDD tests that break
- Reviewing QA code
- Questioning product direction
- Questioning application model
- Modeling new methods for fun
- Drawing up new possible intelligent methods
Systems: QA team downtime
- Innovating new automation framework structures
- Checking test data
- Innovating test data storage and access methods
- Reviewing developer code
- Questioning network topology
- Improving on test environments
- Refactoring complex tests for efficiency
- Innovating uncertainty and user simulation patterns
- Examining test organization methods
- Checking data models against test coverage
- Questioning test coverage metrics
- Questioning functional coverage matrices
- Questioning tests that always pass
Control: Development team downtime
- Picking off low-estimate stories to say you got more stories done
- Surfing lolcats.com
- Buying clothes, accessories, or lifestyle items online to try to make up for empty feeling inside
Control: QA team downtime
- Rearranging tests into different combinations
- Running automated tests you know will pass just to get the run pass checkmark
- Adjusting test parameters to fail to create a problem where none exists so you can later set the parameters back and have fixed something.
I’m sure someone has said this before me, but I like to insist that team members of all ranks and positions be
Careful what you are really paying for; you might end up buying it.
The more control is applied in software development or QA, the more control is needed to keep the project on target.
A systems-based team has self-restorative powers: it can adjust, adapt, and innovate by the very nature of its being.
Systems do require input just like any output-producing structure, but the quality of the output of systems-based teams is a multiple of the system input. This is where systems-based teams shine.
Is Agile Scrum a resilient system? You could argue either way I suppose, but wouldn’t you rather have a long trail of successful innovations rather than a bullet list explaining why your failures aren’t as bad as they appear?
My articles consistently represent QA as a driving force to software development. I feel that systems-based QA approaches can help to drive innovation, question assumptions, and inspire inventive products. QA can assert itself within Agile by following basic scientific principles of a clean test environment and a many-and-often sample rate of new builds. In the case of Agile Scrum as a development paradigm, it is the job of QA to shine a flashlight on the failures of control strategies and the success of systems-based innovation. QA can do this through patient innovation of regression, automation, and performance solutions and pressing to understand the data model, input and output calculation and dependency, and to highlight the complexity of the system where complexity need not exist. Of course, in the end, QA is more than just testers: QA builds themselves as examples to follow, as leaders in the project, as thoughtful innovators rather than reactive pressure valves. It is the job of QA to show the weakness in the system and exploit it before the system really fails. If it is your software development approach that is choking innovation, best to solve that problem first.