AGILE – A Primer

You've probably heard about agile methods or the agile method. Some perceive it as yet another fashionable methodology, which is difficult to adapt to their context. Especially in the context of a fixed price contract. What exactly is the agile approach? Where is it from? How does it apply concretely?

What is an agile framework?

Extending agile practices across the enterprise can be a complex operation. This should not be the case, however, if you apply an adapted agile framework. Imagine this agile framework as a plan for adopting and deploying agile methods across your organization. Each framework provides a set of organizational and procedural parameters that help your teams organize and follow the path of agility with confidence. The most popular agile frameworks are SAFe (created and owned by Scaled Agile Inc., a CA Technologies partner), DAD (Disciplined Agile Delivery, now Disciplined Agile 2.0, created and owned by the Disciplined Agile Consortium), and The SS (Large Scale Scrum, created and owned by The LeSS Company BV).

How agile methods work

Agile methods assume that specifying and planning the details of an entire product before developing it (predictive approach) is counterproductive. The idea is to set a first short-term goal (a big city for example) and get on the road without delay. Once this first goal is reached, a short pause is made and the itinerary is adapted according to the current situation. And so on until reaching the final destination. We are talking about an empirical approach. As part of a software development project, the customer develops his vision of the product to be produced and lists the features or requirements of the latter. We submit this list to the development team, communicate directly with them (rather than by paper) who estimates the cost of each item on the list. We can thus get a rough idea of the overall budget.

The team then selects a portion of the requirements to be achieved in a short time portion called iteration. Each iteration includes design work, functional and technical specification when needed, development and testing. At the end of each of these iterations, the partial but usable product is shown to the client. The latter can then realize by himself very early work done, alignment on need. The end user can project himself into the use of the product and give valuable feedback for future iterations. The visibility thus offered is key. This transparency can also bring more trust and collaboration in the customer / supplier relationship.

If the customer has carefully prioritized his need, he can seize the opportunity to accelerate the "time to market" if he considers that the product in the (partial) state can go into production. Saving money and earning a return on investment. It also has the ability to change the priority of the features that have not been developed (planned for future iterations) along the way. In order to delay a functionality that is not needed, add a new crucial feature in exchange for the withdrawal of another (thus respecting budget and deadlines), etc. This flexibility thus offered is therefore a real asset for both the customer & Product Owner.