A few weeks ago, I suggested three questions that could spark a discussion and debate over your organization’s agile principles. But I didn’t go as far as suggesting example principles or practices in defining them.

I believe every organization applying agile methodologies across multiple teams needs to define their agile ways of working – optimized to their business’ mission, goals, culture, constraints, operating geographies, regulations, and other factors. Creating self-organizing standards and principles is a way to engage team leaders in documenting repeatable and continuously improving guidelines.

Now the agile manifesto has twelve principles of agile software development, including the key one, “The best architectures, requirements, and designs emerge from self-organizing teams.” But it focuses on software development when many organizations use agile in other areas, including agile data science, agile in IT ops,  and agile marketing.

The manifesto also doesn’t provide guidelines or boundaries on self-organization, and leaving it open-ended can lead to conflict between teams and leadership. One of the agile-antipatterns that I share is when a team translates “self-organizing” as “full empowerment” to do “whatever the team wants,” and I believe it’s prudent for teams to establish guidelines and boundaries of self-organization.

Self-organizing standards help agile teams focus on objectives

Coffee with Digital Trailblazers meets most Fridays at 11am ET

I also don’t believe buying and adopting rigid frameworks is the answer for most organizations. For example, should teams plan quarterly (like SAFe PI planning), plan just before the start of a sprint (just-in-time planning), or practice agile continuous planning?

I believe Digital Trailblazers should set flexible principles and guidelines rather than have every agile team decide for themselves. After all, leaders want agile teams focusing on delivering business outcomes, and having every team reinvent the agile wheels to get there isn’t efficient, especially when there’s a mix of agile expertise across teams.

I guide teams in developing self-organizing standards and centers of excellence that drive digital transformations. Self-organizing means they are bottom-up recommended guidelines, not top-down edicts. They should be specific so that product owners, agile team leads, and scrum masters have easy-to-interpret guidelines for their teams but also leave room for exceptions. Teams should debate and update them to an agreed-upon cadence, and I know some organizations that will open them up for discussion and feedback as part of sprint retrospectives.

I also don’t get particular about values versus principles and what are technical details, and I prefer teams to focus on the meaning and guidelines, not the semantics. I urge short one-page guidelines so teams can easily learn them and organizations don’t have too much work maintaining them.

Example agile principles to consider for your team

Below are a set of agile principles that I sampled from three sources: (i) a question I asked on LinkedIn’s Agile and Lean Software Development Group, (ii) sample principles I quote from blogs and books, and (iii) a handful of my recommendations.

Keep in mind – these are samples and starting points. They don’t apply to every organization. Agile teams should self-organize, collaborate, and decide the guidelines that work at their organizations.

Five from LinkedIn:

• “Use a clearly defined adaptive architecture and always ask, do we really need this now?” – Sander Hoogendoorn, CTO of iBOOD.com
• “Understand the nature of your context (recommend solutions and discuss tradeoffs around the nature of your context) – how does your market move, what constraints exist, what are real, imagined, and ready for disruption?” – Tom Hoyland, Principal Agile and DevOps Consultant. I added the (notes in parentheses).
• “Provide a secure and satisfying environment and solutions for employees and customers now as well as in the future.” – Wayne Mack, Retired Agile Transformation Coach, quoting from It’s Not Luck by Eliyahu Goldratt.
• “What does the team think?” – Johnny Hermann, Independent Consultant.
• “Drive a learning and development program where teams can take what they have learned, design experiments, and put it into practice.” Guy Maslen, Scrum Master.

From blogs and books

• Three from Allen Holub’s list,
  • “Outcomes matter more than output. A focus on output yields sub-par outcomes.”
  • “The most effective organizations are learning organizations.”
  • “Autonomy does not mean that the teams do not coordinate with one another and with the larger organization.”
• · In Agile Beyond IT, author Adrian Pyne shares several principles, and here are two examples:
  • “Being agile means being more open to change during a project but remembering the focus on value. Any proposed change must enhance the value being delivered or at least maintain it.”
  • “Satisfying the customer also means that there should be regular open and honest communication, even if progress news is not good, in order to gain and maintain trust.”
• From the improvement manifesto suggested by thought provoker Michael Küsters, “Great minds think alike – or not. Both consensus and dissent are powerful mechanisms for ensuring that you’re making the best possible decisions. Change envisioned by individuals in solitude hardly works as planned.”

From my playbook

• “Make sure the whole team understands the customer, value prop, problem, and constraints before working through solutions and their tradeoffs.”
• “Just because a stakeholder asked, demanded, or declared an edict, doesn’t mean it gets listed on the roadmap or backlog unless the product owner prioritizes the need for markets, customers, business strategy, and safe operations.”
• “We seek agile estimates on features so that product owners and teams can debate a minimally viable scope that delivers customer value and aligns with strategic objectives. We ask agile teams to size agile user stories to articulate implementation complexities, seek simple solutions, plan sprints, and influence roadmaps.”
• “Show me the data before selling your ideas.” – From Digital Trailblazer
• “Share information on how things work, document processes, and educate colleagues on how to fix things.” – From Driving Digital
• “One simple KPI: Features delivered per quarter.” Note, I have a specific definition of “feature” (see post and video) that accounts for release cycles, technical debt, and operational improvements.