Pragmatic Agility

Something that’s been on my mind is how there are different rules for developing software depending on the context. There are certain practices you might put in place as a small team or individual that wouldn’t adapt well to a larger team. Similarly, there are things you’d probably do differently if you were a startup compared to if you were working on an established product.

On the surface, that’s pretty easy to accept without much push back. But here’s the real kicker, the rules and practices for two different teams working on the same product can be wildly different as well. And not only is that ok, it’s probably the correct approach.

If the goal is to deliver high quality software (and that should always be the goal - even though there’s a lot of wiggle room in that phrase as to what high quality software actually means), each team needs to find their own best practices on how to deliver that software. Just as individuals are unique and thrive in different circumstances and different techniques, teams are also unique. What works for one team won’t necessarily work for another.

Forcing teams to work the same way might anecdotally work by luck or happenstance due to similar cultures, but more often than not might lead to discontent within certain teams. There is a folly in thinking that a healthy culture can be dictated. It needs to be encouraged and earned.

So how can we foster the correct environment? We need to be pragmatic and agile - let’s combine this into a fun term and call it pragmatic agility.

A set of standard operation procedures or practices is a good starting point. It might not be formalized, but most teams could talk about how they produce things and communicate with others. However, those standard operation procedures as a starting point won’t work across every team. Within a team what worked on day one might not work in the future usually due to team attrition and expansion, but also due to the ever changing and growing opinions of individuals.

It’s a managers job to help cultivate those rules and practices within a team. Identify where weaknesses are and try out new rules/practices/procedures/etc to address the weaknesses. But here’s the seemingly obvious but not always followed part: if the new thing isn’t working you can just stop doing it and try something different. You don’t have to wait particularly long to adapt and change either. Prolonging a bad practice to attempt to wait it out will only breed discontent within the development ranks.

As teams continue to work on themselves and develop stronger patterns for delivering better software, they should be doing so independently (as the collection of individuals are different) and thus can result in teams developing different cultures of work. This should be table stakes.

However, there is the acknowledgement that not everyone may be onboard within a larger organization and there are still touch points that you may have no control over being reported up an organizational chain. In this case the team should be viewed as a black box. The implementation details (aka those rules and practices the team develops) don’t need to be known outside that black box as long as they are conforming to the interface (the information needed from each team). Often times a good manager will play the role of the interface and shield the team from the outside. But that too is just another practice that can be tinkered with and iterated on.

In an ideal world, someone overseeing a team of teams acts no differently than a manager would towards individuals. They can first help teams identify if they are meeting goals or not and work with them to help better meet goals. They should be working with managers of teams to explore ways to help teams iterate on their procedures to find the best ones. They need to help architect the API (goals) of the functions (teams) and how the functions (teams) work together, but they shouldn’t be concerned with writing the actual functions themselves (that belongs to the teams). As soon as leaders dictate how things need to be developed, they cease to be leaders and instead become dictators (and no one wants to work in a dictatorship).

I began by calling referring to this as pragmatic agility. The goal is to always work to bettering ourselves, drop practices that prevent us from achieving whatever our optimal success is, continually evaluate what we are currently doing and if it needs change, and try new things and iterate until we are at a spot that leads us to a better outcome. We are pragmatic and we are agile.¹²

Footnotes

1. A lot of what I’ve described is from working in teams for over a decade and seeing what works and what doesn’t. But I’d be lying if I said I didn’t have outside influences leading to these opinions. First up, is Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Dr. Nicole Forsgren, Jez Humble, and Gene Kim. This is an awesome and well researched book that brings the concept of a Pragmatic Programmer to a team and organization level. ↩

2. Second, and perhaps with an even greater influence, is a talk I heard from Dave Thomas (one of the authors of The Pragmatic Programmer) at Emerging Tech East this past year. Dave Thomas who helped author the Agile Manifesto famously decried what Agile had become. His talk, Reclaiming Agility, had less to do with the Agile industry and more about what it really means to be agile. Much of which is adapted to some of the approaches I described here. ↩