Skip to main content

26 Heuristics For Effective Software Development

  • Three core agile principles: work small + talk to each other + make people’s lives better
    • You only plan enough details to be able to start (not finish)
    • Implement that (work small), get feedback from real users (talk to each other)
    • You work small so you can get feedback sooner
    • Start with the critical parts that add the most value first so you can get to MVP faster
    • Completing tasks doesn’t make people’s lives better; it’s the wrong “goal”
    • The real strategic goal is focused on the user’s experience
    • Improving the user’s lives improves your team’s as well
    • Do that, and work will be fun and make you happy
    • If it doesn’t, something is wrong about how the team is working
  • Psychological safety is a prerequisite
  • It’s about everybody being able to speak without fear
  • Increasing the amount of lively, excited discussion you can have
  • Respect:
    • Give people the benefit of the doubt
    • Management should let the people doing the work make the decisions
    • A team can talk to a customer and make a decision to change something and just change it without having to wait for permission
    • Any lack of respect that involves waiting for permission slows down user feedback cycles, which is the key to everything
  • Trust:
    • Trust the people doing the work to make decent decisions
    • If you have to ask permission to do something necessary, you are not trusted
    • If you need training, just do it
    • Control hierarchies don’t work with agile
  • Agile is faster because you don’t waste time building things nobody wants or needs
    • Building in large chunks without frequent feedback increases the risk that you are doing just that
  • The most valuable thing a 10X programmer can do is teach everyone else to be as good as they are so the whole system improves and they don’t become a bottleneck everyone sends work to
  • There’s no value in the process itself; there’s only value in getting better at delivering value to customers
  • If the focus is on doing scrum (or any process) better instead of on the people doing the work and the people the work is for, the workflow will fail
  • The people doing the work and using the outcome of the work are more important than any process
  • If any part of the process isn’t helping the people, drop it
  • If it would take 5 minutes to fix a problem for a user, just fix it; forget the ticket
  • Collaboration
    • Negotiating is not collaboration
    • Instead of arguing, run an experiment and see how it goes
    • Any focus on individuals is a mistake; the team as a whole is what matters
  • Learning is the work
    • Releasing small and collaborating with users to figure what’s right and wrong is learning
    • The point of releasing a story as an experiment is to learn; you can’t fail if your goal is to learn something
  • Welcoming change is essentials
    • If something needs to change, you just change it
    • Beware of tactical roadmaps like a complete quarterly plan
    • Prefer strategic goals focused on outcomes for the business and users
    • Then, let the team figure out how to move in those directions
    • Changing accomodates learning, so don’t plan too rigidly
  • To be effective, you have to be developing your own ways of working based on a set of core principles

Original video by DevTernity Conference: