Viking laws

After reading this which jokingly tells us that the Viking laws will replace the agile manifesto I started to think about manifestos and "agile". The agile manifesto well describes how you need a change in your mindset to become agile. And some try to refine it even further. But the Viking laws are brilliant. And I find it intriguing how they describe the right mind set for an agile software developer. Reminds me of my own observations on similarities with the military. Let me elaborate a little on the Viking laws and how I interpret them into a software development context.

  • §1 Be brave and aggressive.
    • Be direct.
      Do not protect others from the truth, speak clearly on your thoughts. Same applies to your code; it should be clear and simple.
    • Grab all opportunities.
      Do not be afraid to take on new challenges.
    • Use varying methods of attack.
      Explore different ways to solve a problem. Do not do the same thing all the time.
    • Be versatile and agile.
      Be skilled in many different areas and use what is best for the task at hand
    • Attack one target at a time.
      Focus on one thing and complete it before starting the next, for example only one user story at a time.
    • Don't plan everything in detail.
      Things that are imminent may need more planning than things in the future. Don't plan more than you're prepared to throw away when things change and your plan becomes invalid.
    • Use top quality weapons.
      Use the best tools available.
  • §2 Be prepared.
    • Keep weapons in good condition.
      Your tools should be updated and working properly.
    • Keep in shape.
      Sometimes you need to practice things on your own that are not in your day to day work.
    • Find good battle comrades.
      A good team can perform great even under chaotic circumstances while a bad team will always fail. You want to work with great people that share your values for most of the time at least.
    • Agree on important points.
      Don't spend energy on convincing everybody of something that is not important, but make sure you all agree on the important things.
    • Choose one chief.
      For those hard decisions that the group cannot agree on, rely on a single person (who you all respect) to make an informed decision for the team.
  • §3 Be a good merchant.
    • Find out what the market needs.
      Don't do things the market does not want.
    • Don't promises what you can't keep.
      People like pleasant surprises, not bad news. Only promise what you can do and there is one promise you always can give; "I'll do my best".
    • Don't demand overpayment.
      Just because you're the only person in the world who can do something you should not demand unreasonable compensation for what you do. That is not the way to build long lasting relationships.
    • Arrange things so that you can return.
      Whenever you leave a team or complete a section of code, make sure that you are welcome to return.
  • §4 Keep the camp in order.
    • Keep things tidy and organized.
      Backlogs, code, documentation etc should be tidy and organized.
    • Arrange enjoyable activities which strengthen the group.
      A happy team performs better than an unhappy team. Do fun things together!
    • Make sure everybody does useful work.
      Everybody needs to feel that what they're doing is useful and drives the team forward.
    • Consult all members of the group for advice.
      You should not revert to democracy for all your decisions but you want to make informed decisions so consult all members of the group. Even the less experienced team members may have an important point of view you need to consider.