Show Menu

12 Agile Principles Cheat Sheet (DRAFT) by [deleted]

12 Agile Principles

This is a draft cheat sheet. It is a work in progress and is not finished yet.


If you’re curious about the origins of Agile, then it’s best to go back to the Agile Manifesto, created by seventeen software developers in 2001. The manifesto can be summed up by four core values:

Individual intera­ctions over process and tools
Working software rather than thorough docume­ntation
Collab­oration with customer instead of contract negoti­ations
More than following a plan, respond to change.

Delving deeper than what they value in a project, the writers of the manifesto agreed on 12 princi­ples, which further defines how to run an Agile project

1. Our highest priority

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

By shortening the time between docume­nting the project, reporting to your customer and then getting feedback, you can focus on the real goal of the project, which is delivering what the customer wants, not what you planned.

2. Welcome changing requir­ements

Welcome changing requir­ements, even late in develo­pment. Agile processes harness change for the customer’s compet­itive advantage.

Embrace change. Even when the customer requests a change late in the project phase, implement it. Why wait for another project to explore another iteration when you can do it now and get the results immedi­ately? Agile wants you to stay nimble and on your feet so you can pivot without having to constantly reinvent the wheel.

3. Deliver working software frequently

Deliver working software freque­ntly, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

If you’re going to embrace change, then you’re going to have to give up on your etched­-in­-stone schedule, or at least create a shorter range to run your tasks. One way Agile does this is by cutting out a lot of the docume­ntation that is required with tradit­ional project management when planning your schedule before you ever start a task. The trouble is a lot of that paperwork isn’t necessary. It only slows things down.

4. Business people and developers

Business people and developers must work together daily throughout the project.

It’s like they’re talking two different languages, and in a sense, they are, but both the business and developer side of the project are crucial to its success. You must build a bridge between the two so they can understand each other and, as important, work together. Use the same tools you would manage remote teams to facilitate an exchange of ideas that both sides understand and are on board with.

5. Build projects around motivated indivi­duals

Build projects around motivated indivi­duals. Give them the enviro­nment and support they need, and trust them to get the job done.

In other words, don’t microm­anage. It doesn’t work. It takes you away from what you should be focusing on. It erodes morale and sends talent packing. You assembled the best, now let them do what they’re good at. If you did the due diligence before­hand, then you can trust them to do the work. Of course you’ll monitor that work, and step in as needed, but stay out of their way.

6. Face-t­o-face conver­sation

The most efficient and effective method of conveying inform­ation to and within a develo­pment team is face-t­o-face conver­sation.

Docume­nting conver­sat­ions, creating email narrative streams, even using collab­oration software like Slack, are all well and good. But when you’re trying to move swiftly, you don’t have time to wait for a reply. You need immediate answers, and the only way to achieve that speed of response is by talking to your team member or team in person. You can do this by working in the same physical space or having distri­buted teams. But if it’s the latter, you want to try and keep the schedules to the same hours, so you can at least video confer­ence. That creates a more collab­orative enviro­nment.

7. Working software is success

Working software is the primary measure of progress.

That means, is the software (or whatever product or process you’re working on in the project) working correctly? You’re not measuring progress by checking off tasks and moving across your scheduled timeline, but by the success of the software (or whatever) is the subject of your project. Basically, it’s staying focused on what’s important. The process is what gets you to achieve the goal of the project, but the goal of the project isn’t the process.

8. Promote sustai­nable develo­pment

Agile processes promote sustai­nable develo­pment. The sponsors, developers and users should be able to maintain a constant pace indefi­nitely.

One reason for short sprints of activity is not only that they lend themselves to accepting change more readily, but they also help to keep your teams motivated. If you’re working on a project for an extended period, there’s going to be burnout. It’s unavoi­dable. Don’t overtax your team with too much overtime. It’s going to impact the quality of your project. So, get the right team for the job, one that will work hard but not overextend themselves and put the project quality in jeopardy.

9. Continuous attention

Continuous attention to technical excellence and good design enhances agility.

Whether you’re working on code or something more concrete, you want to make sure that after each iteration it’s improving. You don’t want to have to come back and fix things later. Fix them now. Better still, make sure they’re getting better. Use Scrum, an Agile framework for completing complex projects, to help review and keep the project evolving

10. Simpli­city—

Simpli­cit­y—the art of maximizing the amount of work not being done—is essential.

If you’re looking to move quickly through a project, then you’re going to want to cut out unnece­ssary comple­xities. Keeping things as simple as possible is a great ethic to streamline your process. You can do this many ways, including the use of project management tools that cut out the busy work and give you more control over every aspect of the project.

11. The best archit­ectures

The best archit­ect­ures, requir­ements and designs emerge from self-o­rga­nizing teams.

When you have a strong team, you want to give that team the autonomy to act indepe­nde­ntly. This means they can adapt to change quicker. In fact, they can do everything with greater agility because you’ve given them the trust to act without second guessing them. If you’ve done your job in collecting the right people, then they’ll do their job addressing issues and resolving them before they become problems.

12. At regular intervals, t

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accord­ingly.

Another benefit of creating a well-r­ounded team is that they will stop, reflect and tweak the way they do things throughout the course of the project. They don’t act by rote or just blindly follow protocol, but think through their relati­onship to the project and adjust when necessary. The last thing you want is a complacent team, one that stands on their laurels. What you need is an ever-e­volving group that is constantly engaged and looking for ways to improve produc­tivity.

Support Cheatography!