Agile Organizations

Introduction

There is an issue in the generalized notion of adopting Agile practices. Many organizations hire firms to educate the developers in how to become “Agile”.  The practices, frameworks and tools recommended to organizations  by these firms are attempts to govern development teams and install Agile practices into product development. The underlying premise in this approach is that by moving away from the waterfall model or the current development model, that the organization will automatically become Agile.

It is unfortunate, but true, that any rule based regime attempting to govern  from the outside is often misguided. Without understanding the inherent nature of the organization, its culture, and its product, any blind adoption of a behavioral framework merely swaps one regime for another. Also, if the new regime imposes organizational restructuring, it can prevent the adoption of its methodologies and practices. This can be highlighted when you look at cross functional teams.

The Agile notion of cross-functional teams, when viewed through the lens of organizational change is often a barrier to entry for the adoption of Agile practices. The reason for this is that cross-functional team members are required to be members of one team and located together in one place. These constraints mean that existing teams with one reporting structure have to share members with another team, with a different reporting structure. Some organizations do this but it is not an easy fit and can cause friction. There are no requirements that says a cross-functional team can’t be distributed among various departments or even across various states or perhaps in different countries. The principle requirement is that they must be able to work together on cross functional user stories and collaborate in order to do so. The development process itself should facilitate this collaboration regardless of the distance separating members of the team.

If this is true then how would it work? How would team members collaborate, but more importantly, develop code in an integrated environment when they are not colocated in the same department. The answer lies in how the development lifecycle is designed.

Development Ecosystems

Enter the cloud. With the addition of an on-premise cloud, development environments can be designed to the needs and configurations and structure of the organization. For instance:

• The infrastructure server team can have a microcloud to integrate the server with a database.
• The UI team has a microcloud/integrated environment that builds its functionality by integrating within  the server provided by the development team.
• A data storage team might have an integrated environment of its own for developing schemas.

In each of these cases an integrated development environment is a microcloud in which artifacts can be deployed and tested together. Each microcloud or integrated development environment is not just a stand alone instance but has capabilities of pulling in artifacts from a publication repository as well as participating in an event driven ecosystem composed of other microcloud instances.

Each of these cloud based integrated development environments can be considered as an enclosed micro-development environment that can be a member of an ecosystem composed of other micro-development environments.

These ecosystems can form along well known patterns and can also be customized to the needs of the organization.

Design Pattern for Development Ecosystems

The diagrams below illustrate a model for a collaborative development environment. Each author/subscriber works in their own separate development environment which can publish artifacts that other collaborators can consume and can receive artifacts from other contributors. There is a central repository to which all artifacts are delivered, processed and published. Subscribers pull artifacts as needed from the publication repository.

The first diagram is a pattern for how the model works. The second diagram is a concrete example of the pattern in action.

Swipe to the left or right to view the diagrams.

Conclusion

Agile methodologies when applied to an organization as a regime that controls the development process can become rigid, inflexible and impair software development. The approach Kinetic takes is to flip the script: Instead of asking an organization to “wear” Agile methodologies, we adapt Agile to the organization. With the introduction of a cloud based integrated development environment – which is a microcloud with capabilities of responding to events and pulling artifacts as needed from a publication repository and creating resources in the cloud – organizations can design development ecosystems for product development. Because each cloud based integrated development environment (CIDE) is self enclosed and can collaborate with any other cloud based development environment, the entire development lifecycle becomes an ecosystem that can grow and adapt to the changing needs of an organization.

Development ecosystems designed and configured in this way inherently promote communication, collaboration, transparency and agility. There is no need for enforcing a set of behaviors upon the development team. Nor is there a necessity for applying frameworks like SCRUM. There should be no need for competing models for development lifecycles. Instead, what we have is an organic model that can evolve into ecosystems that promote and foster Agile methodologies and practices.

A development ecosystem that is adapted to an organization combined with an understanding of the products functionality, encourages or facilitates piecemeal growth, iterative development, upfront integration and can deliver high quality product in a shorter period of time.

Ideate Iterate Innovate