Agile Terminology?

Domain Language

If you're starting something new you need to know how to speak the lingo, if you don't it's easy to make false assumptions which cause confusion down the line. In Agile, there is no down the line, so you must understand the intent behind the terminology upfront.

There are various terms which are used and these form part of a domain language. Not everyone will agree with my descriptions, but this is not an article on the fine detail of terminology.

E.g. What is a customer? Someone paying for the service or product? Well yes. But it may be a sub-section of your customer, or customer persona, or someone wanting something very specific, it may even be your boss, or could potentially be you.

Contained in this article are some of the common terms I use on this site. To avoid confusion, I've written up my intent behind them.

The Customer

In Agile, you're looking at delivering value to a customer. In a traditional mindset, you're looking at fulfilling customer needs by producing a product or service.

Thing is, this is not only a guide on delivering to a paying customer, this is a guide on the utilisation of an Agile mindset, which means the customer may be someone paying for a product or service... but may also be focused on delivering a better way of forecasting for your boss... or getting more paying traffic into your shop. This mindset transcends just business, thus the customer is anyone who is going to realise an element of value from your efforts. As we are looking at delivering small increments of value, the definition of Customer must be clearly focused.

A customer is the explicit part of a person who will benefit from the item of value you are delivering. In Agile we break down the process, we can't service all the customers needs, we service one individual need of the customer.

Value

This is what you are delivering to a customer. In a traditional sense you would be delivering a product or service to a customer. The customer asks for a car and you deliver a car, you think your customer wants a new pair of trainers, you produce a new pair of trainers.
We've identified the solution the customer wants and have set about delivering it, this style of delivery is known as fixed scope.
The problem with fixed scope, is it usually means a large cycle between the idea being had, and the delivery of the product.

Delivery of Value is a different proposition, we're now focusing on the individual elements of value which make up a bigger solution, not slicing a big solution into small chunks which serves a lot of value.

Iterations and Increments

An Iteration is a timebox where an Increment is completed.

This is a fairly simple concept, we set a timebox, say 2 weeks. Then we completely finish an element of work within 2 weeks, that element of work would service a customers need. An Iteration should be short, between a few days and a month with a preference to shorter timescales.

An Increment has a rule, it must be complete, so no more work to do on it, no extra testing, no tidy up later down the line, it's done, put to bed and we can give it to the customer or deliver it as a service.
However, just because we could deliver that product or service, it does not mean we have to deliver that product or service. The critically important point is we could. This is known as Release on Demand.

An Iteration also has a rule, the length of it does not change part way through. If you've decided on 2 weeks, it runs for 2 weeks. If you don't complete an Increment in that Iteration, you don't extend the Iteration you start a new one. Once complete, you assess the work done, and address the amount of work going into the next Increment. In very exceptional circumstances the timebox of the next Iteration may be changed.

Incremental Delivery

Delivering a large product may seem the only way to go, but you can't be Agile if you can't change direction.

Incremental Delivery is building upon what you have at each stage, to build value up in increments which can be delivered on demand. Not, you can have this in six months. But we'll give you something next week, and the week after, and the week after, etc...

Say we're opening a restaurant, your customer is someone who wants feeding. But we can't serve the needs of every type of customer and open the restaurant quickly. The easiest thing may be to deliver quickly cold sandwiches which can be produced quickly. Then we extend this to hot sandwiches. Then extend to jacket potatoes. At each stage we deliver something and service the individual needs of the customer individually. Incrementally changing direction after each iteration.

This might sound ridiculous, but to open a restaurant is expensive and a big risk. If we open it and serve the wrong type of food, the customers may not come. By delivering incrementally we're validating what the customer wants each iteration and expanding our offering.

Incremental Architecture

Most things you do will need supporting infrastructure or tools. Incremental Architecture is the minimisation of the supporting stuff you invest your time and money in.

All too often this is totally overlooked, but is very important. Take a new hobby, you've decided on starting surfing, so you go out and buy a new surfboard, a wetsuit, some sex wax, some tribal looking UV sunscreen, a new roofrack, a surfboard bag, etc...
You go surfing 4 times. The weather changes, you don't go again for 8 years. You tell yourself that £1000 you just spent was well invested as you can go anytime you want.

We want to embrace the term Just Enough. In Agile we are delivering small items of value frequently, the supporting stuff needs to be kept to a minimum as well. The value to you becoming a surfer, is to surf. The first time you go the minimum you can do to surf in cost and effort is to hire a surfboard, or borrow one from a mate. If you do it 4 times then give up, the cost is a fraction of buying all the equipment you need to surf. If you start to enjoy it, you may buy some sunscreen as it's hot, you're investing incrementally.

In software development over-architecture happens all the time. 'We're an Agile development team', but as soon as the project starts the team spend 3 months building servers and environments, automated pipelines and tests, server farms to cope with the huge load you're anticipating, without delivering a single thing to the customer.

Incremental Architecture is about supporting only your immediate needs to deliver the value that is required now, no more, no less. Be considerate of the future, but strive to cut out all over-architecture and over-investment, and using assumptions about the future as your excuse. In Agile the future is likely to change, thus all supporting work and setup should be done at the same time as delivering the value required at that time.

Inspection and Adaptation

Inspection and Adaptation (very similar to Kaizen) is the practice of doing something, learning from it and using that knowledge to make a decision on your next move. This is the basis of any empirical system. To be Agile you must inspect what you have done, and adapt based on the knowledge you now posses.

By creating an Increment of Product or Service in an Iteration, we can easily Inspect what we have delivered to the customer, and Adapt based on what we now know to create our next increment.

This also extends to process, at the end of an increment, did we do everything right to deliver that product or service, how can we do it better next time?
... and extends to marketing, was the marketing right for this product or service this Iteration, and how can we do it better next time?
... and research, did we fully understand the value proposition for the customer, and how can we adapt to get better.

Obviously you can't Inspect and Adapt everything, but the optimisation of process, metrics, value discovery, and value generated should all be prime targets for Inspection and Adaptation.