- You are here:
- Home »
- Glossary
Glossary
Here is a glossary of terms relating to agile, technology, software development, business and strategy.
Continuous Delivery: A set of practices around releasing software that focuses on small, very frequent deployments. It is considered very important to implementing Agile in an organisation, since it allows for small batch sizes and rapid feedback cycles. Implementing it requires Continuous Integration and high levels of automated testing.
Continuous Integration: very closely related to Continuous Delivery; Continuous Integration (CI) is a set of practices that requires developers to frequently integrate their local code with the master codebase, rather than working in isolation and integrating in a big-bang approach (leading to what is known as “integration hell”). It is impossible to achieve Continuous Delivery without first implementing Continuous Integration.
CRUD: an acronym for Create Read Update Delete. These are the four basic operations or transactions that can be performed (creating data, getting the value of that data, changing some data, deleting some data). Some people believe that software components should be responsible for just one CRUD operation, though this is often difficult, especially when dealing with complex business processes.
Cycle Time: A concept from Kanban and Lean Manufacturing. Cycle time is the time it takes for a system to produce one unit of output, from the time that work commences on it. Related to but not the same as Lead Time. Cycle time measures the production efficiency of a system.
Gemba: a concept from Lean Manufacturing; Genba means “in the real place” in Japanese. The idea is that management should inspect their company, its people and processes by direct physical inspection, by walking around and looking at things, rather than reading reports or spreadsheets. Frequent Genba walks are an important part of Toyota’s management principles.
Iron Triangle: a concept from Project Management, that describes the three fundamental constraints of a project: Scope, Cost, Time. Some think there should be a fourth “corner”: quality. Most Waterfall projects begin by defining and fixing the scope, and from that, derive the time and cost. Most agile projects begin by defining and fixing the cost, and from that back out the time (since one is a function of the other), and try and deliver as much scope as possible within that constraint.
Kanban: a set of theories originating in Japan around describing an optimal workflow. Kanban is a simple but profound concept that has been very influential in Lean Manufacturing and, later, in many areas of Agile software development. The core ideas in Kanban are pulling instead of pushing work, breaking workflow into discrete “states” (which are often mapped to swimlanes on a visual management board aka Kanban board), and optimising flow by implementing WIP (Work in Progress) limits.
Lead Time: A concept from Kanban and Lean Manufacturing. Lead time is the time it takes for a system to produce one unit of output, from the time that unit of work goes into a queue. Related to but not the same as Lead Time. Lead time is a function of the production efficiency of a system in relation to the demand of work put into the system. Lead time is usually larger than but can never be smaller than cycle time.
Lean: this word can mean many things in many contexts, but usually refers to a set of Japanese management practices known as Lean Manufacturing. This originated in Japan in the 1960s, inspired by US management theorist D Edward Deming. Lean emphasises small batch size, visual management, pull rather than push flow, just-in-time inventory and continuous improvement. Although not directly related to Agile (it came decades before), many ideas from Lean have cross-pollinated into Agile practices.
Lean Startup: An influential book and now set of ideas by US writer and entrepeneur Eric Ries. The book proposed that startups (companies operating under conditions of “extreme uncertainty”) need to operate under a very different model to traditional businesses: their objective is not to build great products, but to very quickly release a Minimum Viable Product, a slimmed down product which can be used as a basis for learning about customers and what they value. This is based around a process known as Build-Measure-Learn.
Microservices: an evolution of the Service Oriented Architecture pattern, microservices involve breaking down SOA services into even finer grained components, often responsible for just one CRUD operation, that are built, deployed and versioned separately. This could aid in the adoption of Continuous Delivery.
Minimum Viable Product: a key concept in the Lean Startup. A Minimum Viable Product, or MVP, is the smallest increment of product that can be produced and shipped that provides validated learning.
SOA: Service Oriented Architecture. This is an architectural model that became very popular in the early 21st century. It involves breaking large monolothic enterprise software systems into a collection of discrete, loosely coupled services. Many organisations found SOA to be very complex and expensive to implement, although it still has some fanatical evangelists. SOA is recently beginning to be replaced by Microservices.
Test Pyramid: a concept from the Agile testing community that breaks tests into three categories of tests, and how many you should have of them. At the top of the pyramid is a small number of UI tests: these test a system end-to-end from the very top UI layer all the way down the stack. The middle layer is a larger collection of service or integration tests, that bypass the UI and directly test code via service or API calls. Below that is a very large suite of unit tests that test code at a fundamental level. Many organisations doing Waterfall invert the test pyramid: they have a small number of unit tests, a larger suite of service tests, and a huge amount of (usually manual) UI testing. Having a proper test pyramid is crucial to achieving Continuous Delivery.
Visual Management Board: also known as VMB. A board (usually physical, sometimes digital) that is used to track work items (usually user stories), on horizontal and vertical swimlanes (sections of the board). The horizontal lanes usually represent features, and the vertical lanes usually represent states of work.
Work In Progress: also known as WIP. This term is widely used in Lean and Kanban circles, and describes how many units of work are currently being worked on in a given state or part of a system. Many Lean practitioners are often focused on reducing WIP, since a system or sub-system can usually only process a small number of units of work at a given time, and putting more units of work into progress usually just results in confusion, stockpiles and waste. In Agile software development, WIP Limits (a maximum number of user stories) are sometimes applied to vertical swimlanes on a Visual Management Board.
