James Sullivan explains popular agile frameworks and outlines their costs and benefits. If you're worried that you are at a place where you cannot make the sort of investments that these agile frameworks require, James is here to discuss foundational agile practices that can provide you key benefits without the costs associated with these kinds of agile brands.
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.