Lets move to the next principle, Agile Principle 2. We see what the main goal of the whole process is in Principle 1. We now look at a customer value creating concept.
Principle 2: Welcome changing requirements, even late in
https://agilemanifesto.org/principles.html
development. Agile processes harness change for
the customer’s competitive advantage.
Now this one, requires less unpacking than the first.
- Open to Changing Requirements
- Create Competitive Advantage
Both of these are at their core, items that create value in software to the customer. From this value, wins can be won. This is a core violation of the Waterfall method of software development. I suspect part of the reason this is separated from the first was to make sure the declaration from the Waterfall method was absolute.
Remember some of my worst moments in my career is when management decides to go a modified Agile method. I’m sure this is brought out so that Agile supporters can explicitly call bullshit on them.
Open to Changing Requirements
If you really stop and grok this, you soon realize this is just an implementation consequence of early and continuous delivery. Or more precisely the mindset you need to be in for early and continuous delivery. Because customers are customers, they will throw monkey wrenches into the process. It is important to roll with it.
I know when I was a much younger developer, I worked in a government agency. In this place was a Waterfall approach with Agile elements. So a modified Agile process. We had a situation where things kept failing. The reason why was with the more or less Waterfall approach with more meetings than usual but the requirements were still months old when they finally made it to the developer and often times weeks to months older when they made it to the end user. We have talked about the world changing and new requirements popping up. These extra meeting we mostly 2 hour plus team status meetings that would eat roughly a day each week worth of work hours.
As a result of the process, we could not change the system to reflect the changing requirements of the business owner. It was a nightmare. Then came in my crafty manager.
He figured out the core problem and got management to implement a Software Warranty Period. That way the customer can make sure the developer deliver on all the goods the documentation promised.
In reality, it allowed the business owner, the customer in this context, to work with the PM and the developer to figure out how to fix the real problems. The developer delivered what the business owner needed and the PM figured out how to wedge it into the original documentation and thrice weekly PM meetings they suffered through. In the end, it actually worked.
Create Competitive Advantage
This one is just a fact. Flexibility on delivering software that reflect actual problems now rather than 6 months ago means you can exploit problems to deliver better value. I don’t actually have anything to say on it. It’s like saying the sky is blue. It’s like yes and?
So how to execute Agile Principle 2?
Most of it is tied to the fine art of telling the difference between a customer problem and a customer dream. The dreams can wait and should be pushed to the next 2 week sprint. They will derail a sprint for little value. Problems are things that tend to be tweaks that improve the end product somehow. Those can deliver massive value to the customer because it is alleviating a pain point in their lives.
People are selfish creatures and if you are hurting you are very aware of the pain. Relieving that pain is incredibly valuable to clients.