Lesson 1: Agile Values and Principles in Plain Words

Why start with agile values?

In this course you will build a delivery system for your team, one level at a time, using Kanban and agile practice. Before any boards or metrics, you need the ideas that sit underneath them. Those ideas come from the Manifesto for Agile Software Development. Seventeen software practitioners wrote it at the Snowbird ski resort in Utah on 11–13 February 2001. It contains four values and twelve principles.

The manifesto was written for software, but it works for any team that turns requests into finished work. To use it in operations, marketing, HR or service work, read the word "software" as "finished, usable work".

Later levels draw on two other sources: the Kanban Guide (published at kanbanguides.org) and the Kanban Method (from David J. Anderson and Kanban University). You do not need them yet.

Task 1: Restate the four values

Each value has the form "X over Y". The manifesto says plainly that the items on the right still matter, but the items on the left matter more. "Over" means "ahead of". It does not mean "instead of".

1. Individuals and interactions over processes and tools. Talking to people solves more than the tool or form does. Ops example: a two-minute call with the network engineer clears an incident faster than three rounds of ticket comments.
2. Working software over comprehensive documentation. Finished, usable work is worth more than reports about work. Marketing example: a live landing page that people can test beats a 20-page plan for that page.
3. Customer collaboration over contract negotiation. Work alongside the people you serve. Do not argue over the wording of the original request. HR example: sit with the hiring manager to shape a job advert, rather than handing over a form and waiting.
4. Responding to change over following a plan. Plans help, but when the facts change, change the plan. Service example: a new product issue doubles the volume of one type of call, so the team reorders its week to handle it.

DO: Write each value in your own words in a single sentence, with one example from your own team.

Task 2: Read the twelve principles in plain words

1. Keep customers happy by delivering valuable work early and often.
2. Accept changing needs, even late. Change can help the customer.
3. Deliver finished work often, every few weeks to every few months, and the shorter the gap the better.
4. The people who ask for the work and the people who do it talk every day.
5. Build work around motivated people. Give them support and trust them.
6. Face-to-face conversation is the best way to share information.
7. Finished, working output is the main measure of progress.
8. Work at a pace the team could keep up indefinitely.
9. Ongoing attention to quality and good design makes change easier.
10. Keep it simple: get good at not doing work that isn't needed.
11. The best designs and solutions come from teams that organise themselves.
12. At regular intervals, the team reflects on how to improve, then adjusts.

Several principles (1, 3, 7 and 8) are about predictability: a steady, sustainable flow of finished work. That is the goal of this course.

Task 3: Audit your team's habits

DO: List current habits, then sort them.

1. Write down 6–10 things your team routinely does.
2. Mark two that support a principle and write the principle's number beside each.
3. Mark two that work against a principle, again with the number.

Examples to prompt you:

• Supports: a short weekly look-back on what went well (principle 12). Requesters join the stand-up (principle 4).
• Works against: starting every new request at once so that little gets finished (principles 1, 7). Regular evening work to hit dates (principle 8). Reporting "80% done" on tasks nobody can use yet (principle 7).

Task 4: Record your delivery problem

The rest of the course uses this as its reference point. A good problem statement:

• is specific, about one kind of work;
• is observable, so that you could count or time it;
• describes the effect on the people you serve.

Weak: "We're too slow." Strong: "Customers often wait more than two weeks for routine access requests, and we can't tell them when theirs will be done."

DO: Write one problem statement in this form. Note today's date and one rough number, for example "about 15 requests open; oldest is 5 weeks".

Task 5: Make one change on a practice board

To start, apply principle 7 and the first value: make all current work visible, so that the conversation is about real, unfinished items.

1. Set up a practice board. A whiteboard, a sheet of paper, or a blank board in any tool (Trello, Jira, Azure Boards, Planner) will do. Columns come in later levels.
2. Add one card for every item the team is working on now, including side requests, emails and favours.
3. Write on each card the date it started, as best you know it.
4. Count the cards.

Check the effect:

• Compare the count with what the team thought it had in progress. A large gap is a finding in itself.
• Find the oldest card and compare it with your delivery problem. Does it explain part of the problem?
• After one week, record whether status questions ("where's my request?") became quicker to answer.

Key takeaways

• The Agile Manifesto (2001) has four values and twelve principles, and they apply to any team that delivers work.
• "X over Y" means X comes first, not that Y is worthless.
• Finished, usable work is the true measure of progress. A sustainable pace is what makes delivery predictable.
• Sort habits by whether they support a principle or work against it, and name the principle each time.
• A specific, observable delivery problem is your reference point for every later change.
• First change: make all current work visible, then count and age it.