In my previous post, I mentioned that when in doubt on what to do to fix a problem in your agile process, think of The Agile Manifesto as your inspiration and guide on what to do.
But, as the Manifesto offers a list of guiding concepts, it may turn out a little tricky when a given problem to fix puts you in a dilemma between at least two of these concepts that may seem at odds.
Let’s suppose a situation to give an example to make the point more clear: in the next sprint, the customer is asking to add a new feature to the solution. Some of the existing functionality must be able to support that new feature (**)
From the experience in previous sprints, you have already learned that the customer is adamant about the idea of “retrofitting” as the way to give existing functionality the ability to support new features, specially if that retrofit (which looks a lot like re-work!), may require a substantial amount of the person-hours of a sprint.
After you navigate these reqs with the customer, you realize that they feel oriented towards adding new routines, similar to the existing, that include the new feature, so, for any given functionality, you will have two versions of the routine: one version is the existing routine, and the second version will be a similar routine that also supports the new feature.
It is clear to you that this approach does not sit very well with quality attributes like Maintainability or DRY (Don’t Repeat Yourself), just to name a few (and Separation of Concerns, and Single Responsibility Principle, and …)
Besides this, you perceive that these reqs put you in a contradiction between “Working Software” and “Customer Collaboration“.
So, the Agile Manifesto, instead of helping you on how to find a solution to a problem, seems to be part of the problem. So, what should you do?
As I have already stated in (another) previous post, Agile is all about “giving value to the customer”, so, we should not find any contradiction at all, since “value to the customer” means that “Customer Collaboration“, first and foremost, will be your beacon that will lead you out of the woods.
If, after you explain to your customer all the pros and cons of each proposal, including the ones that do not seem OK but are more pleasing to them, the customer still insists on their idea, well, you should be flexible enough to accept their proposal for the time being, implement, and let them use this (not so perfect) implementation, so that they may eventually realize what you were talking about.
THE concept here is that any agile project has to evolve as an ongoing conversation with the customer: to be able to give value to your customer, you must understand your customer, and to be able to do so, you must keep that conversation open and flowing.
Kind regards, GEN
(**): An existing digital dashboard web app, with a set of charts that allowed drill down into tables with detailed info. The original dashboard had monetary figures in just one currency, and the customer wanted to include support for multiple currencies.