Way back in the early 2000s, when I had just started my career in the software industry, the Agile Manifesto was making big waves. It promised a radically different, very efficient and very easy way to deal with software. It was based on a very simple set of ideas.
Since then the term “Agile” (note the capitalized “A”) has been reduced to a bunch of certifications, pointless ceremonies, charts and reports. The original problems that the manifesto tried to wrangle with are still by and large the same. Instead many teams seem to have taken this up as a religion and are going through the motions and somehow don’t stop to look and see how truly agile they are with respect to accommodating change.
Agile is not a recipe. One can’t just slap Scrum or XP on to their development process and expect everything to work fine. In my view, the worst kind of offenders are the ones that misinterpret Agile as an encouragement to achieve complete anarchy. I have numerous teams saying “Oh, we follow Agile so we don’t believe in wasting time defining requirements/ documenting/ designing/ building test frameworks.” In the noise of following ceremonies blindly these teams usually miss out on the most critical part of the Manifesto:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Envisioning the product and the real value it brings to the customer is paramount. It is far more important than tools or processes or making the right noises. If your team is working on something without thinking much about the product vision, you are not being agile, you are just courting disaster.
Let us use this analogy of mountain climbing. It is not exactly a walk in the park to scale, say Mt. Everest. Even if you are not the first one to scale the mountain, it is a big challenge. Even if you have yourself scaled the mountain, it still offers unique challenges every time. But at least you know where you are going — you know how tall is the mountain, what are the typical weather conditions, what is the best time to climb, where to camp, how many meters can you climb in a day and so on. And you will know when you have reached the top. You can stick your flag at summit and take a few selfies to post on Instagram.
Now let us imagine you are spelunking in some unknown cave. You have no idea what are you dealing with. This is completely uncharted. Although you have all the spelunking gear with you, you will definitely fall short of something. There could be poisonous gases at the next bend, you may get caught in a flash flood from some underground river, there may be goblins or orcs — just about anything could happen. Moreover, you may never be sure if you have really reached the end or when you cross the point of no return.
In both the cases, you really have to aware of your surroundings and make quick decisions (be agile). In both cases, you need need to be an expert in navigation and survival skills. In both cases, you need to be prepared with the right gear. However, in case of the cave, you are at a significant disadvantage.
Unfortunately, most teams approach product development like they are spelunking. They don’t invest enough time in envisioning how the product would look like and what the customer needs are. They are just happy following the processes and ticking the boxes and do not worry enough on whether they are building and delivering an incremental product.
To use another (rather well-used) analogy, say a team is building a car for the customer. The general approach is to deliver a tyre, couple of seats, a part of an engine, another tyre, a steering wheel, etc. in each Sprint. Although these are essential components, what the team misses to see is that they are not building an incremental product. The customer need is not really the car, the more basic need is to get from point A to point B. The customer may change her opinion and ask for a bullet train instead of a car, but the need remains the same. Most teams miss out on understanding this basic ask. And although they deliver individual pieces, they don’t understand that the customer still doesn’t get to try and see if her basic need is being met. Teams should focus on building the equivalent of a kiddy tricycle, a bicycle, a motor bike, a compact hatchback, a sedan and finally a muscle car as increments. The customer gets to validate the incremental product and the team gets early feedback.
It is rather strange to see so many teams focusing entirely on things like Velocity, bug counts, stand-ups and other ceremonies without really stopping to question where what they are doing is really agile. There are often teams that genuinely believe that as long their Sprints are running well, all is good. This myopic view is not enough to build a great product.
It is even more disturbing when I hear teams blame the customer saying: “Oh they don’t know what they want, they keep changing the requirement”. Erm, yes it is possible, but that’s the whole point of being agile. Customers may not know for sure what they want, especially if they don’t speak the language of software. It is our job as software professionals to glean that information from them. And this becomes a lot easier when we focus on what the customer needs, instead of stopping at what they think they want. We can’t blame customers because they could not articulate their requirement, it is up to us to understand and define the requirement based on the customer’s need.
It is time we refocus on the Product.
