The Courtesy Protocol: Making

[Explained fully elsewhere, The Courtesy Protocol governs all things. When someone speaks of finding the right way to do something or seeks a path to success, they are seeking the wisdom and rules of The Courtesy Protocol.]

When making, everyone has a plan. From the moment of conception, a plan for what something does, how it works, where it comes from and why it exists takes up folder space in our minds.?From that moment on, what happens next is governed by that plan - and how well it syncs with The Courtesy Protocol.

The protocol of Making applies to software development or baking a cake;?refinishing a piece of furniture or constructing an office building. The nature of each physical element interacting with the whole has rules. Pounding a nail into a board, the shocks to the nail, the suppleness of the wood interact for specific and predetermined outcomes. The whole includes time, temperature, mass, quantity, attitude and more: all interact in every Making.

Software development.

The Agile Manifesto applied to software aims at building from simple without first developing a detailed specification, abjuring the waterfall method of traditional development.?Agile addresses a basic human failing: we are excellent at correlation and terrible at retrieval. We remember bits and pieces - we can setup relationships between them with ease - but we leave out important parts of the whole.

To prove this to yourself: get out a clean sheet of paper and without references, list all 50 of the United States.?

Most people can imagine a map that contains all of the states - and usually remember to include Alaska and Hawaii.?Most people recall a lot of states - usually 34 or 35 - before they start checking “did I say Rhode Island?”

Trying to write an accurate and whole specification of something that doesn’t yet exist isn’t possible for humans. Along comes Agile and iterative development done in short sprints with the idea that a whole plan can’t exist but must evolve through change.

What gets missed is acknowledging and including the plan that sprung to life when the first person to conceive of the project first thought about it; and how that plan grew and developed a it spread mind to mind.

The Protocol of Making will rule what happens and must be included in the very first steps of a project. Capturing the plan that already exists and putting it up for display and examination might look to some to be a return to waterfall, but?instead it should be the very first sprint. It shouldn’t take days, but a day or a few hours at most. It’s the most important time in a project’s entire existence.

The elements of the Making sprint:

1. Write down every feature and function you imagine
2. Write down how long you think it will take to create each feature
3. Go back and write down what has to be true to complete each feature
4. Give that document to someone that will need to use what you make. Ask them to imagine using the product and what functionality you might have missed
5. Add up the times and list all of what needs to happen first for each feature
6. Go back and find the easiest thing you can get done first and do it as the second sprint of many

Examining each step by yourself or with a team:

1. Write down every feature you imagine having

Don’t evaluate or critique. Include big concepts and little details. If you have an existing system you’re trying to improve, include the features that work you want to retain, and mention those that don’t work, to illustrate what you need in the new system. Your internal plan is necessarily based on what you know and that experience came from your existing system.?Leaving out that history dooms you to repeat mistakes that make your current system require replacing. For a brand new system, the same experience base exists just from a less organized rule set?for how things are getting done already. As fast as you can, write out - or speak to someone writing out - everything you can think of for what it is you want to build. Do that until you start repeating yourself. So to speak: name as many of the 50 states as you can.

2. Write down how long you think it will take to create each feature

Again, don’t agonize or drill down. A quick take based on your internalized plan for how long you think something should take with the only relative measure being everything else you describe. It’s critical that you don’t add up the times you cite. The point is to expose assumptions so they can be validated later. In concert with Agile, you’ll revise that number over and over. Be prepared to be wrong a lot. Remember, when you thought of a feature, say for dynamic pricing updates of hardware components, you were working from your experience. Put a stake in the ground based on that experience and get ready to revise it as the project talks back to you with the impact of what gets done and how long it took.

3. Go back and write down what has to be true to complete each feature

MBA’s call this “environmental scanning”. It’s the beginning of what will eventually make up what project managers call “the critical path” for your project. As above, don’t work too hard to be complete or accurate.?Your goal with this sprint is to expose your internal plan to the outside world. Look at each feature, by itself, and list out what needs to be true to have that feature in your end product. If you need the title of a customer automatically added to a price quote email, then a customer database is required. To have that, you need an interface to add and update customers and some place to store the data. To have that, you need to make a selection of development platforms.?

4. Give that document to someone that will need to use what you make. Ask them to imagine using the product and what functionality you might have missed

If you haven’t already included what the book Strategic Selling refers to as the User Buyer in the room with you while you do steps 1-3 above, then give your document as built so far to someone who will be using the end result.?They too have experience from existing systems and ways of doing business that will help you expose more of your internal plan where that plan “missed naming Nebraska”, so to speak.

5. Add up the times and list all of what needs to happen first for each feature

This will be the first time the full scope of your internal plan appears.?Don’t panic. The highest and best use of a project plan is before the project starts. When something is 80% complete, you have a 20% chance to include the outcome.?Seeing all the things that need to be true at the beginning steps of a project and looking at the first summary of how long it will take complete the project is your first chance to challenge your assumptions in the context of their impact on each other. You have 100% chance to influence the outcome.?Now you can start the hard work of correlating and filling in the bits and pieces you couldn’t retrieve to start with, the “states you missed,” Some of those may have a huge impact on your outcome if you don’t find them and adjust from the start. In your mind, as you surveyed your internal pre-existing plan, you had a built in assumption for how long it would all take.?This is your chance to see how flushing out the pieces one at a time and then adding them up gives you a working template to adjust as you learn and the project evolves.

6. Go back and find the easiest thing you can get done first and do it as the second sprint of many

Finally.

The problem with the traditional waterfall method stems from it’s assumption humans can think of everything that needs to be done in detail before a project starts. The problem with traditional Agile is that it ignores the plan that already exists and presumes organic growth will produce a good finished product.?The Protocol of Making provides the benefits of the scope analysis of traditional waterfall prior to a project start AND governs the organic growth promoted by Agile by first and continuing to expose built in assumptions and biases that predestine project outcomes.