An Agile Parable

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.

 

Most everyone has heard of the parable of the blind men and the elephant.

In this parable, the men are blind. But blindness can be achieved not only by loss of sight, but by being too close to the situation. For example, imagine that each man could see, but was standing so close to the elephant they could see only the part they were in front of (e.g., body, tail, leg, trunk, ear, or tusk).

I think this describes many in the Agile world. Many focus on the team and therefore see everything in light of that, missing many essential aspects of what is needed.  This, of course, is not to say the team isn’t important, or even critical.

We all agree Agile software development is about adding value to the customers of a business.  But to add value you need to do several things. You must ensure that the value you are adding is aligned with the business strategy. Is it the biggest return on investment available?  We must both build things correctly while building the right things.

In small organizations, teams are often close enough to see the entire process of creating this value. For example, if you’re on a team in a company that has one product, you can learn how the product will help the customer and that may be sufficient.

But what about the bigger organization where there is more than one product. How do you ensure you are working on the right product? Or how do you know that after delivering some value for the product you are working on, you shouldn’t shift your efforts to a completely different product? This requires stepping back a bit and looking at the product line(s) you have.

But it doesn’t end here. Are the products you are working on the right products for the strategy of the business? And, of course, it doesn’t end there. How do you know your strategy is correct? As you keep stepping back and as your problem gets larger, you see that the team is a small part of the picture.

While team-centric methods may be effective in solving team challenges, they may not address the organizational challenges that need to be addressed. I liken this to a mechanic who always works on the engine to get better acceleration. Maybe the problem is in the transmission, maybe it’s the type of fuel we’re putting in the car, maybe it’s we’re headed in the wrong direction.  The point is – why would you assume it is with the engine?

If you want to improve your development organization you must remember that building the software is only a part of the puzzle. Building the right software is usually a bigger part.  Beware of any approach that presumes starting with the team.  This assumption may blind you to what is really going on.

When looking at different Agile methods/frameworks/thought processes you might want to first look at where their thought leaders are coming from and in particular, what part of the entire problem are they attempting to solve and how?  Many now purport to work on the entire enterprise.  But look deeper, what are the methods being used? If they are merely team methods scaled up, you might miss that different dynamics occur at different scales.

When trying to determine what looks best or where to start, you might first look to see where you are looking from. This is the shift from Agile to Lean-Agile. We are looking at being Agile within the bigger picture.

While the moral of the parable is that humans have a tendency to claim absolute truth based on their limited, subjective experience as they ignore other people’s limited, subjective experiences which may be equally true (Wikipedia). there is another potential lesson from the story. If we overcome this bias and recognize everyone offers some value, we can discover what is truly before us by collaborating with each other.

The Agile Manifesto is very team focused.  See The Agile Manifesto: Incredible Success and Time to Move On.


This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.