Agile is a term that gets thrown around and misused a lot, without much consistency in practice to what it means.

If you take a look at the actual Agile Alliance documentation, you will find that the Agile framework is a mental structure on how to solve problems faced when engineering software.

Like any standard, there is room for interpretation and adaptation. And while concepts like Scrum and Sprints may have sprouted by Agile teams, this does not mean that because you have Scrum meetings or develop in Sprints you are doing Agile development.

For us, the Agile framework is nothing more than a mindset. It is being open to constantly evaluate and update how we develop software to assure we are developing as efficiently as possible while adhering to high-quality development standards.

But we do believe the Agile Manifesto has room for improvement, and for this reason the agile part of Continuous Agile Software Engineering, as well as when we say agile in other contexts without the capital A, is not referring to Agile from the Agile Manifesto, but instead referring to the word agile.

We believe in progressing development through small, iterative updates, with various feedback loops from users and insights to help guide future progression.

We believe in adapting to various projects we work on, adapting to various size teams, and even adapting to the various types of people we work with.

We believe that truly agile workflows do not require nor demand detailed pre-planning or documenting of any specific technical details, nor does it involve any feature-specific deadlines or estimating. Instead, planning and documentation are worked on continuously throughout development, evolving as the project and requirements evolve. And instead of delivering features we deliver iterations, with a focus only on the highest priorities.

The only pre-planning and documentation we want before development is the Statement of Work, or SOW, defining the who, what, where, when, why, and how's of the project.

These are high-level questions and answers that any user, developer, or executive should be expected to be able to understand when participating in any work in the project.

In most cases, this SOW documentation should be created and managed by a project owner or manager, and needs to focus on business goals and user experiences. There absolutely should be no specifics within a SOW document that specifies any technologies, workflows, or any other technical details about the project.

Technical details should be documented during development as part of the an agile workflow loop.

Agile Workflow Loop

Agile workflows should loop through specific stages of development, often several times in an average workday. A single feature may require several, even hundreds of loop cycles to implement, depending on the complexity of the feature.

That loop is Research-Prototype-Evaluate-Integrate-Test-Deploy-Validate.