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.