For something as complex as software development, there can be no “right” way of doing things all the time. Each project has its own set of variables, challenges, and idiosyncrasies. And every developer has a preferred way of working, which makes it difficult to set any hard and fast rules. But this doesn’t mean you should dive into your development projects head first, without guidelines or a methodology—albeit a flexible one—to inform the way forward. And when I say “methodology,” I am using the term in the general sense of the English language word, meaning an approach or way of doing something.
Because of the uniqueness of every development project, no single methodology can be the best one for every scenario. Methodologies, including Scrum, Agile, Lean software development, kanban, and a dozen or more others, have been created with the goal of systematizing or guiding software development. Often the newer methodologies are reactions to older ones, correcting for an over- or under-emphasis on structure, planning, and management. And though the basis of many methodologies is an iterative approach, the methodologies themselves have sometimes become too rigid to undergo the necessary evolution to mature and improve.
Agile itself came about as an antidote to “documentation-driven, heavyweight software development processes.” But it too has its critics, who cite its lack of predictability and documentation as potential issues, while others see pitfalls in that it hasn’t lived up to its promises of a sustainable pace.
Enter Agile 2, which, as the name indicates, is not a wholesale rejection of Agile, but an effort to augment its better aspects with approaches that promote successful software development. I founded it with a team of other forward-thinking highly experienced practitioners in the fields of product design, program management, business, system engineering, human resources, learning theory, software development, DevOps, and of course Agile. We saw an opportunity and set about fixing Agile.
The result of that team effort is an open set of ideas and approaches, rather than a prescriptive list of rules and procedures. Some areas where Agile 2 differs from Agile include:
- Planning: Agile downplays the importance of planning beyond the immediate iteration. While that attitude has loosened considerably, suspicion of planning is still present in the Agile community, even though planning is essential for complex endeavors that involve multiple teams and especially multiple organizations. Agile 2 recognizes that a business’s needs can change over time, so flexibility is necessary to adapt planning and execution to meet these changing needs, but forward planning is necessary as an activity that helps one to think through courses of action, choose a direction, identify intersection points and flexible milestones, and be prepared with contingencies.
- Collaboration: Agile teams typically work with a dedicated Scrum product owner who defines the requirements for the software’s functionality. Agile 2 sees the need for multiple stakeholders’ input into the features and functionality needed and—perhaps more importantly—to integrate the design of the product with the design of the software. According to Agile 2, technical design and product design must be closely aligned so they can iterate in parallel, each influencing the other. Further, development teams need exposure to real users so that they can be part of the conversation about requirements, as developers often have insightful ideas about product features—if they understand how users will be using the product.
- Team structure: The culture of the Agile community has long been one of a one-size-fits-all attitude, often with claims that certain approaches such as pair programming and Test-Driven Development are always best for everyone, with the implicit message that if you are not using those practices then you are not yet “mature” in your use of Agile ideas. This is ironic since the Agile Manifesto begins with the expressed statement “[we value] Individuals and interactions…”—note the explicit focus on individual agency. Thus, Agile historically doesn’t always take individual working styles into account. Early Agile also emphasized the single team construct, with small teams of usually five to nine members. Agile 2 takes a less rigid approach to the team dynamic, including the physical location of team members, and allows for flexibility to work in groups or alone. It recognizes the need for varying team constellations—with generalists and specialists valued equally—and multiple teams, based on an organization’s or project’s size and complexity. The reality is that people are cognitively diverse: we need to acknowledge neurodiversity as a core principle and not try to force one work style template on everyone.
- Data: The original Agile Manifesto didn’t mention data, but the strategic importance of data should not be overlooked. It’s vital to both deriving insights and validating your implementation. Data needs to be reliable and easy to access for it to deliver maximum benefit to the organization. Agile 2 emphasizes the need to break down data silos—and data expertise silos—to make this happen.
Joining forces: Agile 2 and low-code.
Some of Agile 2’s recommendations aren’t necessarily easy to implement when using traditional high-code development methods. Take the “dual-track” product design approach, for example, where product design and technical design work in parallel, collaborating with one another, but neither impeding the progress of the other. Though this is possible to achieve when creating software by writing long-form code, going from feature definition to feature implementation can take weeks or even months. There’s often a considerable lag between the point when a development team receives the business’s requirements and when product designers are able to see those requirements translated into something they can try out. Thus, the long development time for long-form code inhibits the ability to get the most out of a dual-track process, which ideally would be a rapid cycle of feature conceptualization and implementation, with little delay in going back and forth.
Low-code application development, however, is ideally suited to the principles set out in Agile 2. Enterprise-grade low-code platforms come with capabilities that address many of the issues Agile 2 has brought to light.
- Planning: Process modeling in low-code makes planning easy by providing a graphical palette for creating your process flow. IT and business stakeholders can agree on the activities that need to be carried out, which tasks should be assigned to automation technologies, and where human intervention is needed. The process map can be adjusted at any point when carrying out the technical design and product design, depending on the needs of the business. Thus, planning is lightweight and highly visible, and one can pivot easily. Sophisticated low-code platforms also offer the ability to organize documentation in one centralized location for the use of future teams working on the software. This allows you to keep requirements, best practice checklists, relationship diagrams, and any other type of document all in one place. Having critical information linked to the project itself ensures nothing gets lost and new developers can ramp-up quickly so as to meet the business’s timelines. Thus, documentation is also lightweight, highly visible, closely tied to the things being documented, and easily maintained.
- Collaboration: Low-code helps to bridge the gap between developers and business stakeholders by making collaboration easy and highly visual, and encouraging clear, frequent input, which helps you test assumptions along the way to finding the right solution. Prototypes and in-progress builds give product designers and test users something concrete to react to, accelerating the product design process by ensuring your development team has a clear understanding of what’s needed.
- Team structure: Low-code offers a much lower threshold to entry than high-code environments. This allows for much more diverse teams to work on development projects, which expands on the promise of cross-functional collaboration set out by the original Agile Manifesto, which mentioned the user and the customer several times. From seasoned developers who’ve mastered several high-code languages and have broadened their expertise with low-code, to “citizen developers,” and other workers who bring a variety of professional backgrounds and skills to the table, low-code provides a more inclusive approach to development. The better low-code platforms can also be especially helpful when multiple developers are making changes to a single application and need to be cognizant of how those changes will manifest when deployed together.
- Data: Sophisticated low-code platforms eliminate the need to create complex database views or migrate data. Low-code connectors can deliver access to the data where it lives while also offering the ability to extend and transform the data, which makes it easier to act on the insights the data delivers. Not only can low-code platforms provide a unified view of an organization’s data, but they also include built-in data validations to maximize data reliability. Low-code’s promise of unified, validated data provides the kind of strategic value that makes data a true stakeholder in the software development process. The disaster often seen today of a data lake that is full of unusable data can be avoided.
Agile 2 strives to remove some of the de-facto rigidity from Agile by highlighting and expanding on the ideas of flexible collaboration, better alignment of technical design and product design, and an evolution in the team dynamic to incorporate the skills and knowledge of all team members and stakeholders to drive better business outcomes. Agile 2 also recognizes the value and importance of data as it relates to software development, and emphasizes the need to make an organization’s available data as useful as possible. With low-code, organizations can better address these topics and improve their existing Agile practices.
To learn more, check out the “Low-Code and Agile 2: Like Peanut Butter and Jelly” whitepaper and see whether a low-code platform and Agile 2 can be a winning combination for your organization.
