Most everyone has heard of the parable 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 many are the same way in the Agile world. They focus on the team and therefore see everything in light of that. If one focuses on the team and sees everything from that perspective alone, an awful lot is missed.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? In other words, the problem is a blend of working on the right stuff and building it right.
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 should 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, of course, 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 be missing the fact 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.