Two years ago, my wife and I flew to San Diego for a conference. We decided to take a few days off after the conference to explore the coast, so we reserved a car at the airport. After a 2-hour flight delay, we departed from the plane and made our way to the rental car counter. The customer service agent looked up our reservation and noticed we reserved a midsize car. She apologized stating they no longer had any mid-sized cars available and they only had economy cars available. We had to decide what to do. Should we compromise and rent a car a smaller car or should we stick to our car size preference and go to another rental car company? Should we be pragmatic or dogmatic?
We all face this challenge on a regular basis. As an agile coach, I see the day to day stress of needing to get stuff done. This stress can lead people to “ignore” some of the “rules” of being agile. Maybe a developer was pulled out of a sprint for a couple of days to address a critical bug in production. Maybe a senior leader wants a feature included in the current sprint even though the product owner and the team planned to work on it later. Perhaps the team members are shared between two projects because they both need to be done. The list can go on and on. Start pointing out the issues and it won’t be long before someone points out the benefit of being pragmatic.
One way I’ve trying to work through the dilemma of being dogmatic vs. pragmatic is by teaching the why instead of the what. Let’s look at Scrum as an example. According to the Scrum guide, Scrum teams are cross-functional and have all the competencies to accomplish the work without dependences on others. Unfortunate, many organizations that are at their beginning of an agile adoption are divided into functional silos (development, architecture, testing) and are skeptical of the idea of cross-functional teams. By explaining the why of a cross-functional team (reduced lead time and improved communication) instead of just insisting, I have found that leaders and team members can better work together to find a solution that will get the organization closer to the goal of cross-functional teams.
Once you understand the why, you can better understand what is critical and what is not. This understanding will also help you decide when to be dogmatic. For example, let say I arrived at the rental car counter and the staff tells me that they only have one car left. It is a mid-sized like I wanted, but the car has one small difference from the rest of the fleet. The seatbelts have been cut out, and the airbags have been removed. They explain that the seat belts and airbags account for a small percentage of the car and the car has been recently serviced and will get me where I want to go. From the outside, it might appear like any other car, but I would consider it is unsafe and would refuse to rent it. The same thing can happen with a team that looks to be agile from the outside. By implementing a practice without understanding they why the team might be causing more damage than benefits.
While deciding when to be dogmatic or pragmatic can be a struggle, knowing and using the why behind the rules and help clarify the situation. By bringing others into the conversation and talking about the why, you might find a different solution. When I was presented with my options for the rental car, a manager overheard the conversation and offered a different solution. Apparently, a mid-sized car just got returned but the rental car company didn’t have time to fill it with gas and wanted to know if that would work. We took the third option.