As we continue with our monthly look into the Agile Principles, what does the Agile Principle #3 say?
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”
I suggest you replace the word software for product to not get too obsessed with code and because Agile today can be applied beyond the software industry with success.
I also find the beauty of this principle is not clear to the untrained eye sometimes. For that, let’s dissect the principle a bit.
Deliver working software frequently
Back in the 1990’s it could take a few years until the customer would see the working software _ the product_ and it was not uncommon that there were defects or asks for change after waiting for so long. That is because the needs and wishes changed after all that time. And also because all discussion happened on top of documents and contracts. Ideas and words are great, but they are not the same as touching the product.
Seeing the product in action evokes a much different response. The product actually functioning, even if it is in a raw state; not broken. You verify functionality. You verify quality. Actionable feedback is given on concrete things, not on ideas.
And the principle says regularly, frequently – the importance of constant feedback. Do not develop your products in a vacuum. You develop something for someone. So give that someone a chance to give you their opinion on how it’s going. It benefits you as much as it benefits the customer because it’s them that you want to please.
From a couple of weeks to a couple of months
This was shocking 21 years ago. Couple of months? Couple of weeks? That was so outrageous!
The sad reality is that it is still challenging for some organizations today. Sure, they operate in “sprints” of 2 weeks, but what actually gets built and shown off on that timescale? Sometimes it’s built and not tested. Sometimes it’s just ideas.
Of course, 2 weeks or 2 months is a suggestion of possible timescales and you should see where it all fits for you and your teams and your company. But imagine if you only seek feedback every 6 months! You have only 2 opportunities for feedback and improvement… in a whole year.
Remember that feedback is learning: learning about the desires of customers, learning about their taste, their buying habits. Learning about what works as much as what doesn’t work. In a fast-paced world, you want fast-paced inspection and adaptation.
Why a preference for a shorter time scale?
Remember in school at least every month and then per quarter we have those exams and quizzes? Why so often? To avoid the cognitive overload of having to know everything from the year! I certainly would not be wanted to be quizzed for a year’s worth of Linear Algebra!
It turns out it is the very same for Agile product development. You want to correct and adjust, or you want to continue doing what you are doing because it’s working. In either case, you want to learn, and we learn best in smaller chunks.
A shorter timescale allows you to see small steps in changes:
- It’s cheaper because you did not develop a ton of stuff yet.
- It is less risky, because if you are doing something wrong you can catch it pretty quickly.
- And it is easier to consume too, small bites. We won’t be missing _or hiding_ any pieces because we can see what has been added or removed since last time, since not that much time passed.
Have you tried to become better at running or at the piano, when you do it only once a week? How do you think it compares to those doing it 3x a week or every day in small chunks? It is the same principle; learning is learning. And humans learn in the same way for their profession or for their hobbies or their lives. Frequent and small is best.
Now what?
Now that you understand the need for shorter feedback loops, what do you do? Do you start adopting iterations of 2 weeks now, like all other companies are doing?
You could. It is a common practice these days and the technology available allows for that. But the most important thing I find is: consider what is a reasonable amount of time for your teams today. Maybe a month, 4 weeks? It is fair enough!
Then my next question will be: how might you shorten it?
Putting the question exactly like that implies that there is a way to shorten it. Take a leap of faith with me here: there is always a way. And is very common that what stands in the way of you being able to deliver your working product faster is a bump in your process: some weird step that no one understands, red tape of approvals, deep hierarchy and long-winded decision-making, poor use of technology. And sometimes what stands in the way is a way of thinking about your development process. Sometimes we just think in a way that is no longer as beneficial. And whatever it is you have to commit to clear that path for your frequent and short iterations to happen.
So let’s say, now you are able to deliver something in one-month iterations, and you’re working for reducing a week from it. That plain and simple is you improving your development process. It’s a two for one. You get better and you satisfy your customers faster. Even if it’s an internal customer.
You might notice that strong collaboration makes a difference when you are trying to adopt the shorter timescale that is possible for you. Collaboration among team members. Collaboration across departments.
Stay tuned. That is something for the next Agile principle!
As I close this post I invite you to be bold and start asking the question around: how can we make our iterations shorter?
