Understanding the Customer vs Customer Value
The Gilb’s have started a series of posts against Agile. The first on is Wrong Focus.
“It is not about working software. It is not about your preferred working process. It is not about user stories. It is not only about your customer or user. It is all about delivering, to your set of Stakeholders, value improvements to them, to what they care about, what makes their world better, within agreeable, minimum or pre-determined costs. If that is not the main focus, if that is not clear to everyone on the team, you will eventually loose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad.”
They claim Agile software development is flawed because it focuses on improving the process and environment of the team developing software. These improvements result in improved customer collaboration that ensures the team better understands what the customer wants. From my experience, the combination of improved environment, appropriately sized process, and customer collaboration results in mature agile teams doing a great job of delivering the projects and products. But I understand their point. There is a difference between understanding the customer and focusing on delivering customer value.
Wrong Focus
Whether the software development organization is building software for external clients or to enable the organization’s business processes, there are always more things that can validly be improved than there are resources to do the work. Not all of the improvements will result in the same return of business value to the overall organization. Some benefits are more valuable to the organization than others. If you don’t pick the one that is most valuable to the business it is not the right investment for the business. In any of these improvements, there is more improving that is valid than is necessary to achieve the benefit. If the team works on improvements that aren’t the focus of the effort, “while they are there”, they are not focusing on business value. This delays delivery of the effort and is not the right investment for the business.
Nothing in the Agile Manifesto, nor most of the Agile methods, give the tools to pick the right improvements to focus on. They also create an environment where it is extremely likely to work on more then is the minimum necessary to achieve the targeted business benefit. In many organizations, close customer collaboration can lead to “gold-plating” of features. If you offer the customer whatever they want – they will ask for it.
Wrong Focus in Practice
I have a customer right now that is going to build some software to support their field employees. The business goal is to achieve a significant cost reduction in the field through improving quality and efficiency in the field. The developers are extremely interested in developing mobile applications, distributed collaboration, GPS interfaces, image capture and markup, mapping, barcode, and training training. They have started a new business to build this product with the hope of selling it outside the business in the future. The challenge here is how do they clearly identify those improvements in the field and in dispatching that will deliver the significant reduction in field expense. If they go and and talk to the dispatchers they might find 30 things that could be done better. All of these improvements would result in an improvement in work conditions or performance. But they may not be aligned with the current business focus. The same will happen in the field.
Just because it will improve satisfaction or make someone’s job easier doesn’t mean it will help with the current business focus. How do they align absolutely the minimum amount of technology to deliver on these improvements? Especially when their interests are in this bigger, more robust solution. Especially when this limiting of features is not in line with their future business objectives. Nothing in Agile addresses how to deal with this conflict.
Where’s the Answer
I address this in Feeding the Agile Beast. This is the domain of Business Analysis. As the Gilb’s point out, most Agile methods abstract this from the team. They focus on improving their processes and collaboration. In Scrum, Business Analysis is abstracted behind the Product Owner. In XP, it is abstracted behind the Onsite Customer. I don’t agree with the implication from the Gilb’s that this abstraction is a deficiency in Agile. It is just outside the scope. I also don’t agree with Agile teams that close collaboration with the customer is sufficient to ensure business value is achieved. This is not an OR conversation. This needs to be handled as an AND conversation. This is the next thing we need to learn – how to keep an Agile team laser focused on business value AND maintain the benefits of understanding the customer that comes with Agile software development.
Tags: Agile, Big Agile, Business Analysis, Software Development
Subscribe via RSS
Thanks Dennis, this is an interesting conversation. As I was reading through your post I was thinking “Doesn’t the product owner own the requirements? Aren’t they supposed to ensure value is being delivered and work with the scrum master and team on it?”
Is it just a matter of the team being so heavily focused on? I’ve seen Scrum implementations in particular where this was true.. the product owner’s role was nebulous and ever changing. Kind of like many project sponsors in general.
Josh,
Yes. The Product Owner owns the requirements and is responsible for ensuring value is being delivered. They should also provide oversight to make sure gold plating doesn’t happen.
But that’s exactly the point. Agile just assumes that the Product Owner knows how to do this and is doing it. Everything about it is implicit. The ceremonies (processes) and values within the team are explicit – the ceremonies and values outside the team are left up to the product owner.
Gilb is critical of Agile because this isn’t addressed. Just saying it is someone else’s responsibility doesn’t make it happen effectively.