Do you still remember the twelve principles of the Manifesto for Agile Software Development? Me neither! At least not until they somehow popped up on my screen last weekend. And my first reaction:

Then I started to think about what each principle would mean for me in an ideal world and how I have sacrificed almost every single one of them at some point in time.

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

Satisfy the customer through valuable software

• Do not just build what the customer wants but what he needs.
• Create value with your software.
• Do not try to sell CRs for the sole purpose of making more money. Increase the value of the software.

#2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Welcome changing requirements

• Seek feedback all the time and as early as possible.
• Don’t be afraid to raise concerns even late in development.
• Talking about the budget or CRs too early can disturb or destory rather meaningful discussions.

#3 Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Deliver working software frequently

• Deliver - not only present. Provide a running and stable system with the latest features that the customer can use.
• Make it part of the process that the customer plays around with the new features and gives feedback.
• Try to get real user as soon as possible (MVP) - Only real users will give real feedback.

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

Work together daily

• Do not work in isolation.
• Work as a pair or group whenever useful.
• Use reviews of all kind to share knowledge and get feedback.
• The team is not only the devs. Work closely together with POs, testers, UX and the customer (if possible).
• Share a team room whenever possible.
• Communicate with the whole team. Not just about business but also personal matters.
• When working remote create space for interhuman relations. A team needs some off topic chit-chat!

#5 Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

Motivated individuals

• Feedback-loops to increase recognition and gratitude.
• Help individuals to accomplish personal goals.
• Celebrate successes and embrace failure.

#6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Face-to-face conversations

• Provide room and tools for collaboration.
• Avoid misunderstandings and communication problems:
  Face to face > phone call > instant message > mail.

#7 Working software is the primary measure of progress.

Working software is progress

• Functional valuable features delivered and customer satisfaction is true progress.
• Other things can be measured and evaluated but at the end of the day that’s what counts.

#8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

A sustainable pace you can maintain indefinitely

• Do never(*) work overtime.
• “Sprint” is a stupid word. You should not be exhausted after every iteration.
• Find a pace that the team can maintain long time without burnout. Including holidays and sick leave.

(*) Never is a strong word only used here to make a catchy statement. Common sense, people.

#9 Continuous attention to technical excellence and good design enhances agility.

Technical excellence and good design

• Time invested in good design is almost priceless.
• Encourage knowledge exchange and discussions.
• Throw away early, refactor later.
• Don’t shy away from taking external help in the early stage if needed.

#10 Simplicity — the art of maximizing the amount of work not done — is essential.

Simplicity - maximizing the amount of work not done

• Find the bare essence of the requirements.
• Reduce unnecessary noise and gold plating.
• Clarify what is required to satisfy the need. Aim for clear goals.
• Deliver fast, get feedback, improve. (80/20 rule)

#11 The best architectures, requirements, and designs emerge from self-organizing teams.

Self-organizing teams

This seems to be the hardest and totally uncommon: Let the team decide how it will work - not the management.

• Let the team decide on the best fitting team composition according to circumstances.
• Scrum as a guideline not a dogma.
• Agile does not have to mean Scrum at all.
• Sprints do not have to be two weeks.
• Not every team needs a Scrum Master.
• The standup is for the team not the management.
• Definition of Done is defined by the team and maybe not even necessary.
• Do not dictate a quality assurance workflow. Hold the team accountable for the results.
• Provide the team with some fun-budget - no questions asked.

#12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Reflect on how to become more effective

• Not just in the retrospective meeting. Start listening to the problems mentioned in the daily standup.
• Put some effort into retrospectives.
• Always derive smart actions.
• Pain that “can’t be changed” can be changed almost always.
• Automate to save time and reduce errors.
• When something is painful do it more often. Releasing a new version is painful? Do it every week friday afternoon. Automate and streamline until it runs so smoothly you hardly even notice it anymore.

In software development “Agile” is like the ugliest word of the year - every year. A buzzword so misused that many devs are sick of hearing it. But besides all that consultant gibberish I think from time to time we all should remember what agile originally stood for - true values.

Now that was a nice refreshment. I plan to update this list from time to time now. Maybe I can add some more hands-on points over time.