12 Principles: A Dozen Simple Rules for Agile Development

Hello!

Previously we reviewed the Agile Manifesto, the constitution of agile development, and in today's post I present to you the more direct follow up to clarify a few things. The Bill of Rights of agile development; the Twelve Principles.

The Twelve Principles of Agile Software

We follow these principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/

Looking at these principles it is clear to see a few themes emerging and being expanded upon from the initial manifesto.

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Delivering results that are actually wanted by stakeholders and maintaining a frequent flow of progress. Isn't that an awesome goal for people to strive to achieve?
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Things change, don't bitch about it. If you were hosting a dinner party, planned a hog roast and then find out all your guests are vegans. You could grumble, but people are coming across, why not dive into learning new vegan recipes? Rise to the challenge.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Show actual progress over time, it's more exciting to show gradual improvements in chunks than deliver a massive project that is no longer relevant.
• Business people and developers must work together daily throughout the project.
• Be interconnected within a team, it helps focus on the project, in a personal development setting this is incredibly important to retain accountability.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• Get team buy-in and support in a project, it helps if they're passionate about it. In a personal development setting this would suggest that you focus on something you truly see as a worthy goal. If I wasn't bothered about fitness and all I wanted to do was to read, knowing fitness is important, I would begrudgingly put it into sprints, but it would be far more difficult to reach the goals.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Be clear and honest in communication, so many times people infer so much from text when there's really nothing there.
• Working software is the primary measure of progress.
• Deliverables = progress. 
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• 'It's better to burn out than fade away' - Nope. Why not continue on the path delivering constantly. The Government Digital Service said that 'Boring is beautiful' - that's not a bad thing.
• Continuous attention to technical excellence and good design enhances agility.
•  Be mindful of following the best practices. Find and follow best practices, they're best practices for a reason.
• Simplicity--the art of maximizing the amount of work not done--is essential.
• Why over complicate things?  Keeping it simple ensures you can do it again, repeating tasks. It's easier to explain to others and it helps others understand what you're doing.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• Teamwork is good and best practices emerge from sharing resources with those you trust.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
• If you perform a task in the exact same way why would you anticipate a different reaction? Play around and find what works, find your groove and work into it. You improve your approach through revising it.

These principles work with self improvement and when reduced to their essence can work in many things in life.

You have to

• Stop
• Review what you do constantly, don't get carried away
• Collaborate
• Work within teams to achieve everything you need to, sharing resources and responsibilities
• Listen
• Work with your stakeholders, don't bury your head in the sand

With the principles and manifesto broken down it is clear that agile can be utilised in all strands of life, professional and personal.

Thanks for reading!

AT

Agile Manifesto: Personal Edition

Hello!

In today's post I thought it best to go back to the original manifesto that agile came from.

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

 

 http://agilemanifesto.org/ 

There it is in all its dandy glory, but where did it come from and what does it represent?

The Agile Manifesto was written in February of 2001, at a summit of seventeen independent-minded practitioners of several programming methodologies. The participants didn't agree about much, but they found consensus around four main values.

Supplementing the Manifesto, the Twelve Principles further explicate what it is to be Agile.
http://www.agilealliance.org/the-alliance/the-agile-manifesto/

So, the agile manifesto is like the US constitution and the Twelve Principles is similar to the Bill of Rights. Let's examine the manifesto and then see how these principles can be applied to personal development. The manifesto focuses on valued areas and promotes some concepts over others.


Individuals and interactions over processes and tools


This states that the human element is more important than the machine they are a part of. Yes we are awesome little snowflakes, completely original, but we work so much better and have much greater impact combined together as a snowball; and there are many ways to make a snowball.
 
Working software over comprehensive documentation


If it works and we know conclusively how it works with extensive documentation of how it does the thing we want it to, awesome. That's great, but what's the most valuable part of that? The actual thing that works, this is what should be prioritised. We should constantly be asking ourselves, does it work?
 
Customer collaboration over contract negotiation
Contracts are incredibly important and help define terms, but when you strip the contract down what is actually required? As an individual/team/company, you have been asked by somebody else to create something. Collaborating and building to a fluid specification is important as it keeps everyone in the loop and allows all parties to be open and honest with each other. The client is happy because you build what they want, and you're happy as your customer isn't going to completely flip out at the end of the project because you haven't delivered what they (didn't) ask for.

Responding to change over following a plan


Sometimes teams continue down the road outlined down at the start of a project even if they're no longer aware if it's possible or not. Can we just take a second to put this into context in the real world. You're driving down the motorway, the sat-nav says to go left over the bridge, you see a new sign stating the bridge is being repaired and to cross it would be certain death. Do you listen to the sat-nav you decided to listen to at the start of your journey or the new sign directly infront of you? It's surprising how often a company will drive off a cliff...

That is, while there is value in the items on the right, we value the items on the left more.
So, we can see value in plans, contracts, processes and documentation, but when we start a project, we need to drill down and look at the core of what is being said. So how can we repurpose our own personal development agile manifesto?




Wellbeing and conversations over goals and tasks
Results over comprehensive planning
Teamwork and maintaining the essence of the vision over initial epics

Responding to surroundings and embracing opportunities over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

I'm happy with the above changes and find them relevant whilst keeping in the spirit of the original manifesto.

Thanks for reading!
AT