Agile 2019

Recently, I’ve noticed discussions about the state and direction of Agile. Martin Fowler gives presentations about the state of Agile here. And Robert C. Martin devoted an entire book to this topic - Clean Agile - which I read in one sitting and definitely recommend.

I truly observe that times have indeed moved on. Agile has become a buzzword and a cargo cult. Most people claim to follow it, but interpret it in their own way. Reality is described by terms like faux-agile or dark-scrum. Agile is sometimes interpreted as the only correct approach to managing projects. Sometimes it’s enough to just implement Scrum, divide the waterfall implementation phase into iterations, and the agile transformation is complete. Unfortunately, even developers don’t consciously understand the basic principles and values that Agile brought. I judge this by myself and my surroundings.

But what is Agile actually?

Agile, or better yet the Manifesto for Agile Software Development, is for me a set of values that I should consider in the constant search for better ways to create software. However, they are very abstract, so it’s useful to expand them with the Manifesto for Software Craftsmanship. Although it seems to me that I understand everything, I don’t know exactly how to implement these values into daily work. And this is where Extreme Programming comes in. I recommend the excellent book by Kent Beck.

The most important thing for me was understanding that the goal is the simplest possible design - the absolute minimum that’s sufficient to meet the customer’s requirement. For this to make sense, you need to work on making subsequent changes or adding increments as simple as possible. This is helped by the TDD methodology, which is based on double-checking (test and implementation). And as a result, any refactoring or change could be performed with confidence that what we’re doing works.

However, in design, both I and apparently my colleagues have always tried to look several steps ahead and prepare the system for requirements that might (but also might not) come. With this approach, we try to eliminate future changes and system refactoring, but at the same time (from an agile perspective) we unnecessarily complicate the system. It’s therefore necessary to make this mental switch, which may go against what I’ve been used to doing throughout my entire career - which may not be simple at all.

And then there’s another necessary mental switch. This time on the business side of the project. This involves the product owner allowing a certain portion of the iteration (sprint) capacity to be dedicated to developers for work whose results cannot be immediately sold to the customer and therefore “aren’t visible.” If the business demands one hundred percent (sometimes even higher) utilization of iteration capacity, developers won’t have time to refactor, update, explore new approaches, and in the long term, the system will suffer. This switch is even more complex because it requires trust that developers will use the allocated time efficiently.

After reading these books and articles, I perceive that we need to focus more on and talk about the technical side of transformation. Not just glide over the surface that’s obvious to everyone.