Machiavelli knows agile.

The Agile reformation is all about satisfying customer needs, improving product quality, moving quickly, and maintaining a sustainable pace of work. These differing prerogatives require changing the way we think about work and look at problems differently. For agile to be successful, a scrum master or coach must lead change.

I often feel like Don Quixote jousting at windmills around the office. One of my product owners pointed out a quotation from Machiavelli.

“It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success than to take the lead in the introduction of a new order of things.” 

Leave it to the prince of political manipulation to give me some fodder for my blog.
Change is hard because people prefer to have routines and rituals in their lives. Also, people who benefit from how things are will resist change because they might lose authority, money, or status. It is easy for individuals to see reform as a zero-sum game, with a gain for someone else equal to a personal loss. I see this pathology in both technical and business professionals.

On the business side, working with technical professionals is a huge culture shock. Now, they discover that the systems and technology they take for granted are not the result of magic. They collaborate on the authoring of requirements, and they have “skin in the game” when it comes to the success or failure of an initiative. No longer will the alibi of “…it is technology’s fault” work in an organization behaving in an agile fashion.

Rapid feedback benefits both businesspeople and technology staff. It avoids “death march” projects. With each iteration, the days of building software that does not drive value to the business disappear. A software project can quickly pivot to new regulatory or market needs. Finally, the CFO will see reduced cost overruns and failing projects.

Agile not only changes the business professionals who practice it; agile changes technology professionals who follow it.  Developers begin to understand the challenges the business faces.  An engineer sees business partners as equals and worthy of respect. Writing unit tests and performing automated deployments build trust with business partners as bugs and defects decrease.  The arrogance of software professionals being the smartest people in the room gives way to the humility of helping others succeed.  The hacker ethos of development gives way to a more professional perspective.

Agile is not perfect. The reformation is only eighteen years old, but it is growing and improving. It is starting to become the de facto technique of new software development, and it is spreading to other areas of business. Change is perilous. Getting knocked off your horse is not fun, but nothing worth doing is easy. The reformation is not going to stop, and you either lead, follow, or get out of its way.

Until next time.