DECODING THE EFFICIENCY AND EFFECTIVENESS OF AGILE PRODUCT DEVELOPMENT

When teams are trying to change from a waterfall product development to Agile, it is good to adopt a practice like Scrum/a scaled framework for larger teams or Kanban to set the cadence/synchronization or flow to adhere to the first principle of the Agile manifesto “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

The “How” of the Agile principle

It is dangerous however to think that a transition to such a practice alone is ‘going agile’. Scrum or Kanban define the “how” of a delivery: the “early and continuous” part of the agile principle stated above. The “valuable software” piece is a different story altogether and is the “what” of the delivery. While coaching the teams on agile transformation, too much emphasis on the “how” can mislead people into thinking that is all there is. Particularly so, when people are exposed to the agile world through the lens of a scaled framework, its certifications and roles. This can lead to a waterfall inside Scrum. Teams would go about developing products like they always have, with the only difference being that the work would be defined by say sprints or a scaled framework with its own rituals in addition. Management focus in such a case would be on which existing person can fit into which new role that a Scrum or a Scaled framework prescribes, who must be trained for what etc. The result of such a focus would of course yield a no different outcome in terms of the product’s value and if this is the sole direction that teams take, it can become an excuse to say that “Agile doesn’t work”. Note, finally, that this is the easier part of the agile transformation.

The “What” of the Agile principle

Equally, if not more important, is the “what” of the agile principle: valuable software. Hmm, which practice enables this? How does one approach this problem? Are there organizational issues that will hinder the delivery of “valuable software”? With the bewildering array of agile practices available, how does one choose the right one? A simple way to approach the problem is to first break down the product into increments and iterations and progressively elaborating as you go along. Say, as an initial step, a system engineer divides the product’s features into 5 increments and three iterations of each increment with a broad definition of a cadence for each increment and iteration but with a vision to move towards a smaller time-frame for both. Then you search for which agile practice removes barriers that hinder this. Is lack of test automation hindering frequent integration? Will test driven development or pair programming help improve software quality? Will Behavior driven development catch bugs better? Does the team need technical expertise to be able to ‘break’ a complex hardware product into increments and iterations? Are outdated organizational practices like centralized decision making, drive to insane levels of human resource utilization, measuring people by hours spent in the office rather than on outcomes, silo departments each trying to optimize themselves in isolation etc hindering the delivery of “valuable software”? Basically, every problem under the sun! There is no easy answer here and any practice in this realm is always work in progress keeping in mind that “One size doesn’t fit all”. Also, a mechanism needs to be in place to always watch the applied practices for tweaking/discard or to adopt a new practice.

While working with teams to adopt Agile, it is important to define the “what” (the effectiveness part) and then execute the “how” (the efficiency part). The “how” is relatively easier; the “what” is the place where you can expect resistance as this is where people will have to change the way they work. Organizational barriers need to be broken, policies might need to be reformed, the way you develop software might need to change etc. A useful way to go about this is to adopt agile in an ‘agile’ manner: incrementally and iteratively. This reduces risk and can get better buy-in from management when it sees the long term road-map for such changes but take them one at a time and in small steps.