Force Vs. Flow in SDLCs OR: How to Detox an SDLC
What is a “force” project management style in a software development environment?
“Force,” also called a “brute force” approach, is a strategy of pushing a project to completion at any cost. Force often has an underlying “crisis” element — reactive rather than proactive. This approach is stressful and unsustainable for teams, and impedes creation of a viable final product.
One characteristic of the force approach is that the problem to be solved has not been clearly defined. The Human Capital Hub HR resource site states that leadership which is, “Focused on the original goals at all costs risks failure and can end up doing a good job at achieving a goal that turns out to be completely wrong or misguided.”
“A healthy SDLC environment can appear to be chaos, like other intensely creative disciplines”
Force travels from the top down, paradoxically slowing and stalling SDLCs (software development life cycle). Communication goes by the wayside, lost in the frantic activity of meeting targets. Project managers may succumb to force as a default when experiencing pressure from above. This management style introduces a “competitive” quality, which can inhibit healthy communication and collaboration.
According to a PeerJ paper, “Despite the idea among managers that pressure and negative feelings [brute force] help in getting the best results out, there is growing evidence that fostering positive affects of software developers has a positive effect on the focus on code, task and project goal settings, and, consequently, on their performance.”
Impact of Force, or How to Make Devs Unhappy
A healthy SDLC environment can appear chaotic, like other creative disciplines — think art or music. While parameters can be set prior to start, chaos must be permitted for solutions to emerge. Ironically, coercion, in the form of a force approach, and creativity, rarely co-exist. Regardless of their degree of geekiness, developers are human, and susceptible to the influences of mood and environment set by management styles.
In 2021, the global software market size was an estimated USD $51.08 billion, with a predicted annual growth rate of 8.7 percent, projected to reach USD $117 billion by 2030. Recognition that developers are the key “assets” in the sector has triggered academic studies about the care and nurturing of this human commodity.
The findings of studies correlating happiness to productivity in software development famously gave way to corporate perks like free lunches, private concerts, in-office yoga, and huge signing bonuses to name a very few. While these benefits may be enviable, a healthy sense of productivity cannot be overlooked as a contributor to a sense of purpose and satisfaction.
Dysfunctional, unsuccessful projects are toxic to devs.“Feeling unproductive at work was number one (45%) among the factors that cause unhappiness—even above salary, which slipped to fourth,” said data scientist David Gibson in an article for The Overflow.
In a survey of 380 developers, happiness was defined as the feelings of satisfaction, contentment, or joy that people have about their work as well as a sense of well-being based on the quality of their professional relationships, work environment, tools, and processes. The top reason for developers to stay with their employer was work/life balance (24 percent). Significantly, the quality of projects and salary were next, tied at 21 percent each. Successful SDLCs are an essential component of employer branding and employee retention.
In the book Happiness and the Productivity of Software Engineers, the authors state that, “Being stuck in problem-solving and time pressure are the two most frequent causes of unhappiness. [Another] frequent cause is to work with bad code and, more specifically, with bad code practices. Developers are unhappy when they produce bad code, but they suffer tremendously when they meet bad code that could have been avoided in the first place.”
How do dev teams feel about failed projects? Coders and developers on Reddit forums offer anecdotal evidence of force management failures. One coder writes that “The bad code will be blamed on the developer and not the manager who forced it through to production without the proper review. Grr!”
Another coder says that, “The project is about to finish. At the standup, the project lead seems very enthusiastic about getting the project shipped, and suggests we should make a deployment for testing during the same day. Here's when I start to feel really bad. To me, it's clear that the project won't be shippable soon.” Failed and flawed SDLCs are demoralizing.
What Does a Failed SDLC Look Like?
OnPath COO Lon Botta said, “When you're brute forcing something, you're trying to arrive at a solution as quickly as possible to drive something out the door. Brute force is all tactic and no strategy.
“Six months to a year later you're doing rework. Let's say you've spent a million dollars putting something together. Chances are you're going to spend another million or more to remediate and mitigate. You're going to have high attrition; most of the people that are being asked to perform in a brute force scenario don't have support and they're burned down to the ground. It's bad for morale and it's bad for business.
“At the same time, companies are spending money on marketing and sales collateral, UX/CX, and rework. If you do that again six months later, you've spent a million dollars for a paperweight. Many of these cases end up being absorbed by the company on an OPEX or CAPEX level. It's throwing money at a problem, throwing people at a problem, throwing things at a problem without actually understanding the problem itself.”
Bringing Flow to SDLCs
The term “flow” not only describes the movement of work through the system in SDLCs, it also refers to a state of individual productivity in “knowledge work.” Flow is the polar opposite of the “force” model.
In the paper The Importance of Flow in Software Development, the authors describe “flow” as the ideal journey of an SDLC, but also as a state of high creative productivity. “Software developers that fully concentrate on their work also report this kind of flow, where only the relevant parts of the brain are focused on the core task. SDLCs become more productive when developers have the ability to reach flow for a large part of their working time. Similar examples can be found among athletes and musicians who get into a ‘groove’ where performance and concentration reach a peak level.” By bringing an SDLC into a flow state, the stage is set for team members to enter productive personal flow.
What Does an SDLC in Flow Look Like?
An SDLC that is in flow from start to finish is a thing of beauty, but has basic requirements to set the stage for optimal productivity and product. This means an investment in preliminary planning and forethought to establish a functional, underlying structure to the project. On an individual level, an SDLC in “flow” makes the same state more accessible to team members. “For software developers, accessing the flow state can be the difference between quality software and buggy code,” says Ryan Donovan, CTO of Hootsuite, in his podcast “What Science Says About Flow State.”
“While testing may be somewhat invasive, it does not have to be intrusive, and will make a game-changing contribution to the internal culture of an SDLC.”
In a force structure, there are more ‘unknowns’ than ‘knowns’, while in a flow structure the reverse is true. By pragmatically and proactively identifying all the ‘knowns’ up front — people, tools, process, data, KPIs — SDLCs in ‘unknown’ territory can be quickly course corrected back to the ‘known.’ Next are steps for setting up a sustainable, flow-conducive SDLC environment.
1. What’s the Problem?
Is this over-stating the obvious? Referring to his experience consulting on force-based projects, Botta said, “I have been in many meetings where no one at the table, including stakeholders, project managers, and developers, had the same idea of what the project was and the problem it was trying to solve.”
What problem are you trying to solve? How does your end product fill a gap, provide a solution, or meet a user need? While this step may be obvious, in many cases the early product concept has not answered the question — it might be a compelling idea, but take it deeper and understand the problem it solves.
When this step is complete, everyone — from stakeholders to dev teams to project managers — understands the objectives and minimum viable product (MVP). This highly practical approach begins to build a runway for a successful launch.
2. Who Does What?
One of the characteristics of an SDLC in flow state is that everyone understands their function. A purposeful SDLC plan considers project roles and players, forcing a realistic understanding of resources and capacities. Flow is accessible when each player knows their role, much like in a symphony orchestra—a bassoon player isn’t trying to perform the oboe section of the score. When everyone knows what they’re doing, flow emerges organically.
This is possible even within the creative chaos of the initial phases of the SDLC — a RACI matrix chart (responsible, accountable, consulted, and informed) gives context to the “swinging for the fence” early creative exercises. This matrix preemptively eliminates toe-stepping and empowers team members to deliver their best strokes in their assigned swim lane. You have also introduced an element of predictability to the ideation process. This is a practical approach that aligns the culture/skill set of the team with the priorities of the business.
Every project should have an exception path — a process for managing deviation when the unexpected arises. This is possible, even within a chaotic environment, when team members know what to do and who will do it — exceptions become steps rather than resource-sucking black holes.
3. Communication — Can The Team Hear Itself?
In the flow model, transparency is essential. In the paper A Communication Protocol for Requirements Engineering Processes,” the authors state that, “Unstructured communication can result in situations of both information overloading and information withholding leading to poor process effectiveness and efficiency.”
Force scenarios are the home of “unstructured communication.” Unrealistic deadlines make it seem that there is no time for communication. Ironically, this breakdown delays phase completion and increases costs in terms of lost time and tech debt.
In flow projects, intentionally established communication pathways allow teams to have a birds-eye view of a project while simultaneously staying focused on their own swimlanes or music scores. An SDLC becomes synergistically ‘self-aware.’ Project status dashboards with end-of-day updates facilitate proactive responses to roadblocks.
Contextualize messaging by building specified channels in a communication platform like Slack to foster faster, clearer communication. Don’t depend on meetings as an operational, day-to-day mode of communication — ideally, communication at high and low levels is flowing independent of meetings — the connection points are in place. By embracing this level of communication, meetings become faster and more productive.
A critical aspect of project communication is that it flows within non-public channels, away from non-technical stakeholders who could potentially misinterpret or misunderstand conversations and reactively insert themselves into development processes. Marketing, sales, and C-level stakeholders simply do not have the contextual knowledge to always accurately interpret dev communications.
4. Is the Project On Course?
Analysis and Continual Improvement
Continual analysis throughout the SDLC identifies opportunities for shifts that reduce friction on the path to the end goal. Small, strategic shifts can reveal effective tactical approaches to arrive at the desired end product. This purpose-driven course correction includes exposing gaps and breaking down silos.
Botta said, “An SDLC in flow always has an active communication structure in terms of metrics telling an ongoing story. If there’s a problem you can see it quickly and fix it. You don’t care that there is a problem, you just have to know. You know problems will arise but it’s ok and part of the process — this creates a safe environment. In force models, competitive environments don’t allow for transparency.”
Identify KPIs and metrics going into the project, then use ongoing measurement to track processes. Over time you’ll be able to identify velocity and whether you’re meeting your goals. The data will give a picture of the capacity of the team and point out where improvements are needed for course correction. Data also provides levers to balance the process. For example, if you pull a timeframe lever to support project impacts, then product validation might improve.
When testing is on-ramped in early SDLC stages, developers are relieved of the costly labor of cleaning up bugs and code problems in later stages. Deploying a testing plan sooner allows testing teams to smoothly integrate with dev teams with minimal disruption. While testing may be somewhat invasive, it does not have to be intrusive, and will make a game-changing contribution to the internal culture of an SDLC. A solid QA/Testing service will establish and advocate for robust communication channels with frequent reporting, relieving dev teams of the frustrations of wrestling with bugs and errors, allowing them to stay on track. Improvement is continuous throughout the entire SDLC.
Ideal vs. Real World SDLCs
The SDLC flow scenario has benefits that go beyond high-quality product deliveries — it promotes a sustainable culture within the SDLC, allowing developers to achieve optimal productivity and satisfaction, leading to better overall outcomes. Burnout, frustration, and code debt are minimized, and ultimately, end consumers have a positive UX.
Real-world scenarios can be a different story. They can reactively move into perilous “unknown” zones when a brute force management style prevails, but an SDLC can be “detoxed” and put back on path at any point in its journey.
Whether you’re in the early stages of setting up a project framework, or are wrestling with a stuck or stalled SDLC, contact OnPath Testing for a conversation to discover options for launching directly into flow or bringing a project back on course.
