A Dictionary of Agile Language (updated)
The importance of language is inevitable. Finding the right wording, which is expressing exactly what we want to say from a context point of view, but also from a emotional point of view. The agile development space is an area of application, where this comes true notably.
We just need to recall, that we use language not for talking only – in our mind the same language is used already when we start thinking.
Besides the central word agile itself, the community of agilists has created their own dictionary, where new terms have been selected, which helped to add a new meaning to the idea of agile development. Agile is in the end about mindset. It thereby required a languages, which supports the mindset.
Language even can be the accelerator for the agile mindset. While several people are talking about the value of “agile” itself, others continue to evolve the ideas and develop new ideas and concepts around the agile core. Continuously, new terms are being put in place, which are meant to emphasize deviations from traditional approaches.
The other way round, understanding the language can help to gain a better understading of the agile mindset. It is worthwhile to start to collect the terms and explain the meaning behind the new terms.
The Dictionary of Agile Language
The dictionary of agile language is a lineup of agile terms and there counterpart in traditional approaches, which are still very common to many people and projects. For that reason you can find for each of the items a short explanation, how the new agile terms are meant to provoke a change in mindset:
“People” was “Resources” – agile puts the importance of the contibution of individuals in the center and not the plain workforce
“Investment“, “Bet” was “Project” – agile emphasizes the the process of creating value continuously rather than working towards a given plan
“Supporter“, “Facilitator” was “Manager” – while traditional approaches ask for managing people, who are supposed to ensure goals and progress, agile approaches advocate self-organized teams, which look for leaders, who support them or which can be facilitated to achieve their objectives
“Team” was “Expert” – other than with traditional approaches, where experts have been put in the center of planning, the agile approach is team based, where members have to decide on themselves, how they can contribute the best way (keyword “t-shape profile”)
“Ambition” was “Estimation” – agile teams have ambitions to bring meaningful products to customers following an affordable approach, while traditional teams start with estimates with the intend, to make plans visible and traceable
“Check Point” was “Deadline” – while traditional approaches work towards plans, where deadlines determine the dates, where results are to be delivered, agile approaches consider to have regular check points, where deliverables are challenged, if they are sacrificing needs
“Virtual Coffee” was “Workshop” – whenever people in an agile environment consider to have a problem addressed, they invite for a virtual coffee, where the issue is discussed amongst them, whereas traditional environment ask for the organization of a workshop, where all stakeholders are asked for bringing their input and find a solution
“Increment“, “Iteration” was “Release” – traditional approaches assume, that deliverables need a release process before they can be handed over to customers in a reliable and reasonable way, while agile teams offer frequent increments, where small iterations can be pulled, evaluated, and consumed by customers immediately
“Purpose” was “Task” – traditionalist think that teams need to be told what to do, agilists believe that telling teams the purpose of what is to be build will leave the decision on the approach with them
“User Story“, “Backlog” was “Specification” – agile works with prioritized list of functionality expected by users, while traditional approaches work with a documentation describing a big picture and all relevant aspects of a solution
“Chickens and Pigs” was “The Boss” – agile provokes giving power to committed development teams (the pigs) to decide how things are done and restrict influence of requestors contributing the requirements (the chicken) on these decisions, whereas in the traditional setups the boss is the major instance who has the saying what is to be done and how things are done
“Retrospective” was “Lessons Learned” – agile people meet on a regular basis and discuss what works well and what can be improved, while traditional projects ask team members to reflect on issues and improvements after deliveries (releases)
“Stand Up Meeting” was “Status Report” – what is going on, planned next, and hindering progress is discussed in frequent (daily) stand-up meetings in agile processes, whereas the boss is collecting a status and sharing a status report on a regular (weekly) basis to provide updates
“Fail-Fast” was “Acceptance Criteria” – agile provokes to test-run implementations as soon as possible to detect failures and take action immediately, whereas traditional projects define an aligned set of acceptance criteria upfront, which gets verified at the end of a project (deviations are argued and adherent projects planned where necessary)
“User Persona” was “Stakeholder” – in agile people to derive solutions from the situation, challenges, and needs of typical users, whereas in traditional projects stakeholders (like key accounts or project managers) are asked to define the requirements for the solution
“Built-In-Quality” was “Quality Assurance” – the results from a product increment must be potentially shipable is one of the agile paradigms, which implies that teams have to take care for quality from beginning, whereas in traditional approaches quality assurance is a discipline on ist own, where dedicated team test and validate the quality of the results from a project in a subsequent step
An interesting observation is the use of new terms, which do not have a counterpart in the traditional approaches. They came up because of the iterative/incremental approach agile is provoking:
This list is the second version of the attempt to create a dictionary of agile language. I hope it will find more contributors and grow – the agile way. I am pretty sure, there is more to add. Please make use of the comments to amend.