Developing with Agility

For many organizations, and individuals, agile software development is just a process.

I guess I first need to describe what I consider are the tenets of agile. Agile isn’t a process, scrum is a process, as is kanban. These processes are meant to create a set of actions that allow teams to organize their agile practices, with observable reference points for adjusting actions and providing information to external observers. But this isn’t agile. 

The foundations of agile are concerned with continuous improvement, empowering teams, removing roadblocks and ultimately delivering value frequently. These foundations of agile are based on refinements in manufacturing (i.e. “The Toyota Way”), lean development, and observations that came after engaging with customers frequently to deliver value. 

This is all great right? It’s a philosophy that engages and empowers individuals as well as customers. But what happens? People are trained in scrum practices, or kanban practices, but not in the ideas. They are taught ceremonies and actions, not why, what value are brought, and what they might do differently. And organizations drift from the ideas, because they want measurable activities, constrained along fixed schedules that have nothing to do with what they deliver. 

I think there is another tenet here that gets lost, or maybe was never defined, which is that the individuals should behave with agility as well. And what I mean is their individual approach to writing code. A team or individual is given a feature that produces outward value (users are identified via an account, which can be created, modified and deactivated). They make an effort to break this down some, but only within the process constraints that have been created. If they are following scrum, they try to make it fit within blocks of time. For kanban it might be looser, picking delivery portions that make sense as a final value, but if you take a step back and look at it, are arguably still too large.

I believe this occurs because of that concept of value. They might be asked, or are thinking, what value am I delivering? Well if a user can’t create an account, they don’t yet have value. The developer then writes a large chunk of code, all the pieces from data storage to business logic to a communication layer to a user interface and testing. They don’t consider it done until all these pieces are in place. They might not even consider it done until you can do more than create. 

The effects of not developing with agility impact many dimensions of the overall product. The development can exceed the process constraints, meaning nothing gets delivered within a sprint, so the processes lose value. Without focusing on the smaller actual individual pieces there can be a lack of comprehensive testing. The resulting logic may not be something that can be easily explained, creating later problems first when it is tested in an integrated environment, causing a long tail of defects, and second once the product is deployed.

Developing with agility may not solve all these problems by themselves, and there are other strategies that can help mitigate these issues, but if you start with asking developers to practice agile development, thinking about how they mentally break down items and getting that into their actual actions, the overall process improves, and the delivery flow is ultimately more successful.

Leave a Reply

%d bloggers like this: