Agile is useful. “Agile” is also responsible for a remarkable amount of process theatre.
The difference is usually whether a team is using the ideas to learn faster or using the framework to look busy.
For a small startup, I would begin with something almost disappointingly simple: make the work visible, limit how much is in progress, deliver in small pieces, talk to customers, and regularly fix the way you work.
You can add the fancy bits later, if you still need them.
Start with the manifesto
The Agile Manifesto is short. It values people, working software, customer collaboration, and responding to change. It does not tell you to use Jira, estimate in story points, or spend half the week in ceremonies.
That distinction matters. A process can be called Scrum and still make feedback slow, decisions difficult, and teams powerless. It can also be a plain Kanban board and support the manifesto rather well.
If your team is four people, including you, I would not start with a full Agile transformation. Put the work on a board and get something useful in front of a customer.
What I want from an Agile setup
I use Agile practices to create a few useful conditions:
- everybody can see what matters now;
- the team can finish work before starting more;
- feedback arrives while it is still cheap to react to;
- engineers understand the people using the product; and
- the team can change its own way of working.
The framework is secondary. Scrum, Kanban, or a mixture can all work. I am not fond of the full-monty Scrum setup by default, but some of its parts are useful. Take what solves a real problem. Sunset what has become a ritual.
Be agile about being Agile.
Build around feedback
The most useful feedback loop is between the people building the product and the people using it.
I like engineers to join customer sessions. They do not have to run the interview; observing a product manager or designer is fine. Seeing somebody struggle with a feature creates a different understanding than reading a ticket saying “button unclear”.
The second feedback loop is inside the team. Retrospectives matter, but only if something happens afterwards. A retrospective that produces the same complaints every two weeks teaches the team that improvement is theatre.
Pick one or two actions. Give them an owner. Check what happened at the next retrospective. As a leader, your job is often to remove the organisational obstacle the team cannot remove itself.
Keep work small and visible
Large batches hide uncertainty. They make estimation harder, feedback slower, and releases more exciting than releases should be.
Break work into the smallest useful slices you can deliver and learn from. Limit work in progress. When work starts piling up in review, testing, or deployment, do not add more work to the left side of the board. Help with the bottleneck.
This sounds obvious. It is also where many teams fail, because starting work feels productive while finishing it exposes all the difficult bits.
Use metrics as signals
Metrics can help a team see whether changes are improving the system. They can also become a very efficient way to make people game the system.
The current DORA software delivery metrics look at change lead time, deployment frequency, failed-deployment recovery time, change fail rate, and deployment rework rate. I use them to start conversations about flow and stability, not to rank teams.
The SPACE framework is a useful reminder that developer productivity cannot be reduced to output. It looks across satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow.
Do not put every metric on a dashboard because you can. Choose a small set that helps answer a question. For example:
- Are changes taking longer to reach production?
- Where does work wait?
- Are failures increasing as delivery gets faster?
- Does the team feel able to do good work?
Use the numbers with the team’s experience. If the dashboard says everything is excellent and the team says delivery is painful, the dashboard is missing something.
A small setup that works
For a new or small team, this is enough to begin:
- Agree on the outcome the team is trying to improve.
- Put all active work on one visible board.
- Set a low work-in-progress limit.
- Split work into small pieces that can reach users.
- Decide how often priorities are reviewed.
- Hold a short retrospective and act on one improvement.
- Track one flow metric and one quality or health signal.
Run it for a few weeks. Then ask what helps, what gets in the way, and what is missing.
Roles and ceremonies should solve observed problems. A daily meeting may help a new team coordinate; an experienced team may only need it a few times a week. Estimation may help with a difficult trade-off; estimating every tiny task may just produce expensive numbers.
There is no prize for framework compliance.
The leadership part
Teams cannot be Agile if every decision has to travel up and down the organisation. They need a clear direction, boundaries they understand, and authority to change how they deliver.
That does not mean leaving the team alone and hoping for self-organisation. It means being clear about the problem, the constraints, and the outcome, then helping remove the things that slow learning down.
Agile is not magic. It is a collection of habits for shortening feedback loops and adapting to what you learn. Keep those habits. Be suspicious of everything added on top.