Agile, DevOps, Not Perfect!

Agile practices have brought about a much faster pace to how cross functional teams collaborate to deliver value to their business partners in a project setting. The speed at which change happens today, has led to an overhaul in how development, operations, and functional resources participate in delivering software products to their business users, and it has been this need for speed what has brought about the Agile and DevOps revolution. While it has many benefits, the Agile methodology, and a complete DevOps toolchain, that enables developing and delivering changes at the pace that your business now requires also has several drawbacks, including from a project management point of view.

The agile methodology which allows for stakeholders to be heavily involved in the ideation and development of software by introducing a constant cycle of develop, verify, and adjust, has arguably led to the creation of more dynamic products and increased customer engagement and happiness. The technology response to the increased need to build and deploy software safely and rapidly, has been that of the DevOps practices and methodologies, which go alongside the Agile practices.

Some of the drawbacks, however, include a tremendous lack of focus relative to documentation, and an increased emphasis on building just enough and documenting just enough, in order not to delay showing “real progress” to the customers and stakeholders. This also means that project management must deal with managing the expectations of users relative to the ever-changing number of requirements and new features that they think about as they see the software evolve after every Sprint. The rapid pace of requirements gathering (again, often lacking in the documentation department), coupled with a strong desire to move forward, presents challenges from the perspective of having the ability to lock down tasks in a project plan, and keep everyone aligned relative to a schedule, and it also causes issues with dedicating time and effort to artifacts like support runbooks, technical designs that are descriptive enough so that resources outside of the project team can gain value by reviewing them, and more. There is also a lack of emphasis regarding formal training because users see the product often but this hurts future users and those not directly part of the project team. Another challenge that can present itself is a lack of emphasis relative to security, given features that delay delivering value to the users and showing progress are frowned upon, and often software is deployed into Production in an MVP state that largely ignores security concerns that can easily be exploited by malicious actors, and when the security concerns become too evident to ignore, it can cause significant efforts to redesign the solution to account for the security gaps in the initial product and design. Lastly, another area that suffers is that of proper attention to error handling, retriggering of messages and overall troubleshooting and robust support features, in favor of delivering functionality to end users and time to market.

A balanced approach that still delivers value quickly and allows users to see the product sooner, but also does not neglect documentation, security, supportability, and maintainability, should be the goal. We must be careful of falling in love with the number of user stories being closed in a Sprint and artificial progress/value being shown, that can ultimately lead to delivering a sub-par product that looks visually appealing but falls short in every other metric.