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.
No comments:
Post a Comment
Comments on this blog are moderated and we do not accept comments that have links to other websites.