Skip to main content

Ten Principles of Software Projects

I've been working for Fitness24Seven for 2,5 years developing custom software solutions. We have been running a lot of projects, both short and long ones and come to value a set of principles that help us create great deliveries.

I was thinking I would share those with you.

1. We work in a continuous stream

When a task is done we release it. And then we bring in a new task. We still have iterations, but only for hosting demo and retrospective with regular intervals.

We do not

  • Work in what Scrum define as time boxed sprints
  • Commit to a backlog that should be done at the end of the sprint
  • Stress about imaginary deadlines at the end of the sprint
  • Cancel work because it wasn't done at the end of the sprint
  • Create a sprint backlog that is closed for modifications during the sprint

2. We optimize for the throughput, not for utilization

We try to have as little parallel work as possible. We carefully manage our work in progress to make sure that all current tasks are actively being worked on.

We do not

  • Bring in more work before we have completed something on the board
  • Cancel a task that is being worked on, instead we finish it
  • Bring in more work when a team member has spare time. We try to find ways for that team member to help out with the work on the board.

3. We do not keep a backlog in the traditional sense

The most important task to work on is constantly changing. When we finish one task, we will pick the next task that is most valued by our stakeholders.

We do not

  • Hoard user stories in a backlog, if they haven't been picked up in 6 months we delete them
  • Fret on old bugs. If nobody has fixed the bug after 6 months of reporting we delete them
  • Spend time grooming our backlog. The Kondo Principle applies - if you do not love it, delete it

4. We work without estimates

Estimates take time from doing the work, it takes time from the project manager to follow up, and it provides very little value. If the product owner needs to know if Task A is more complex than Task B, he can just ask the team.

We do not

  • Spend time in planning meetings
  • Follow up on how much planned work is left on a task
  • Measure or follow up on pace
  • Keep a burn down chart

5. Our Project Manager is a servant of the team

It is the purpose of the project manager to clear a path so the team can work without impediments. Problems should be solved before they affect the work on progress.

We do not

  • Follow up on who works on what, as long as tasks are being completed
  • Follow up on how many hours anyone has worked
  • Measure the team by key performance indicators
  • Keep people responsible for failures

6. We love planning, but do not follow a plan

In planning we do all the research we need to start a project, even estimates to figure out a reasonable budget. When the project starts we throw away that plan because it is already outdated. What we bring with us into the project is the learnings from making the plan.

We do not

  • Follow up a project based on the original scope
  • Bring estimates from budget planning into the project
  • Make promises to the business that we cannot keep
  • Let an outdated plan affect our decisions in the project

7. We build our team on trust, not control

We assume that everyone is here to do their best. That is why we do not ask what you did yesterday, but rather what has happened with this task since yesterday. What the team members did yesterday is irrelevant.

We do not

  • Measure how our team members perform
  • Follow up on how much time has been spent on a task
  • Require team members to be glued to their keyboard
  • Ask anyone to stay late to finish their work
  • Crunch, ever

8. We help each other out, even if it's not our job

Most important is that tasks are progressing, not that a frontend developer only do frontend code or a tester only do testing. A backend developer can create a solution architecture and a frontend developer can review the backend developer's code by just saying "explain it to me".

We do not

  • Claim ownership of our role or our tasks
  • Let tasks sit dormant waiting for an individual to be free
  • Communicate in silos
  • Let prestige stop us from doing what's best for the project

9. We design solutions just in time for implementation

There is a short due date to design. That is why we do our requirements gathering, graphical design, solution architecture first when it's time to start working on the task.

We do not

  • Start designing until we know that the task will be worked on
  • Do technical design or investigations before the work has started
  • Groom the backlog with requirement gathering

10. We always stay excellent towards each other

Personality traits are #1 priority when we bring in new employees or consultants to the team. If we find people that we like, the work will be much more fun and easy going. The technologies are always something you can learn on the job if you have the right attitude.

We do not

  • Require people to be 100% effective on day one
  • Hire people based on their technical prowess
  • Care about titles

The most important traits are care, compassion, humbleness and the ability to be excellent towards your team mates.

comments powered by Disqus