There comes a time in the life of every project where the right thing to do is shoot the engineers and ship the fucker.

This note is about managing a software development projects and teams. Related to management in general.

Strategy Focus

Seeing the iceberg before it hits the ship.

Employees focus on what you measure. Telling developers to write code quickly reduces code readability and makes the development slower in the long run. Programmers will normally work on attributes prioritized but prioritizing everything is not possible.

Default setting. Management tends to hurry up development team, mainly because detecting commitment of an individual programmer in a project is hard. Telling developers "work hard" is only thing managers knows how to do. Stakeholders prioritize lower costs so they get most return for their investment. This cause the product to lose quality all the time.

Focusing on quality improves motivation. Developers usually want to produce high quality software but the processes do not allow it. Focusing on quality will motivate developers more because they do stuff because of itself.

Do not be feature blackmailed. Keeping a customer by implementing a small extra feature is never worth it. Real cost of implementing the feature is rarely what you first see. No, you should not make it optional either. Oh, you have developer who has nothing assigned? Still strong no, have him improve existing code base and features. When a large majority of your customers has stated that they want it, you might consider adding it. Instead, benchmark what your users are using and make it better.

Show the numbers. Consider having big dedicated computer in office that shows an analytics dashboard. Measuring poorly is better than not measuring at all. Main point is to communicate what you are focusing on.

If you want to focus on financial cost:

• Measure new customers this day / week / month.
• Measure paying customer count.
• Measure current revenue per month.
• Measure dollars spent on a project.
• Measure dollars spent per line of code.

If you want to focus on speed:

• Measure time till next iteration.
• Measure will current tasks get completed as estimated a.k.a. velocity.
• Use external libraries and frameworks that are widely used.
• Establish testing culture focusing on unit tests.

If you want to focus on quality:

• Measure number of bugs per project or per module.
• Measure number of public routines in contrast to private ones.
• Measure average number of required parameters in functions.
• Measure average control flow complexity of routines or classes.
• Measure average number of lines per file.
• Code reviews, time of an individual developer is less important than quality and sharing knowledge inside the team. Should focuses on finding bugs and complex code, not correcting them. Majority of reviews should not end in "looks good".
• Pair programming, one writes and other follows. One should be more experienced than the other.
• Establish testing culture focusing on usability and quality assurance.
• Allow people to refactor early, often and in small chunks.

Keeping Track

You must keep track of your project somehow. Here is a suggestion that can be used with most project management software or with just post-its. I use Trello and GitHub Projects but this can be applied to other project management tools too.

Have two boards for each product.
Product board and development board.

Product board is for product owner, product manager and project manager. Where user-stories are gathered and requirements are written down e.g. user shouldn't be able to try logging in without restriction. There are 5 states where stories can be.

• Ideas: inbox for ideas, requests and feedback.
• Useful: story has some value but no concrete requirements yet.
• Approved: will be done but needs to be designed and estimated.
• Finished: user-stories that have been designed and estimated.
• Next: user-stories for the next iteration or sprint.

Development board is for developers and quality assurance team. There are 6 states where a story can be.

• To Do: tasks for current sprint, ordered by priority.
• In Progress: developer moves here when starts working on.
• Ready for Testing: task has been implemented on test environment.
• Now Testing: a task is now currently being tested.
• Tested: task has been tested on the test environment.
• Live v[x]: task is on live, archive any older than 3 versions.

Everybody should have access to all boards. Then developers can throw stories back to product board if they lack details.

One card per story. Split stories smaller if get big.

Each story should have a checklist:

• List items can be grouped e.g. front-end/back-end
• If requires multiple roles (designer, developer), show roles in the list item.
• When all are checked, the task is done.