I’ve recently come to the conclusion that the answer is simple and universal: “Agile Best Practices? Those which work now, or might work soon if you gave ’em a shot.”
Yes, methodologies such as Scrum, Kanban, XP, come with explicit practices a team must be using to apply the respective frameworks “label.” Some refer to these as the “Best Practices.” And there are also emergent “Generally Accepted Practices” that are optional. All are readily available from any methodology’s “Field Guide.”
But are these really the “Agile Best Practices” for your team? Should you blindly follow them to the letter? Should “Leadership” mandate you implement them?
NO. NO. NO. All of these practices are good only as training wheels and should be taken off as soon as possible. Drop the framework labeling [Scrum, Kanban, XP] if you feel a little dirty when you veer from the dogma.
Values and Principles – The North Star for Teams
Behind all of these practices (best, GASP, etc) are important values and principles. And I propose that teams use values and principles as their north star as they develop and refine their own best practices. (And maybe we drop “best” from our usage. It is simply too damn situational.)
© 2014 Jurgen Appelo
But wait, there’s more. Below is a summary of what various communities of practice have defined as their core values and principles:
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.
© 2001, the authors this declaration may be freely copied in any form, but only in its entirety through this notice.
- 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.
Interesting quora discussion from former Google engineering director on “do all of these agile principles apply to us?”
Agile beyond software / IT, what an expansive concept, has four guiding principles:
- Make people awesome
- Make safety a prerequisite
- Experiment and learn rapidly
- Deliver value continuously
Read more about each at modernagile.org
- Eliminate waste
- Empower the team
- Build integrity in
- Amplify learning
- Decide late
- Deliver fast
- See the whole
Lean Change Values
- Simplicity of interactions over complex process
- Cause and purpose over urgency.. the why
- Diversity and inclusion over closed-door planning
- Pull over push
- Touch over technology
- Organic over scripted
- Growth over perfection
- Quality over quantity
Scrum Master Values
- Team communication and collaboration over process compliance
- Shared understanding of what is to be done over-fixation on how decisions are reached
- Open dialogue with users and stakeholders over “walled gardens” separating teams from their customers
- Acknowledging that not everything can be known and working incrementally from that starting point over immutable timelines and feature sets
Raising the bar. As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships
That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
© 2009, the original authors. this statement may be freely copied in any form, but only in its entirety through this notice.
Agile and adaptive approaches for linking people, projects, and value
We are a community of project leaders that are highly successful at delivering results. To achieve these results:
- We increase return on investment by making continuous flow of value our focus.
- We deliver reliable results by engaging customers in frequent interactions and shared ownership.
- We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
- We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
- We boost performance through group accountability for results and shared responsibility for team effectiveness.
- We improve effectiveness and reliability through situationally specific strategies, processes and practices.
©2005 David Anderson, Sanjiv Augustine, Christopher Avery, Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, Pollyanna Pixton, Preston Smith and Robert Wysocki.
- Testing throughout over testing at the end
- Preventing bugs over finding bugs
- Testing understanding over testing functionality
- Building the best system over breaking the system
- Team responsibility over tester responsibility
- Each problem has multiple Solutions. There is not one best way to run a software project.
- Solutions depend on the problem’s context. The best practices depend on the project environment.
- Changing context requires changing solutions. When project environments change, projects change accordingly.
- Each strange solution is the best one somewhere. There is always a place and time for less popular practices.
- Solutions change the context and themselves. Practices change environments and how we use practices.
- Simplicity necessitates understanding complexity. One must understand complexity before applying simple solutions.
- We cannot predict the best solution. We have to try practice to know if they work in our context.
© Jurgen Appelo
- Networked Structure over vertical hierarchy. We seek participation, innovation
- Transparency over secrecy. We seek collective intelligence, meritocracy
- Projects and Souls over jobs and roles. We seek flexibility, capability to face continual disruption
- Adaptability over predictability. We seek continuous learning, culture, deal with complexity of reality.
- Intrinsic and Transcendent Motivation over extrinsic rewards. We seek autonomy, challenge.
- Ambition over obligation. We seek self- mastery, happiness.
- Fairness over criticism.
- Actionable feedback over numbers.
- Frequent reality checks over abstract evaluation criteria.
- Rewards reflective of business value added over rewarding the status quo.
- We respect individuals regardless of the power dynamic in the process.
- Criteria should be visible and the process transparent.
- The process is fluid and can change as long as the manifesto is applied.
- Appraisals should be regular enough to ensure no surprises.
- We embrace and support and reward changing actions where business reality demands.
- We recognize the value of work done.
- Appraisals should be done by people with context.
- We assess as frequently as possible, but no more frequent than would be disruptive.
- Metrics should be easy tounderstand,, assessable and achievable, and have a shelf life.
- We provide frequent actionable feedback to help teams and people improve.
We believe in the creativity and motivation of human beings. We consider human leadership as pivotal in a highly networked and highly complex world. We understand the task of leadership as serving life and striving for conditions in which people, in their diversity, can contribute in the best possible way and in which they can develop themselves and work effectively together:
- Unleashing human potential over employing human resources.
- Diversity and dissent over conformity and consensus.
- Purpose and trust over command and control.
- Contributions to networks over position in hierarchies.
- Growing leaders over leading followers.
- Courageously exploring the new over efficiently exploiting the old.
10) Always get the full story before making a decision.
9) It’s incredibly easy to ‘flip the switch’ and start writing people off after a few bad experiences. Resist at all costs. You were bumbling once too. You made poor decisions. You learn and grow, and so does everybody else.
8) Sweep up the crumbs. Wipe the tables. Turn off the lights. Plug the holes that need plugging—even if it’s menial, even if nobody will know you did it. Do it in service of the product, the company, and this wondrous, magical thing you are all building together.
7) Recognize you can’t do everything. Close your eyes, fall backwards, and learn to trust.
6) Clearly, there is a more efficient way to do the things you do. How? Ponder that on your daily drive home.
5) Figure out which people rely on you and how you can help them be self-sufficient. You may feel important having a monopoly on salmon provisions, but if the whole village learns how to fish, it’ll free you up to do something else. Like figuring out how to grow wheat. Or how to domesticate those cute wolf-pups.
4) Don’t say anything if it’s not actually contributing to the discussion. Your voice is not so melodious that it absolutely must be heard.
3) Making the best decision is not as important as putting in the right processes to ensure that the best decisions get made.
2) Dole out thanks and encouragement like you dole out opinions.
1) Above all, this: never, ever get in the way. It’s better to twiddle your thumbs and squint up at the clouds than to obstruct progress for the sake of that stupid, childish thing called ego.
Roll Your Own Team Values
Whew, that’s a lot of ideas. I’m sure you can find plenty of inspiration to make your own list of team values.
How many values should a team have? It depends. Would you settle for: “just enough but not too many.” If you need a number, I suspect: 5±2, or maybe 7±2. The key point is that the team decides which and how many values “fit” given their current situation.
Does “management” need to agree to the team’s list of values? Any team is part of the larger organization. If there’s a huge disconnect between company values and team values, problems will eventually emerge and it’s likely the team will be dissolved. Perhaps it is a “Type 2” decision: Team consults with leadership, in the event of a tie or disagreement, team wins. But they accept full accountability. (A key point I want to make is that a team’s values are theirs to define. Can they simply adopt en masse from one of the lists above? Maybe. If they want. Leadership just can’t inform them “Here are your values.”)
How frequently should the team inspect and adapt their list of values? They’ll know thru retrospectives when it is time. Situations change, team members come and go. Values need to be adjusted accordingly. Drop some, add some. Maybe it’s part of the team expectations exercise.
Ultimately these values serve a “north star” for when a team hits something new, messy, unexpected, or just confusing. By using these values as guidance, the team can develop their own agile best practices. Whoops. Their own GEFN practices 🙂
I’ve facilitated the “Roll Your Own Values” exercise on three teams recently. My take aways are:
- It is relatively easy for the teams to come up with an initial list
- It helps to find a single word that summarizes affinity groups
- Small list (five max) is workable, any more is cumbersome
- To keep things alive, teams need to see these values frequently – added a channel description in slack, put on a wall
- It’s been great to tie the values into kudo/props practices and a tool like Bonus.ly makes doing so easy
Case Study in Make It Your Own
https://twitter.com/johncutlefish has a great example of a team owning their values: