The original “agile manifesto” has been, by far, the most dominant force the past decade on how organizations and teams go about designing, building, and maintaining software systems. It provides a basis for which requirements, communication, and organization are built around. The manifesto has spawned a “dizzying array” of well defined methodologies and frameworks, each with their own set of rules, rituals, and practices. Scrum, SAFe, XP, Kanban, Lean, and on and on. These frameworks have their purpose and situations where they shine and provide value. They also have situations where they introduce too much complexity and rigor where at the end of the day, the answer to the question “Does this make us better?” is “No”.
The manifesto
Answering the question “Does this make us better?” is fundamental at Leaf and why we subscribe to following the principles of the agile manifesto rather than adopting a single agile framework and apply it across the board.
- Value individuals and interactions over processes and tools. Processes and tools should be there to serve a team, not the other way around. Tools are a support mechanism to facilitate organization and communication but at the end of the day, the relationships and skill of the of the people involved is what will generate success.
- Value working software over comprehensive documentation. We believe that iteratively building software with frequent feedback loops will deliver software that meets the customer’s needs more efficiently and with a better results. Developers should have the flexibility to experiment with new concepts. Stakeholders should have the ability to evolve their requirements through interaction with the software to help clarify their vision.
- Value customer collaboration over contract negotiation. Ongoing collaboration between the development team and the customer supporting the iterative development of software and ensure development happens transparently and without surprises.
- Value responding to change over following a plan. We need to be nimble to respond to shifting needs – be it technical, customer, or market driven.
Post Agile
By not adhering to a single framework, we are afforded the flexibility of picking what works best for us and the customer. We incorporate practices such as daily stand-ups, sprints, Kanban flow, deploy often, automation, and retrospectives. We are able to integrate with other customers that might be invested in more formal methodologies such as “Scrum” or “SAFe”. For customers who aren’t invested (or don’t care) about a software methodology, by working with them we can derive project practices that make sense for both the development team and the customer based upon everyone’s needs and capacity. And sometimes, that can involve eschewing agile a bit and incorporating “waterfall” techniques.