The first Agile principle is “customer satisfaction by rapid delivery of useful software“.
The thirds Agile principle is “Working software is delivered frequently (weeks rather than months)“, I actually think these two are very closely related.
Both are about regular delivery, although point one stresses the “useful” aspect, implying business benefit needs to be achieved with each iteration. And the third principle has a focus on “working”, meaning the delivery must be a complete usable function which has been adequately tested.
But what does that mean in the real world?
I’m a keen fisherman, so it might be time for a few fishing analogies. Sorry!
Any fisherman could understand this concept with a commonly used fishing phrase “a little and often“. When we want to catch loads of fish we don’t chuck all our bait into the lake and simply wait for the fish to come. As then we caught nothing then a few big fish then nothing again. To translate into business terms, you’d have to wait longer for benefits realisation to start and when it did the short term benefits maybe quite large but they wouldn’t be sustainable in the long run.
Dropping in a little bait at a time helps to gradually develop your swim and once the fish have started to bite you will generally continue to catch if you keep going with a regular feeding pattern. Meaning, with Agile rhythm becomes important. Plan frequent releases of software each one delivering small incremental benefits, the business will become familiar with this rhythm and will expect to be “fed” on a regular basis.
A common mistake by the novice fishermen is to get this feeding pattern wrong. How much to feed and how often is key to landing a large catch. Just as with Agile the length and content of each sprint is massively important. You’ll need to experiment on what works best within your particular organisation. Be prepared to steer away form the Agile text books!!! You’ll find that “true” Agile will expect a very rapid delivery cycle, I’ve seen books suggest that a 2 week cycle is the absolute maximum. It is quite likely that this doesn’t fit with your organisation so be prepared to adjust the principles to fit your situation. I’ve had more success with a 4 to 6 week cycle. Simply because the business has a day job and they can’t always devote enough time to support a 2 week cycle. In my opinion, starting off with a monthly cycle and then reducing or increasing based on business appetite would be a good commonsense approach.
Another concern for every fisherman is the environment. Changes in the weather, water temperature or even water oxygen levels will all effect your catch rate. And in turn will dictate the speed and volume you should feed. For example, in the winter months fish are very dormant meaning a slower and smaller feeding pattern will give better results. The business world is no different, changes in priorities, staffing levels, management focus, budget and market conditions can all influence the speed at which change is productive within an organisation. With fishing experience tells the angler when to increase or decrease the feeding pattern. Guess what, Agile is no different! The longer you run sprints the more experience you’ll have on when / how to adjust the rate of delivery. Don’t be afraid to change your sprint lengths, don’t become ridge in your thoughts on how long sprints should be. It isn’t and shouldn’t be one size fits all.
In my next post I will discuss the 2nd Agile principle “Welcome changing requirements, even late in development”, hopefully with less references to fishing!