Make Haste! Slowly...

Agility is a highly valued attribute in the fast-paced field of product development. Agile approaches enable teams to efficiently provide high-quality solutions while adapting to changing needs. However, in the middle of the pressure to meet deadlines and produce swiftly, an ancient Roman idea known as "Festina lente" serves as a useful reminder: making haste slowly is a key to successful agile delivery.

Festina lente

Festina lente, means "make haste slowly" in Latin. It is a reminder to challenge our teams to strike a balance between speed and caution. It serves as a reminder that rushing into development without a solid basis can result in costly mistakes and missed opportunities or outcomes. I hear many teams complain that meetings slow them down. What if we didn't call it a meeting? What if we called it an activity for you to understand a bit more about the problem you are trying to solve? Would that feel like a waste of time?

I often hear developers or managers say "I just want to get in there and start coding!". CODE WHAT? What are you going to code? If we don't understand the problem, we likely will write more code than necessary. Our goal is to write no code if we don't have to. Learning more about the problem at hand and collaborating through our diverse thoughts on how to solve the problem can lead to a much better solution. Festina lente encourages teams to value thorough planning, collaboration, and incremental progress above reckless haste in the context of agile delivery.

Festina lente underscores the significance of deliberate planning before diving into development. Agile teams should spend time learning about the project's goals, scope, and requirements before breaking them down into manageable iterations. Planning and prioritizing tasks sets the scene for successful delivery. We often view those activities as anti-agile simply because of the idea that we shouldn't spend a lot of time planning.

The more time we spend planning the less time we spend building product. I agree with that, but recall the agile manifesto encourages responding to change over following a plan. This is often misunderstood as "no more planning". This is not the case, planning is everything. It gets us all on the same page and working towards a common goal. The output of planning (the plan) is not the goal. It can be thrown away and changed as needed, but it certainly doesn't mean we shouldn't plan.

Collaboration and Communication

Festina lente emphasizes the importance of collaboration and effective communication within agile teams. Regular meetings, such as daily stand-ups, backlog refinement activities, and sprint reviews, provide for goal alignment, problem solving, and keeping us on the same page. Engaging stakeholders throughout the process ensures that their input is taken into account and that expectations are handled or mitigated as early as possible.

Quality

Moving slowly implies prioritizing quality over shortcuts. Agile teams must commit to writing high-quality code and testing thoroughly at all stages of development. Teams develop confidence with stakeholders and ensure that the given product satisfies expectations by prioritizing reliability and stability to make it easier to move faster in the long run because we are more efficient.

Festina lente promotes introspection and adaptation as a means of continuous improvement. Agile teams should examine their processes on a regular basis, looking for opportunities for improvement and implementing changes progressively. Adopting a culture of continuous learning and improvement allows teams to adapt and improve their delivery capabilities.

Teams can ensure that the software meets the specified quality contracts by devoting time to thorough planning and testing. This decreases the possibility of rework, customer discontent, and expensive post-release issue fixes. In addition it ensures that our contract of quality matches the risk of missed items. For instance, if you are launching a new pace maker software, your testing contract is strong. One small issue and someone can loose their life, that requires a higher grade of testing before a release. If I am building an online movie ticket program and by some edge case issue you were assigned the wrong seat, that is a little less problematic than loosing your life; our testing contract should match the risk associated with the issues.

Quality in collaboration is improved because Festina lente supports open communication and collaboration among team members and stakeholders. This increases trust and leads to more effective decision-making across the agile delivery process as we tend to have co-ownership of the deliverables and process to deliver.

Adaptability

Agile techniques live on the ability to embrace change. Festina lente advises teams to thoroughly evaluate the impact of changes before implementing them in order to avoid making rash judgments that could compromise the project's success. It encourages teams to consider the ramifications of change requests before implementing them and allowing our stakeholders to have a say in the risk that will be brought on by the change. They are in control of scope / schedule, developers simply advise on risk of changes.

Agile should embrace change. I agree. In fact principle number two of the Agile Manifesto states that we are to:

"Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage."

I wish we would pay more attention to the customer's competitive advantage line. We shouldn't change just for the sake of change, we should make changes that ensure a competitive advantage. In addition, I wish we could add a comma after this statement and say "it is not without consequence". Any changes should be evaluated in effort by the developers and presented in a way that reflects consequences to the over all plan.

The stakeholders have a final decision to merit the changes against the risk associated. Slow down, let's evaluate the change, and make sure stakeholders are aligned with the consequences of the change. We don't need a big change control board meeting to evaluate this either, it can be done efficiently.

Closing

My experience shows me that many people misinterpret agile as "going faster". I don't disagree that in the end we likely are going faster than other methods. Michael Mah has done some great studies on agile projects and found that agile projects deliver 16% faster than other methods. This used to be 35% faster a decade ago. The reason is not because of the process though. The process / values that we embrace help, but people are the reason any significant change happens. People embrace the methods and find ways to make themselves more efficient through the process. Agile principle number 12 says it clearly:

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly

It is because of this that allows our teams to find better ways of working, more efficient ways of collaborating, and embracing great engineering principles to make solutions stronger and easier to adapt later. This is the reason we go faster. So I think some have it right when they say we have to slow down to speed up. This is heart of Festina lente!