Agile has been a popular methodology for many years. I agree with the Agile Manifesto and its related principles, and I have successfully used agile methods for years, including continuous integration, continuous deployment, and DevOps. It is true that “out-of-the-box” agile is a methodology that is most appropriate for localized (often called collocated) or virtually localized teams. The need for supporting larger, often distributed, teams is a main driving force for the new brands of agile, mostly dedicated to scaling, and to making the entire organization agile. Some examples of popular agile frameworks are disciplined agile delivery (DAD) and the scaled agile framework (SAFe). Now don’t get me wrong, I am a huge fan of DAD and SAFe. However, these are brands of agile that require significant training and support; they require their own set of processes, artifacts, investment, and prices.

This is not an article that “bashes” agile brands in any way. In fact, I believe that many of the new agile brands are fantastic and provide great return-on-investment. However, these new agile brands do require investment, and if you are at a place where you cannot make that investment, I am here to discuss with you foundational (base) agile practices that can provide you key benefits without the investment in agile brands.

As you, most likely, know, there are key base agile practices that will provide you certain efficiencies, customer insight and early “feedback loops” that will make your software project less difficult, clearer, and more understandable. Release and deployment management are directly supported by continuous integration, continuous delivery, and DevOps. It is equally important to take a strong business focus.

It is always important that you live up to the commitment of your business governance. While there are many myths about agile and other processes related to not delivering documentation, remember that this is not true. It is important that you regard all processes as frameworks to which you map your business. Always deliver you regulatory and governance artifacts when they are due.

One important agile practice that can really drive strong collaboration with the business and customers is the use of requirements written from the user perspective. In agile these are called user stories, but they can be regarded simply as user requirements. The reason why these types of requirements help is that they will drive increased interaction with the customer. This, in turn, will empower the customer and shift some control in the customers’ direction. This increased communication and customer control will directly positively impact customer satisfaction.

Requirements written from the user perspective can be challenging. The user will provide no information on technical complexity, effort, difficulty, tiers, etc. All this discovery and design is up to the development team. To be sure, this will spark many conversations with the customer, and the customer will become more invested in the solution process.

Another agile practice that will improve software quality is validating that all requirements are covered by test cases and enforcing that the test cases are run. The results are obvious: test requirements and software quality will increase. Finally, be sure to track and resolve all defects.

Have your business team prioritize the requirements that you implement. Not only will this allow your business team to feel invested in the project, but it will also drive important collaboration. When your business team is invested in the process, and feels that they have some ability to manage it, it will be remarkable how much customer satisfaction improves.

DevOps is another set of agile practices that can be applied to our software development process immediately to improve quality and tune release and deployment, thereby decreasing time to market, which improves the release and deployment process. DevOps may sound like today’s new marketing term, but it involves basic good configuration management, good build management, and good deployment and release management.

DevOps supports continuous integration testing. Continuous integration testing involves running builds in a team or common workspace. The builds in the common workspace run as developers deliver their new or modified files to work to the common workspace. Continuous builds allow builds to run against all developer changes. Therefore, if there are problems with any developer work, the problems will be discovered immediately when the build is run. Then, once discovered, problems can be readily resolved.

It is likely that you will need a software configuration management (SCM) tool to run the DevOps process efficiently and in a repeatable manner. There are a number of SCM tools on the market. Some tools are free, some are expensive, and others are low cost. You get what you pay for, but all tools can support continuous integration models, and there is plenty of online documentation for continuous integration.

SCM tools will also support good SCM strategies. SCM strategies are often the foundation for good governance and compliance strategy. SCM supports changes management, file versioning, and application versioning. Change management is the recording and tracking of development tasks, change requests, defects, etc. All of which can be tied back to a business compliance and governance strategy.

Good SCM version control is more than just checking in and checking out files and code modules. Good  SCM DevOps practices link the file versions to a change record in the change management system. This, in turn, links the working software to the business compliance and governance strategy. Good SCM practices, by way of tools, also track the version of each file involved in a build and, eventually, a release. Each time that change will be captured by the SCM system, even if one file changes in an existing release,. Full releases are typically tracked by baselines, and file version differences between baselines need to map back to the change system. Good DevOps practices are good software development practices. Agile only adapts these DevOps practices because they make software development releases less complex and more manageable.

Continuous deployment is based on the same idea as continuous integration. Only continuous deployment involves the deployment of the application and its component to a “production-like” environment. Because this process involves “smoking” out problems sooner, virtualized computing and cloud makes maintaining production-like environments easier.

Working in increments is another agile practice that one can readily adopt. In agile, the increments are called sprints. The benefit to working in increments is reasonably clear; they allow you to establish simple milestones in your work while you test and look for feedback. Working in increments provides a strategy for managing change, which means that the business and the team can discuss and understand technical “trade offs.” Teams can also run quality tests on each increment and find defects sooner when they are the least expensive to fix.

To me, working in increments is a natural way to work, and it is a great strategy for making projects less complicated. The approach is to break down complex tasks into simpler tasks. Teams can adopt this incremental strategy any time, and there does not need to be a big commitment to using a formal agile process and training. Working in increments also provides the team opportunities for “think breaks.”

Short breaks really do help with the design and problem-solving process. I am the anxious type and I have major difficulties leaving work-in-progress, but I have always had successful results when I take a think break, or “sleep on” a problem.

Agile has this concept of the daily standup, or daily Scrum meeting, and it is a great idea for communicating status and issues. These daily meetings have a very standardized process. However, teams can schedule regular brief updates without the formality, and they can gain similar benefits. It is possible to use a report or query from the current SCM or change management system to discuss the current status of the team’s work. This will also make the development process more transparent and it will serve to help with future planning.

Although I really am a fan of agile there is not always a need to fully adapt and make an investment in a formal methodology. As discussed in this article, there are some “good software development” practices that can be implement by your team without large investments in software development process experts. These good software development practices will make your development project less difficult, increase software quality, and also increase customer satisfaction. Industry best practices, including continuous integration, continuous deployment and DevOps, will help you achieve success on your own to become more agile.