Next up in the 3 hole of the agile principle lineup is Agile Principle 3. Lets take a look at it.
https://agilemanifesto.org/principles.html
Well this one seems a no brainer.
In many ways that is exactly the truth. We hit the single most valuable delivery point for the customer. Deliver working software. We establish a time frame and a valuation on that time frame. There is not much to unpack on this one. In fact there are only two things I really feel need some clarification.
Definition of Working Software
When you say working people get in their minds visions of a perfectly working product all fleshed out and done. The reality is very different. The working part of the working software should say something more akin to meeting specified goal. One of the things about the agile process is it is iterative. So working is a loose definition.
If you job is to get feature x built and you deliver feature x that is it. Right? Well, what happens if feature x’s implementation is slightly different from the wire frames? Some would say that is wrong but is it. If the wire frames have 3 textboxes. Each with a fantasy of data within it. When implemented, it is discovered that the 3 textboxes take too much room to display all of the data without horizontal scroll bars or shrinking the base text size. The system is working by the definitions of the written list but not the vision of the wire frames.
Sometimes that is ok and other times it is not. It is how perfectionist the business owner is to a functional or visual ideal.
For example, I have one client, that could careless what the output of the programs GUI reflects data so long as it has the needed output. While others every facet of the GUI must be perfect. It is a temperament and business goals defined reaction.
Business realities of Time Scale
After the nuance of the first, you would expect there to be something similar with the second part. Not really, you want the shortest time scale you can manage to have a functional deliverable.
For instance, in my government job, 2 weeks would be impossible. The gears of the machine just can’t move that fast. But a scale of a month or two would work. While the management would not think that as a amazingly fast pace, the reality is it is. Most project require inter-sectional cooperation. That takes, time, paper work, and the occasional nug to wake up the napping DBA. For the record, I had to do that before.
That being said, if you can’t build a actual deliverable in the time of the sprint, then your period is too short. So if things are not getting done or getting done in enough scale to deliver the value to the business process owner than stretch that scale out to longer.
Final Words about Agile Principle 3
Finally, it is a per industry, per employer, per business process owner pacing issue. Those three things determine the length and speed of the project. The slowest one will win. Be prepared to combat pushes to make it go faster because the slowest of the three will determine when it is over.
For example if you employer want to push through fast and the business process owner agrees, which in small business is often the same person, but you are in an industry that has to met industry standards, you maybe blocked by government or private regulatory bureaucrats from actually moving that fast. Agile Principle 3 can be surprising stubborn to implement within an organization because of that reality.