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
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 -
“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.
Books in this post
