I was recently involved in thinking of ways to introduce agile concepts to new developers (as in, completely new to software and going through a boot camp).

Many introductions go straight into terminology / ceremonies / scrum; I wanted to show the rationale and avoid the jargon; here's my attempt.

---

Agile teams are:

• Small in size (5-10 people typically)
• Cross-disciplinary - all the skills required to design and release the software are embedded in the team. Eg product person, designer, developers
• Empowered - high level project goals may come from outside the team, but the agile team should have the autonomy and skills to come up with solutions to the goals

The user is the boss

The team can only make guesses about whether the software will be useful.

Agile teams recognise that they’ll only know for sure whether a feature is a success, once the change is released to users and is being actively used.

Many of the team’s ways of working flow from that understanding, such as:

Release early

Aim to release an initial version of a feature quickly to get feedback from real users - don’t keep perfecting for weeks on end, based only on assumptions within the team.

Users usually surprise you with what they do and don’t like, and their feedback is the fastest route to improving the product.

Release often

Agile teams understand that there’s always a risk that users won’t like what has been built. The trick is to try to build each new feature as efficiently as possible, and get feedback from users as quickly as possible. Then if they didn’t like it, at least we minimised the amount of effort that was wasted.

Improve the initial release with frequent small changes (iterations). Iterations happen within short periods (called ‘sprints’) that last typically 1-2 weeks. The team should aim to have something releasable at the end of each sprint.

Develop features in small standalone chunks; agree together beforehand what will be built, and write that shared understanding down (a simple description of how the feature will work. When it’s released, we can verify what has been built against the written description. Don’t rely on memory).

Because we want to release quickly and often, we need to avoid extensive manual testing and manually deploying the software, which take much longer than automated tests and deployments.

From the moment a developer finishes writing their code, it’s realistic for the change to be live and available to users within a few minutes, even for quite mature products. Because of the focus on having lots of automated tests, they can be run in minutes against any new change before it’s released to give confidence that everything is working.

Learn quickly from users

The team frequently measures how the users are using the software:

As users interact with the software, we can make the software capture anonymised data on what they’re doing - aka ‘analytics’

Team members can interview users in person, either before development starts, or after it’s been released - aka ‘user research’

Let users give their feedback via the software eg a feedback form

Respond to change

Because we value our users’ opinions over our own assumptions, we need to be ready and able to add, change and remove features quickly based on their feedback. So responding to change is more important (and realistic) than having a fixed plan.

With this mindset, developing the ability to pivot easily to new requirements and features is very valuable. Agile teams prefer to write software in ways that let them adapt the code easily to meet new requirements. Some techniques include:

• Rely on automated tests and minimise manual testing
• Write code in smaller modules rather than one big lump. If the requirements change, many of the smaller modules can still be re-used without having to rewrite everything
• Keep the code in good shape so it can be easily read and maintained by everyone, and adapted for the next requirement

Collaborate

As you can see from all the above, things can move and change quickly. Open communication within the team is vital. The team should have ready access to someone from the business, to get their queries answered quickly; ideally the business is represented inside the team by a ‘product owner’.

When agile was invented ~20 years ago, remote work wasn’t really a thing, and face-to-face conversation was considered the best mode of communication (as opposed to via lots of documentation). With remote work, it might now be a mixture of video calls, messaging systems like slack and in-person team days.

What’s it like to work in an agile team?

• Empowering - the team has the skills and authority to solve a problem for the business
• Exciting - things move quickly. You’re not waiting months or years to release to users. The team directly monitors how users interact with the software, so can develop a real connection and empathy for them, which makes for a very rewarding feedback loop.
• Disciplined - both the software and the team need frequent attention to be kept in good shape. If the health of the codebase or the team interactions and relationships are allowed to deteriorate, the team won’t be able to maintain a steady pace. Agile teams are about sustainability not burnout.
• Reflective - it’s important to reflect frequently on what’s going well and not so well, and adjust practices to keep the team culture healthy and effective