Software developers are “creatives.”  Most don’t fit the stereotypes of artists, designers, authors, etc.  However, even those who typify the hyper-analytical “software engineer” persona crave opportunities to work on projects where they can express their creativity by building great solutions. 

Many imagine (and often start) “green field” projects that allow them to do just that.  They want to avoid integrating their work with previous (legacy) implementations and accommodating technical and project management constraints.  They long for autonomy in deciding what to develop, how, and with what.

Most often, however, this drive for autonomy clashes with the realities of creating successful products and services.  Success entails more than writing code.  Also, developers, like practically everyone else, expect compensation for their work.  Unless the effort is altruistic or some sort of hobby, the needs of sponsors, stakeholders, customers, and users influence what the solution becomes, its development, and the mix of technologies and tools employed.

Every software development project, regardless of the chosen development or project management approach, must address the phases of the software development lifecycle (SDLC) and the constraints of the “Iron Triangle”:  Cost, Schedule, and Scope.  There is no free lunch.

Balancing Team Autonomy and Project Control

Striking the right balance between development team autonomy and project management control involves aligning software development and project management approaches to deliver the greatest value possible.  That balance is different for every organization and project.

Before Agile, the need to subordinate software development practice to the needs of project management was an unquestioned assumption.  Documentation and processes that supported project planning masqueraded as engineering or technical artifacts.  It did not matter that those detailed requirements, design documents, and development plans became obsolete doorstops soon after development started.  What mattered was that they provided information with which to create management plans, schedules, and budgets.

Two major factors opened the door to experimentation with iterative and incremental software development and delivery.  The first was the decades-long track record of failure amassed by traditional software projects in delivering complete solutions on time, within budget, and at expected levels of quality.  The second was the impact of technological advances that flipped the cost differential between computer memory and employees (i.e., employees became more expensive than computing resources).

Differences between Software Development Approaches

We now have multiple software development approaches to choose from.  Each balances team autonomy vs. management control differently based primarily on how they address the following priorities:

• Adaptive vs. Predictive Planning
• Tactical vs. Strategic Focus
• Innovation, Flexibility, and Speed vs. Control and Risk Avoidance
• Iterative and Incremental Delivery vs. “Big Bang” Delivery

Adaptive vs. Predictive Planning

Figure 2 above depicts some of the most common software development approaches on a spectrum, from most adaptive on the left side to most predictive on the right side. On the adaptive extreme (cowboy coding):

• Little to no planning occurs prior to or during the project
• Developers execute project activities in an ad hoc fashion, based on their own judgement and project needs, rather than following a deliberate plan
• They have a free hand in choosing what they develop, design approaches, technologies, tools, etc.

As we move from left to right on Figure 2, software development and program management process overhead increase.  So does the amount of planning done prior to software development.

As Figure 2 depicts, planners have latitude in tailoring and implementing software development approaches.  Different choices yield different amounts of process burden and upfront planning. Ultimately, project and technical constraints and circumstances shape the implementation of all software development approaches.

On the predictive extreme, project activities are tightly coordinated and sequenced based on plans that encompass the entire development project, from requirements definition to release.

Rather than performing most project planning during the Planning and Analysis phases of the SDLC, Agile spreads planning across its entirety. Agile software development executes SDLC activities as one integrated flow of work that grows and evolves solutions iteratively and incrementally.

Tactical vs. Strategic Focus

As we move across the software development approaches, from left to right, solution alignment with organizational strategic aims increases.  This is because predictive software development approaches are typically top-down in nature. Adaptive development projects are more closely aligned with short-term tactical goals and deliver capabilities in smaller increments than predictive development projects.

Alignment between strategic and tactical imperatives is possible and necessary for both predictive and adaptive approaches. However, the inherent top-down vs. bottom-up nature of predictive vs. adaptive planning results in very different ways of achieving strategic and tactical alignment.

Learn how Scrum aligns organizational strategy and IT via a product management mindset.

Innovation, Flexibility, and Speed vs. Control and Risk Avoidance

Choosing the right software development approach also depends on project sponsor and stakeholder priorities.  Projects best suited for an adaptive development approach prize innovation, flexibility, and speed.  Predictive software development approaches are most appropriate in organizations seeking to enforce top-down control and avoid risk.

The nature of a project’s technology and business/mission domains also influences choices between software development approaches. Projects best suited for a predictive approaches:

• Have stable and well-understood technology and business domains
• Standard and routine solution approaches
• Project staff experienced in delivering systems of similar size and scope

An adaptive software development approach is best for innovative (non-routine) technical projects and for projects that require ongoing refinement and experimentation to arrive at the most optimal solution.

Some software projects in regulated industries or government may require predictive software development approaches.  Regulatory oversight increases the need for program management control and risk avoidance.  Most software system development projects do not require that level of oversight and control, thus making them likely candidates for adaptive software development approaches.

Iterative and Incremental Delivery vs. “Big Bang” Delivery

Another defining feature of software development approaches is whether they deliver capabilities iteratively and incrementally or as monolithic “Big Bang” releases.  While most organizations deliver software solutions incrementally across multiple releases, many develop large increments of capability over months or years. Such release increments are essentially Spiral or serial Waterfall projects.

Iterative and incremental SDLC approaches, like Agile, increase the frequency of releases and shorten the time between them considerably.  For example, software teams that employ Agile approaches such as Extreme Programming (XP) and Scrum develop release candidates every two to four weeks. Smaller, more frequent releases lower risk and provide more opportunities to align solutions to current business/mission, organizational, and technical circumstances.

Conclusion

Control is a vital element of agility.  Accelerating the pace of software delivery requires some degree of control and flexibility.  Overemphasizing control slows software development and decreases flexibility.  Underemphasizing control can turn flexibility into chaos, robbing software development teams of both planning and process stability, thereby slowing progress.

The term “Cowboy Coder” is a pejorative for a reason.  Developing functionality without disciplined technical and project management processes leads to low-quality implementations and project failure.  It also makes it harder to align solutions to market, business, mission, and oversight requirements.

The opposite extreme is ill suited for most software development efforts.  Most software development efforts do not need the amount of process and documentation overhead Waterfall software development brings. In fact, the predictive planning necessary to carry out Waterfall process and documentation runs counter to the way modern software systems are developed.

Software development teams must not ignore project and technical constraints.  Nor should they try to address every constraint and risk prior to development.  Instead, they should leverage them to create better solutions through inspection and adaptation, iterative and incremental development and release, and adaptive planning.

Last Updated on February 2, 2022