The following post is part three of a three-part blog post series, called From the boat of product to the sea of culture, that touches on the interconnectedness of culture, product and agility. Other parts include:
- Part one – The sea of culture
- Part two – The boat of product
An agile mindset is represented by the boat motor that is used to drive the product forward. Just as there can be different types of boat motors – fuel engine, steam, and manual oars, agility is one set of values that can propel the product towards solving customer problems and achieving business outcomes in complex domains where the cause and effect relationship is not (immediately) clear. Depending on the product’s need, you would choose the appropriate boat motor(s).
Using cynefin terms, if you are working in the simple/complicated domain with sequential steps, perhaps an overall waterfall approach might be better suited. That does not mean that agile and waterfall are exclusive. Agile values can be used within waterfall ways of working. For example, if you are building a house, you would like to first lay the foundation before creating the skeletal structure of the walls, and then proceeding to creating doors and windows within the house. You can’t create the windows before laying the foundation and creating the skeletal structure. However, when you’re creating the windows, you can work incrementally and use customer feedback to inspect and adapt your work prior to completion. This is an example of using agile values alongside waterfall ways of working.
In essence, agility boils down to the working in a way that embodies the Deming cycle, also called the PDCA (plan, do, check, act/adapt) cycle.
Working in increments de-risks your product/service. Rather than creating a plan and blindly executing on the entirety of the plan, it’s often a good idea to work on a small part of it, check with your customer to see if it delivers the expected value, and make their feedback actionable by infusing the next increment with it. This leads to continuously improving your offering and plan with timely advice.
Lots of scaling frameworks (such as SAFe) try to fill the need of coordinating difficult areas of a complex product. Rather than being dogmatic and adding redtape, administrative complexity, and new pre-defined processes to your work environment, it is often better to think about how to de-centralize and quicken the decision-making process in order to reduce dependencies between parts of your product, so that you can scale it quickly and effectively. This is the driving principle behind Amazon’s growth and success. I describe how this can be done in part two of this blog series. This often enables each team/department to create solutions for their own context rather than using a pre-defined silver bullet, which in real-life, only makes the company’s problems worse.
No engine can help move the boat of product forward if the sea below doesn’t exist. A coherent culture needs to be established for any organization to enable effective agile ways of working. Existing frameworks like Kanban and Scrum can help a team deliver more effectively and efficiently, if things such as vision and mission, strategy, operating principles, goals and measures are already in place. Without those things, trying to improve a team with the help of any framework is doing something efficiently but not effectively. An analogy to think about this is a dog trying to dig quicker and quicker for a bone but not realizing that it’s digging the wrong spot. The dog is being efficient at digging because it’s doing it at a good pace, but it is not effective to the goal it wants to achieve, which is to find and dig the bone. Effectiveness focuses around identifying the right problem before trying to optimize for a more efficient way (less waste and quicker time to market) to create a solution. A point that I often see missing in clients is the clarity around what agility means to them and what problems they are trying to solve by being more agile. Think of being agile as a means to achieve your business goals, rather than it being the goal itself.
Dysfunctional organizations that try to implement scrum as a quick scheme to be more modern or work like the rest of the cool kids fail more often than not. It’s like applying a bandaid to a deep wound that needs surgery. Leaders and change agents often focus on applying practices and frameworks, or introducing new product roles and techniques to help them better address customer needs and eventually be a profitable organization. However, as emphasized in part one and part two of this blog series, it’s more important to build a culture that enables an effective way of working towards addressing customer needs and business goals at different points of the product lifecycle. Rather than treating it as an exercise that is done once, it’s important to treat building the culture as a constantly emergent and evolving process. Once the sea of culture is established, you can then allow agile values and principles to thrive in your environment and drive the boat of product forward.
Rahul Bhattacharya 
2 thoughts on “The engine of agility”