skip to Main Content

The Culture Foundry Development Process

  • By , Director of Engineering, Culture Foundry

This is an overview of the Culture Foundry development process. This process is continuously evolving (so this is a snapshot), but is aimed at creating quality websites and web applications while balancing the needs of our clients for speed. It’s a condensed version of how we think about change in a systematic fashion. We use Trello and custom scripts for automation.

Suppose a client needs to add membership functionality to their website. Here are the internal steps that will occur. (All names are fictitous.)

  1. Suzy the Engagement Manager (our name for someone who wears many hats: a project manager/client advocate/product manager) will work with the client to define exactly what membership looks like. What kind of functionality is needed? What pages are protected? Who can sign up? How will they be approved?
  2. Suzy breaks this up into chunks of work that are roughly a day or less in size. She may pull in Joanna the developer who has worked on this site before to ask questions. Suzy may be working off of a larger scope of work that has previously been defined.
  3. These chunks of work are put into cards on a client Trello board.
  4. Periodically, Suzy moves one or more chunks of work up to the Work In Progress board (a global board that everyone has access to which gives an overview of what is actually being worked on). There they go to the “Problem Definition” Column, where they are further refined if needed. This may include gathering credentials for access or design comps. Key information added at this time is the “Definition of Done” which determines what the task is actually trying to accomplish.
  5. When Suzy feels like the problem is adequately defined, she moves the card to the “Dev Review” column.
  6. Sam the developer reviews the card and fleshes out any non functional requirements. She also sees if there is any other information that is needed for a developer to complete this task. The “Definition of Done” may be revised. The card may be broken into two or more cards. Some back and forth is expected between Suzy and Sam. This may be asynchronous (Trello card assignments, slack discussions) or synchronous (video chat), as the parties decide. But all decisions are captured on the Trello card. Sam may add some notes based on her research that will help whoever gets the card. Finally, Sam determines that this card is defined enough to be developed against. With Sam’s stamp of approval, the card is moved to the “Ready for Work” column.
  7. Joe the developer picks up the card from the “Ready for Work” column and moves it to the “Doing” column. He assigns it to himself. Joe does the work. He can pull in Joanna or Sam or Suzy if he has questions, but the goal is for the card to be well enough defined that he doesn’t have to. He does work on a branch in git, typically a feature branch off of master.
  8. Joe finishes the work. He pushes the work up to Github.
  9. Joe creates a PR linking back to the Trello card, describing how to test and deploy the work. He assigns Jane the developer to review the code. Joe also moves the Trello card to the “Code Review” column, and assigns Jane there. For some projects, a continuous integration pipeline is kicked off and automated tests are run.
  10. Jane reviews the code, pulling it down to see if it “does what it says on the tin”. She also looks for code and application issues. Jane and Joe may have a bit of back and forth, typically on the PR.
  11. When Jane approves the PR, she updates the Trello card back to Joe.
  12. Joe then deploys the changes to the staging server, using his instructions that he wrote previously. He then notifies Suzy the EM that this feature is ready for testing by adding her to the Trello card and moving it to the “QA” column.
  13. Suzy QAs the changes and makes sure that the origina requirements weren’t misunderstood. She may create additional cards based on this. She may bounce it back to Joeif something is awry. Joe would fix it and assign the card back to Suzy. Eventually, Suzy approves and moves the card to “Ready to Deploy” and reassigns it to Joe.
  14. Joe merges the PR to master.
  15. Joe deploys the feature using a capistrano script (or other project specific deployment tool) and runs through the other steps of the deployment process, if any. He then notifies Suzy that the work is done.
  16. Suzy verifies that it is done on production, lets the client know, and moves the card to the “Done” column.
  17. The card is automatically archived after a week.

There are other nuances to the development process, but this is the “golden path” of work in Culture Foundry.

Back To Top