Guess what? Great teams break the “rules” all the time.

Sometimes they…

• Do Big Design Up Front (BDUF).
• Work in isolation.
• Mob and pair.
• Stop (and/or start) using sprints.
• Have output oriented goals. Ship X.
• Obsess about aesthetic details.
• Ignore customers.
• They take feature-requests.
• Work more waterfall-like. Lots of handoffs.
• Parallelize (and serialize).
• Shoot for the step-change and stop iterating.
• Do big-bang releases.
• Do continuous delivery.
• Stop working and take a couple weeks to reset.
• Learn by releasing stuff.
• Learn before starting work.
• Slow down. Speed up.

…but they do so as a team. And switch things up depending on the nature of the challenge.

“No they don’t!” Some do. Some don’t. “Not in companies like my company!” Are you sure? Show me. “But only experienced teams!” Have you worked on a team like that? Do you have firsthand experience? “You have to follow the rules to break the rules?” Who makes the rules? Is it sequential? “That will never work here!” I trust you there. “Teams need training wheels!” Is that the best way to learn how to ride a bike?

Where do teams get into trouble?

1. They are not an actual team.
2. The team is not free to experiment.
3. The team is detached from the impact of their choices.
4. The team lacks experience.
5. The person guiding the team lacks experience.
6. They may not realize how counterintuitive this all can be.
7. They lack experience mapping context to technique.

For #6, let me give you some examples. It can be very tempting to:

• Parallelize work and avoid the messy problem of working together. But there are many situations where working together will yield better outcomes.
• Use a mono-process (it is easier to describe and explain and manage). But it may be more effective to let teams adapt their own working agreements.
• Avoid “new ways” of working. But they may work.
• It can be very tempting to cargo-cult “new ways” of working. But they may not work.

You get the idea. This is hard. Things are not immediately intuitive. If you haven’t seen X work, then it is natural to distrust X. If you’ve only seen X work, then it is natural to distrust Y.

The challenge is that many frameworks are unclear about the desired effect — the job — of each component. Why sprint? Why co-design? Why tracks? Why specialize here? Why generalize there?

The discourse is dominated by:

• People touting “the way”. Do this or else. Start here or else.
• People saying “it depends”, which gets theoretical and hard to follow
• People defending the status quo (“we solved this 50 years ago!”).
• People burning down the status quo (“we need to rethink our fundamental assumptions!“)

In some way we need it all! We need to combine paint by numbers, with mapping context, with learning from the past, and challenging our assumptions and the status quo! To do that as a team we need 1) trust, safety, and respect, 2) freedom to experiment, 3) time and space to practice, and 4) exposure to new ideas.

Above all, we need humility. We don’t know it all, and there are always paths to improvement.