Agile is not about rituals; it is about developing software differently
In too many organizations that have adopted agile you can see walls covered with sticky cards, stand-up meetings and even pictures of pigs and chickens. However, beyond the rituals, software is being designed and developed exactly the same way as before. Agile methods have been around since the nineties, and after twenty years in the process of adoption most organizations are still scratching the surface. This is not unique to agile; adoption of innovation has always been this way, as human nature is to resist change; we welcome new technologies, ideas and gadgets, as long as we can use them to do what we do mostly the same way. In the past it took several generations for innovation to generate change. Today, with the acceleration of technology, it may take just a few years, but it doesn’t happen instantly.
Adoption of agile in organizations is a process that needs to be understood. The first generation of projects will likely stay on the surface of rituals and tools. Practices like collocation, full allocation, stand-up meetings, etc; can be done even when using a waterfall approach, so they are comfortable. In order to move to deeper waters, teams have to embrace agile practices that can act as triggers for change. One of these practices is “time-boxing” and another one is “quality is non-negotiable”. When these two practices are combined, teams are forced to think differently. When the team knows that the iteration will not be extended, that overtime will not be approved, and that stories with defects will go back to the backlog and that the demo with the sponsor and stakeholders will not be pleasant, things start to change.
Floating scope is probably the practice that has the highest potential to trigger change. On one hand, it reverses the logic for managing projects, with scope being the dependent variable. On the other hand, it requires trust between the delivery organization and the customer organization. Trust that the team will deliver a solution that is capable of realizing the benefits that justified the project, in the time and cost expected and with top quality. When there is a relationship of trust between the project and key stakeholders, this start to permeate down to the team, and allow agile practices to turn a platoon into a self-managed team of smart people that need less direction and more space to deliver high quality solutions.
