After observing millions of dollars wasted and made, companies close, and lives disrupted I have adopted these lessons. Your business is not immune from the problems of modern knowledge work. It does not matter if you are a division of a public company or a startup. These lessons are my remedy to the current development catchphrases (agile, scrum, sprints, kanban, waterfall, burndown) when they fail to meet the expectations of business.

1) Write down what you are doing – create a ticket!

Create an issue for all work to be done. Make it public for your team every day. Everybody writes tickets, and everybody follows the same format. Use a tool everyone on your team likes. Use a task manager, like Jira or Pivotal Tracker or Excel or Trello. Make sure the team knows your plan for the week. Stick to your plan.

A proper format for ticket writing is:
As a “stakeholder,”
I should be able to “do something,”
So that “a result occurs.”

2) Story points are worthless managers.

Story points are an excellent way to evaluate complexity, yet a story point is a terrible tool to manage how much work will get done. Use story points to breakdown hard tickets into manageable chunks of work.

Five story points are probably too much for any one ticket; eight certainly is – break it down. If you can’t break stories down to 3, then remove it from the week and have a meeting for clarity. If you must use story points, try to keep all stories at 3 points or less. This guideline is critically true for teams that have been together for less than a year.

If you are using story points as a management technique, you will need at least a year with your current team before you can manage with them. The average job an engineer keeps is less than three years – this is hardly worth the effort considering the cost.

Contrary to most beliefs, story points do equal time, so don’t get comfortable dodging that fact you are spending money when you rack up the points.

3) Personal commitments will guide your team.

Use a personal commitment, not story points, to evaluate how a person is doing every week. Make it binary. Person X said they would get these features built this week and they succeeded, now give them a green check. Person Y has not finished a task they have set to complete, they have failed six weeks in a row, and it’s time to coach and correct.

A personal commitment is a hard way of thinking for new team members and junior employees, but it is the most important characteristic of a great team. Each person knows what they should be doing and publicly discloses this to the team. It removes ego, places accountability on the individual, and provides a clear coaching mechanism.

3) It’s not ready (done, finished, beer thirty) until it’s testable.

Can I test it on production? Yes, then it’s done. There might be a bug. That is Ok. We will create a ticket for the bug. The basic idea is, if a user can use it, it is done. Everything else is just work in progress.

For sales and investment: it’s not done until the money is in the bank.
For hiring: it’s not done until the person starts.

4) Use branches, pull requests, and code review.

When you start work on a new story, create a branch. When you have finished, push the branch to the repository, and then create a pull request. Ask a person to review the pull request.

Deploy it to your staging server after evaluation. Then test the code on the staging server. If tests pass, push the code to production; test it again. When everything looks great, rebase on top of master and redeploy. Test one more time.

This is how it works:
https://guides.github.com/introduction/flow/

Code reviews should not start religious arguments dragging on. Look for two things:

1) Learning Opportunities – What can you learn from this code?
2) Red flags – code that won’t work, spelling mistakes, a missing test.


5) All stories, bugs, and tasks should be attached to an epic.

Look at your quarterly goals and decide what your epics are. Bundle all work into those epics. If there isn’t an epic for the work, create a new one. Be flexible and habitual about this.

At the end of the year, quarter if you are an early stage startup, look at how much work went into each epic.

6) High output teams use weeks, quarters, and years.

The two-week sprint is a terrible estimation technique. Engineers who are excited about their work will underestimate everything and miss their goal. Engineers who are disenchanted with their work will over estimate and luff off the second week. Keep your planning meeting weekly and concise.

Give your team two weeks buffer every quarter for vacations, company holidays, learning opportunities, new hires, and burnout. You should plan 11 weeks of work each quarter.

Plan for engineers to do 2.5 days of coding work, 1/2 day of meetings, one day of QA and deployment, and one day of learning each week.

7) Book retrospectives when products launch.

Skip the retrospective until your product launches and then evaluate how the process moved along. Don’t have retrospectives before your product or version has shipped.

There are two reasons for this:

1) Changing process too much without a launched product or feature will add process complexity to your workflow. A consequence of the retrospective should be change. Aforementioned slows the team down. It is incredibly distracting to have a hackathon or start the switch from Jira to Pivotal mid-product-development cycle.

NOTE: you can always change process mid-development without a retrospective.

2) This meeting should be long and well considered. Having the retrospective every two weeks, or one week (OMG!) sets the stage for a meeting that is not planned or well considered. The meeting should last at least half a day, and everyone should get food. It should be a time for celebration and reflection.

Create a workplace of openness with one-on-ones where employees can voice feedback frequently without fear. This environment will alleviate the need for bi-weekly retrospectives pinned to sprints.

8) Ad Hoc meetings.

New teams suffer from culture conflict in code and process. This dynamic can easily slip away into hours of conversation. I have seen engineers talk for 4 or 5 hours about the same topic distracted from product development.

The solution here is to cap all process, code style, and religious arguments to 5 minutes. Failure to achieve resolution in 5 minutes means it’s time to set a 30 minute Ad Hoc meeting.

Ad Hoc meeting guidelines:

– Focus on one topic
– Timebox the meeting
– Include relevant parties only (designers don’t need to be involved in unit testing conversations)
– Reach a consensus

9) Give your makers time to make.

This one comes from Paul Graham. Makers in your company need time to make stuff. They need time free of meetings, meals, and noise.

My iteration on this is to schedule standup early in the day (10 am) and demos late in the day (5:30 pm). We have planning meetings Monday morning and code releases late in the week (EOD Thursday or Friday morning).

http://paulgraham.com/makersschedule.html

10) Empathy required.

You would never try to interrupt your designer’s creativity with endless changes and meetings, so why do this to your engineers – if you are an engineer, don’t do this to yourself. Set out clear goals and milestones and let people figure out problems for themselves.

Consider what it takes to get a piece of software working. Consider what it takes to please a user when they have 500 other things on their mind today. Consider catchphrases, artificial deadlines, and labels that won’t save your company or create a place where people want to work. Consider authenticity and value with every decision.

Solving real problems as a team will result in great fun and a healthy company. My hope is you are moving that direction.

Leave a Reply

Your email address will not be published. Required fields are marked *