Agile Approaches

Most Agile methodologies focus on frameworks, organizational changes, unit tests and performance metrics to develop products. Quality is often measured by code coverage and the number of unit tests that complete successfully. Integration testing is further down the line in the lifecycle and operations is even further down than system tests. All these phases of the lifecycle have their own organizational structures, teams and operational environments.

Agile firms coming into an organization often recommend not just changes to methodology but changes to the organization. One of the most common changes that Agile teams present to an organization is to restructure their teams to form cross functional teams.

Implementing cross functional teams often means taking existing staff from one or another existing teams to form the new team. For example:

• Members from an existing UI team can be selected for the new cross functional team.
• The data storage team and the infrastructure team can also be selected for the new cross functional team.

This often impacts existing teams and how they function. And most managers and team leads are resistant to such organizational changes.

Additionally many Agile firms promote Agile practice by focusing on frameworks like SCRUM. The motivating factor for this approach is that SCRUM has a defined structure that formalizes the Agile approach. Inevitably the adoption of frameworks leads to the selection of tools which model these frameworks and which are then used to “manage” the development process.

The actual management of the process is then put in the hands of project managers, many of whom have little to no development experience who use the tools and frameworks provided to them to govern software development. The result of this is yet another regime that has some rigid structures directing and managing the software development. It is interesting to note that the focus of development teams in this environment is on unit tests and quality is often determined by metrics like code coverage, number of bugs, code size, code complexity, etc.

The general understanding is that once all this management overhead is put into place, that the organization is now Agile.

Agile by the Numbers

The problem with this approach is that in the end all that has happened one regime has been swapped for another which is no less rigid and process bound than before. However all the focus is on the code, the stories, the unit tests, quality metrics and so on. The software development lifecycle in itself is not taken into consideration. And, strikingly, neither is the product.

In most organizations, there is no direct experience of the product being built. The software product lives on developers machines or in system test or in version control systems like git. It is generally understood that if the unit tests pass and the quality metrics are good, that the product being built must also be of high quality. Nothing could be further from the truth:

• Unit tests exercise individual pieces of software. They do not test how those individual pieces of  software work together.
• Quality metrics are all well and good, but they do not indicate how the software actually functions.
• The code in git, though constantly changing, is essentially inactive or  in a state of suspended animation.
• It is only active when it is built and tested on someones machine or machines.
• The only place where the product is experienced is in systems integration tests.
• And even then only the QA engineers and the developers experience the software as a living product.

In essence the state of the product is derived from reports and tools and not from any living experience of the product

Agile Naturally

While all these measures might be helpful, they do not address the elephant in the room – the product being built. It is arguable that Agile methodology is derived from the essential nature of a software product. By decomposing a software product we find that a user story is the smallest cross functional unit of that product. Any smaller and it ceases to be a user story. Any larger and it includes unnecessary functionality that may even belong to another user story. User stories can naturally be bundled into features. And a collection of features taken together composes a product. Essentially a software product can naturally decompose to features and user stories.

Every user story has a cross functional behavior:

• It exists in the UI (Presentation layer)
• It exists in the Server (Middleware/Business layer)
• It exists as data (Data Storage layer)

In order to build a user story and experience it as a whole, it needs an integrated development environment which allows all these pieces to cohabit and work together in an integrated way. This is the argument for cloud native development.

Instead of approaching a user story as individual pieces that are unit tested, it can be approached as a multi-layered functionality that can be tested in an integrated development environment in the cloud. An on-premise cloud provides an environment for upfront integration testing. Because of this, every user story developed in a cloud native manner can be tested and experienced as a living piece of the product. There are methodologies and patterns that can be used for developing user stories in this way. Please see Adaptive Agile 

The difference between the CNDEs and CI/CD pipelines, is that a CNDE, or an ecosystem of CNDEs, are event based and asynchronous. They are loosely coupled and form ecosystems based upon events. This means that they are not bound to a single sequential formation like a pipeline. Events can be customized by the organization and different departments can have CNDEs join existing ecosystems by listening to events they are interested in. This frees up the organization to design development environments in many different ways and to grow their development lifecycle organically.

Besides promoting Agile in themselves, CNDEs also facilitate an Agile approach to building software development lifecycles.

Conclusion

CNDEs and the role they play in the software development lifecycle has not been explored fully up to now. For the most part organizations build their product and then publish it to the cloud. The approach outlined here is to build the product from start to finish, in the cloud. The term cloud in this instance really means a micro cloud or an on-premise cloud that can be augmented with resources that enhance its ability to participate in an Event Driven software development ecosystem. Each cloud instance with these features we call a cloud native development environment (CNDE).

This approach is not an architectural nicety. Making each cloud instance an environment for upfront integration development and enhancing it with the capabilities of coordinating with other cloud CNDEs to build user stories, features, etc. creates essential building blocks for developing ecosystems that can be customized to an organization’s structure. Not only does this bring flexibility and power to a development lifecycle, but it promotes agility, adaptability and velocity to software development. Most importantly it focuses the software development on the product and makes that product always available throughout its lifecycle to the organization at large.

This refocusing of the development lifecycle to the product reduces risk, promotes quality, enhances transparency, reduces managerial overhead, lowers cost and reduces time to market.

Ideate Iterate Innovate