I used to work for a company that used a process mostly like the following:
1. Hit 'copy' on a Dropbox Paper template of usually-important questions.
2 Write the name of the project at the top.
3. Collaboratively write whom (we think) it matters to, what systems (we think) it touches, and why (we think) it matters.
4. Go talk to the people in ops/support/api support/sales/legal/etc, whom it mattered to and ask them. Collaboratively edit the Dropbox Paper document with the updated understanding.
5. Think some more about the systems it touched. Read code. Maybe write a 1-day spike. Maybe write psuedocode. Maybe draw diagrams. Ask questions. Update the Dropbox Paper document. Delete irrelevant questions or sections.
6. Come up with a few design options, starting with some crappy ideas. Maybe talk with other teams. Maybe go back and talk with stakeholders. Eavaluate trade-offs. Pick the option[s] that made the most sense. Put the others at the end underneath an <hr>.
7. Meet with the stakeholders again to double-check that everyone's on the same page and they'll have capacity for us to ask Qs when we run into the unexpected. Send out a concise project-kickoff email so people know what we're doing.
8. Break work into trello cards. Sequence them to try to deliver incremental wins along the way.
9. Write tests. Write code. Ask Questions. Write queries. Get stuck. Get clarity. Make changes easy, then make the easy change. Do hallway usability tests. Update the Dropbox Paper document as you learn important things, so it stays an organized source of project truth.
10. Succeed.
11. Have a project retro among engineers and stakeholders to collect learnings, usually scheduled by the PM.
12. Send around project complete email with a link to the Dropbox Paper document, which now becomes a historical reference.
Projects were generally 2-4ish weeks. Longer effort would be broken up into conceptually-coherent phases of that size.
--------
Causes of success:
1. Insist on written clarity -- We put a lot of thought into the Dropbox Paper document because it was actually our means of communicating with each other (and our post-vacation selves) about the results of our a conversations. It is astounding how much faster you can work when you're on the same page and know what you're doing.
2. Start With Why -- We strove to always keep in mind the actual impact we were trying to have
Sometimes we would get to step 4.5ish and realize that the project had insufficient "why". This observation enabled us to deliver (earlier than expected!) the most high-performance snippet of code that any company can deploy:
```
```
3. "Take what is useful, discard what is useless, add what is specifically your own." -- either Bruce Lee or a weird guy from Mostar
The template was a useful reminder, but we cut any section that didn't serve to create clarity.
4. Being able to talk to stakeholders, to know what their goals are, and talk through what UX matters to them....sure that probably helps the business... but the real reason it is great is that it is just so damn personally rewarding.
5. Technical Investment -- Our PM wanted us to keep the codebase clean and well-tested so that we'd be able to deliver with more speed and sureness.
1. Hit 'copy' on a Dropbox Paper template of usually-important questions.
2 Write the name of the project at the top.
3. Collaboratively write whom (we think) it matters to, what systems (we think) it touches, and why (we think) it matters.
4. Go talk to the people in ops/support/api support/sales/legal/etc, whom it mattered to and ask them. Collaboratively edit the Dropbox Paper document with the updated understanding.
5. Think some more about the systems it touched. Read code. Maybe write a 1-day spike. Maybe write psuedocode. Maybe draw diagrams. Ask questions. Update the Dropbox Paper document. Delete irrelevant questions or sections.
6. Come up with a few design options, starting with some crappy ideas. Maybe talk with other teams. Maybe go back and talk with stakeholders. Eavaluate trade-offs. Pick the option[s] that made the most sense. Put the others at the end underneath an <hr>.
7. Meet with the stakeholders again to double-check that everyone's on the same page and they'll have capacity for us to ask Qs when we run into the unexpected. Send out a concise project-kickoff email so people know what we're doing.
8. Break work into trello cards. Sequence them to try to deliver incremental wins along the way.
9. Write tests. Write code. Ask Questions. Write queries. Get stuck. Get clarity. Make changes easy, then make the easy change. Do hallway usability tests. Update the Dropbox Paper document as you learn important things, so it stays an organized source of project truth.
10. Succeed.
11. Have a project retro among engineers and stakeholders to collect learnings, usually scheduled by the PM.
12. Send around project complete email with a link to the Dropbox Paper document, which now becomes a historical reference.
Projects were generally 2-4ish weeks. Longer effort would be broken up into conceptually-coherent phases of that size.
--------
Causes of success:
1. Insist on written clarity -- We put a lot of thought into the Dropbox Paper document because it was actually our means of communicating with each other (and our post-vacation selves) about the results of our a conversations. It is astounding how much faster you can work when you're on the same page and know what you're doing.
2. Start With Why -- We strove to always keep in mind the actual impact we were trying to have
Sometimes we would get to step 4.5ish and realize that the project had insufficient "why". This observation enabled us to deliver (earlier than expected!) the most high-performance snippet of code that any company can deploy:
3. "Take what is useful, discard what is useless, add what is specifically your own." -- either Bruce Lee or a weird guy from MostarThe template was a useful reminder, but we cut any section that didn't serve to create clarity.
4. Being able to talk to stakeholders, to know what their goals are, and talk through what UX matters to them....sure that probably helps the business... but the real reason it is great is that it is just so damn personally rewarding.
5. Technical Investment -- Our PM wanted us to keep the codebase clean and well-tested so that we'd be able to deliver with more speed and sureness.
6. Do not 'be Agile'. Move _with agility_ -- https://www.youtube.com/watch?v=a-BOSpxYJ9M
(Looking back on that company, their normal development process was full of accidental Reasonable Accommodations for my ADHD)