Meet the new boss, same as the old boss

Organizations large and small adopt Agile for many different reasons, not the least of which is the promise of rapid product development. In most cases Agile consultants are brought in to help facilitate the adoption of Agile practices into an organization. Invariably the discussion comes down to frameworks and tools. A great deal of time is spent choosing frameworks like SCRUM or Kanban, or selecting the preferred Agile tool for Agile management.

In most of these cases, the individuals put in charge of instituting Agile practices are not developers. They are managers or project managers, or individuals certified by SCRUM. It is rare to find technical project leads as being Agile coaches and if they are, they simply adopt SCRUM or Kanban and use that to “become Agile”.

When it comes to tools, a great deal of time is spent discussing which tool is best at representing Agile processes. And these tools are used to make developers conform to  an “Agile model” so that managers can “track progress”.  Under this new regime developers are discplined into providing constant status through these tools and to their overlords in project management, most of whom know little about software and even less about the product being built. Nevertheless, organizations that adopt these practices proudly demonstrate their Agile credentials and how their development processes are now more nimble and adaptive.

To add to the burden placed upon software development are the notions that quality is determined by metrics and unit tests. Unit tests and metrics such as code coverage, test coverage, defect density and so on, are used as yard sticks to determine software quality. A great deal of emphasis is placed on unit tests alone. And if the automated builds and their associated units test run successfully, the implication is that your software has a clean bill of health.

It is unfortunate to observe that organizations who adopt these practices have merely swapped one form of external control for another. Their new processes, after the adoption of the new regime, are no more Agile than they were before. And the focus on process obliterates the focus on product. Additionally, while software metrics help developers to clean up code, the strict adherence to them is no indcator of product quality. In fact, it may be argued that relying on these metrics alone can be a false positive on the quality of the product being developed.

In most companies that  implement the new Agile model wind up with rigid structures that are no better than the waterfall model or whatever they did before. And in some cases they are worse. These new regimes are also brittle, rigid and over-managed and have moved away from Agile’s notion of self organizing teams.

Behavioral systems can be naturally broken up into units of functionality or user stories. And each functional set of user stories can be delivered in cadence of two – three weeks by a self governing team. This process is by nature definable and trackable. If the user stories require functionality in the UI and software service as well as the database, an integrated environment – like a cloud – is the natural place for it to occur. Also the development process for each user story or integrated unit of functionality will naturally take place iteratively because an integrated environment promotes it and the nature of that user story demands it. It also fosters collaboration and communication between all team members developing the user story. Additionally that functionality once delivered can be reviewed and experienced by all the stakeholders in the business.

Developers can track their development through user stories in Agile boards. But tracking  the software development by using Agile boards  doesn’t need any formalized framework to manage it. Developers can choose any tool or methodology that helps them visualize and guide the process. It is a critical inflection point that developers manage tools, but the tools are not used to manage developers.

Agile development is natural and can be presented in many different ways. SCRUM and Kanban are only two of these ways. The Agile process does not need any formalized structure to represent or define it. It is self defining by its very nature. And when these natural progressions in the Agile development process takes place, they can be externalized and tracked. The tools and frameworks that the team uses are at the discretion of the team and are there to help the team visualize and manage what they are doing. The team controls the process and not the other way around. In effect, the development of a product occurs from within the development team and is collaborative, dynamic and nimble by nature.

Conclusion

Most efforts at Agile attempt to control and manage development teams from the outside. They create a regime that imposes itself upon software development. And this approach not only slows down software’s natural growth rate, but may impair its quality as well. These efforts attempt to regulate behavior through rules, frameworks, tools, metrics and so on, do not achieve the results they hope for.

The natural approach to Agile, which Kinetic adopts, is to create an environment that promotes and fosters Agile principles and practices. In this environment a team naturally collaborates and communicates in order to build a product. A shared environment like the cloud also facilitates product review by the stakeholders. By making the product always available, its visibility and awareness grow within the organization. And after a while the focus of the organization begins to change from processes, reports and metrics to the product itself. This is not to demean the value of metrics or code coverage etc. but to promote software quaity and awareness by direct interaction with the product at all levels of the organization.

It is a goal of the Agile development process to make an organization product-centric, rather than process-centric. After all the purpose of the organization is to deliver a product. All stakeholders can contribute to product enhancement and product quality. This reduces risk, promotes quality and reduces the time to market.

Ideate Iterate Innovate