The 12 Agile Principles: What We Hear vs. What They Actually Mean

This is a guest posting by Nishi Grover Garg. The Agile Manifesto gives us 12 principles to abide by in order to implement agility in our processes. These principles are the golden rules to refer to when we’re looking for the right agile mindset. But are we getting the right meaning out of them? Let’s examine what we mistakenly hear when we’re told the 12 principles, what pain points the agile team face due to these misunderstandings, and what each principle truly means.

Principle 1: Our Highest Priority is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software

What we hear: Let’s have frequent releases to show the customer our agility, and if they don’t like the product, we can redo it. The team’s pain points: Planning frequent releases that aren’t thought out well increases repetitive testing, reduces quality and gives more chances for defect leakage. What it really means: Agile requires us to focus on quick and continuous delivery of useful software to customers in order to accelerate their time to market.

Principle 2: Welcome Changing Requirements, Even Late in Development. Agile Processes Harness Change for the Customer’s Competitive Advantage

What we hear: Agile needs to accommodate change every day, even during the ongoing sprints. The team’s pain points: With no clarity in requirements and the user story details changing every day, even during the sprint, there is no steady way to design or execute tests with surety, leading to confusion at the end of the sprint about what is a feature and what is a bug. What it really means: During the software development lifecycle, agile gives us the flexibility to add or modify features and functionalities, even later in the project timeline, due to working in thin “slices” of work rather than in big chunks of design, code and test phases.

Principle 3: Deliver Working Software Frequently, From a Couple of Weeks to a Couple of Months, With Preference to the Shorter Time Scale

What we hear: Release as soon as possible. The team’s pain points: Having delivery cycles that are too short may not make sense as a valuable outcome, and if the outcome is not usable, adding iterations just acts as an overhead of regression. What it really means: Depending on the context of the software being developed and the type of application, find out and fix a time scale for delivery, preferring the shorter time scales when feasible.

Principle 4: Business People and Developers Must Work Together Daily Throughout the Project

What we hear: We talk once a day during a formal call, depending on need. The team’s pain points: We have questions, some of which need immediate answers. But when we’re used to interacting with the business side in one set meeting a day only, we’ll often wait to ask those questions, which delays those answers and, consequently, the entire sprint. What it means: Team must have open channels of communication between the business and development sides for frequent exchanges of information. Remember the first tenet of the Agile Manifesto: “Individuals and interactions over processes and tools.” Talking when we need to is preferable to having a formal process regarding interactions.

Principle 5: Build Projects Around Motivated Individuals. Give Them the Environment and Support They Need, and Trust Them to get the Job Done

What we hear: Let’s give high-level user stories to the team, and, because they are agile, they will deliver at the end of the sprint. Meanwhile, let’s monitor every hour spent on each story and how many defects each person logged. The team’s pain points: Agile teams are built around a culture, and having a culture of pitting people against each other based on the number of tasks performed or defects logged interferes with the agile focus on continuous quality and one-team spirit. What it really means: Agile teams need to be built around motivated individuals, and once they have the environment and support they require, there is no micromanagement needed.

Principle 6: The Most Efficient and Effective Method of Conveying Information to and Within a Development Team is Face-to-face Conversation

What we hear: Let the people talk and decide what they want to do. We don’t need to keep track of their communications. The team’s pain points: Having face-to-face conversations is great to communicate information, but we still need some track of the decisions or changes being made. Not giving the updated design changes to testers, involving everyone in discussions or having a lean document created for these purposes just creates confusion in the future, especially during sprint testing. What it really means: In any kind of communication, the best way to get our point across is to talk face to face. Make use of such interactions to stay on the same page within the team.

Principle 7: Working Software is the Primary Measure of Progress

What we hear: We depict the increasing functionality of the software every sprint, so there’s no need to set up or use any other metrics. The team’s pain points: Increasing software functionality is a measure of progress for the project, but not having any measures of how the needed progress is happening keeps us all in the dark. The day we do not see the desired progress, we won’t know when or where we lacked as a team. The same also goes for defect counts, tasks spilling over to following sprints and the overall quality of the project. What it really means: The progress of the agile sprint, release, project and team can be seen in terms of the working software delivered. Other metrics, such as a burndown chart, release burnup, defect metrics, and coverage percentages, can help us track the project health over time.

Principle 8: Agile Processes Promote Sustainable Development. The Sponsors, Developers and Users Should be Able to Maintain a Constant Pace Indefinitely

What we hear: Agile means pace, so let’s go, go, go! The team’s pain points: Having to work constantly at a super fast pace drains the team’s energy and reduces the overall productivity and motivation. What it really means: The pace of the agile team must be sustainable — neither too fast nor too slow. The team must be able to constantly work for months on end at the same pace, while still ensuring the best quality outcomes, achieving personal growth, and remaining motivated and engaged.

Principle 9: Continuous Attention to Technical Excellence and Good Design Enhances Agility

What we hear: Let the expert architects make the best designs, and have the team follow them. The team’s pain points: Agile may need lots of planning, re-planning and changes when new features are added, edited or redesigned. Teams need control over implementing the best designs. What it really means: In order to produce the best quality products continuously, agile requires our continuous attention. We need to consider ideas, tools and techniques at all levels of software creation.

Principle 10: Simplicity – the Art of Maximizing the Amount of Work not Done – is Essential

What we hear: Let’s do the bare minimum and ignore tasks like reviews, documentation and recording. The team’s pain points: Ignoring documentation under the guise of agile leads to zero details within user stories, forcing the team to deliver software within the sprints with only a one-liner description to go from. Testers also face the trade-off between having documentation of their tests vs. executing the maximum exploratory tests. What it really means: Simplify the team’s tasks so that the main focus is on software quality. Anything that impedes the team’s pace should be reduced, including over-complicated tools, too many levels of approvals, and exhaustive documentation. Do the minimum, but do not cut away what is really needed.

Principle 11: The Best Architectures, Requirements and Designs Emerge From Self-Organizing Teams

What we hear: The agile team should work on requirements, designs and development all alone. The team’s pain points: Though the agile team may be a self-organizing entity, they do need support from and interactions with the outside. Not having enough clarification on requirements, or reviews from the technical experts or architects outside the team, can be challenging and lead to rework. What it really means: Build a motivated team, let them come up with ideas and questions, support them from the outside, and then trust them to get the job done.

Principle 12: At Regular Intervals, the Team Reflects on How to Become More Effective, Then Tunes and Adjusts its Behavior Accordingly

What we hear: The team discusses their process and problems after each sprint and offers any suggestions or improvements. The team’s pain points: Having a retrospective meeting at the end of each sprint is good, but there may be some issues there. Many team members may not be asked their opinion, or even if they are, they may be too shy or hesitant to share their issues. The value of this exercise may not be evident until the team sees some corrective actions being taken to resolve the mentioned issues. Teams also may wish to discuss their problems internally, so having high-level managers in the meeting may pose a threat. What it really means: The team must discuss their process-related issues and suggestions for improvement at the end of each sprint, and the points gathered must be tracked so that they can be resolved in the upcoming sprints. That way the team can learn from their past mistakes and continuously improve. The end-of-sprint retrospectives must be conducted in a safe, inclusive and encouraging environment. This is a guest posting by Nishi Grover Garg. Nishi is a consulting Testing and Agile trainer with hands-on experience in all stages of software testing life cycle since 2008. She works with Agile Testing Alliance(ATA) to conduct various courses, trainings and organising testing community events and meetups, and also has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.