Agile explained in 3 paragraphs

I said earlier (in french) that being able to explain agile in any time frame from 1 minute to 2 hours is a key to agile adoption. Sometimes it’s also in a written manner. As years goes by I have stacked some short descriptions of agile I use here and there or rewrite.
Here’s a 3 paragraph explanation I wrote for a client’s HR division, whose people had no knowledge in software development. Feel free to reuse / modify / share.

Iterative implementation
In a classic waterfall development process, the software is exhaustively described, then developed at once, then validated.
Every evolution during the project disrupt the schedule. In agile development, features are added little by little up to the wished goal, refining requirements and validating as implementation goes on. This approach enable innovating during the project, and shortens the time between idea and implementation.
For agile mode to work, the implementation organisation must remain stable : a dedicated team, stable over time ; fixed-duration iterations (one or two weeks) ; and a regular work rhythm.

The agile team
Maximum proximity of all contributors is seeked as to benefit from face-to-face communication and the best emulation possible. Through specific meeting rules and visual management, shared responsibility and self-organisation are encouraged : success is everyone’s business, and the team operates day-to-day the way that seems relevant to it.
3 roles are distinguished in agile :
– the product owner (*) defines thinly the functionalities and their relative priority of implementation
– developers are in charge of end-to-end implementation
– the facilitator run the meetings and watch after the team dynamic. This role is endorsed by either a developer or the technical manager (**).

Handling risks and work pace
Progress indicators and risk indicators are evaluated by the contributors of the project themselves. With ground people driving the project, incident and delays are detected earlier, enabling structural decision to be taken by the top management soon enough, thus reducing further rush hours. (***)

(*) I used in fact « responsable produit », french translation of « product manager », a term more suited to the client’s usual terminology. The intended receivers weren’t about to run projects themselves so I choose not parasite their understanding with our agile-specific metaphor
(**) This organisation used to put apart technical people from business one. Coaching some of the technical managers into becoming agile facilitators of their team, aka Scrum Masters, was a choice we had made in this particular organisation.
(***) … Which was a way to tell the HR that a more efficient project management, i.e. Agile, enabled a healthier way of working

Tags: Agile Coaching, Agile Consulting, Agile Management, Change, Expliquer l’agile, Management agile, Pédagogie, Pedagogy, YourTurnChallenge