XYZ System: BPRF Brainstorm > Research > Prototype > Final Build

BPRF Brainstorm > Research > Prototype > Final Build I’ve wrote about this before in detail so here’s the practical short version. I use BRPF as a method of building things, within the ever evolving XYZ System. It’s a fundamental part alongside the project management aspect of the XYZ System. The project management part of XYZ is based on the Agile framework, but aims to be a lightweight pared down version. This part BRPF is focused on the engineering or building part. The implementation of this in my company allowed for greater freedom and autonomy for engineers and product owners without chaos. The principial goal is to provide an easy light weight method to get things done fast, or at least as fast as they are needed. This system achieved those goals and I seen not only greater productivity and quality, I see the product owners and the engineers grow and become better.

Roots of BRPF

I originally heard about the BPRF system from Mark Rober. I took one of Mark Robers engineering courses online some years ago. The courses are designed to be simple so that kids and adults alike can follow them. (The course evolved into https://www.crunchlabs.com/ if you are interested in knowing more.)

In the course Mark introduced the process by saying that it was something that they used in NASA JPL While he worked there (JPL – Jet Propulsion Laboratory https://www.jpl.nasa.gov). Surprisingly when I did more research on it I could not find this exact terminology, but I did find JPL engineering whitepapers on the staged iterative approach outlined. So indeed the methods are part of the core principles of building projects at JPL. I could not find any proprietary claims to the process so I believe it to be in the public domain, so I rolled it into my every evolving search for systems that work well.
Mark said that his team used this process while building a Mars Rover, so I decided that if it was good enough to put a robot on the Mars then it’s good enough to build the things I need built. At the same time in my work I was in the midst of evolution of systems used in the company so I decided to try make this fit around our app & website development, platform development, content production (videos, ads etc) and product development themes.

In the process below the terms product owner and developer are used. This process can work with individuals or teams. You may use different terms in your organisation. but the process is the same. The following is the wording of the bullet point list for each step in the process kept as lightweight ans concise as possible. All team members were instructed to learn and follow the process, so when you’re reading the document you may be one or the other of the characters but regardless you’re 100% responsible for the whole project, that’s a core rule – and infact the only rule!

BRPF Stages

BPRF Brainstorm > Research > Prototype > Final Build

Rule #1 > YOU (The person reading this) are 100% responsible for everything you do. < End Rules.

Product Owner and Developer, you must Work Together, COLLABORATE you are both 100% responsible for the story.

Why do you have to use this system?
The 4 stage B-R-P-F system for solving problems and building solutions works well. If we all follow the same system we’ll have a good system. We can evolve a good system into a great system. If you’ve a better idea when we can use that. Otherwise get on board. You’re expected to make this system better as it matures. Always refine, always lean, never cut corners.
BRPF > Brainstorm > Research > Prototype > Final Build. These stages don’t have to be long processes nor do they need endless planning, but they should be followed for EVERY story. We are not looking to create administration this is not about creating useless administration its about minimising it.
You don’t learn by reading, you learn by doing. So begin using the system on your current and next stories. Follow these 4 stages in your work until you get good at it.

(B) Brainstorm:

• Communicate Talk to the product owner. Get clear on the problem being solved.
• Understand what is the problem? there’s no point in solving the wrong problem.
• Investigate what are symptom? possible causes of the problem?
• Speculate Talk about possible solutions, Guesstimate / Speculate, how much work involved in the solution, how much time it will it take. Decide on a solution to research. Resources? Do you need more people / other developers involved from other epics?
• Organise Once you’ve all the brainstorming clear collect all info to a story. Collect all files, designs, whiteboards, postits and any resources that you need and attach to story. Don’t spend time on fancy presentations when a pen and paper will do.

(R) Research

• Understand Research the possible solutions you came up with in Brainstorm the solution, write out your solution in logical parts, use pseudo code to describe
  e.g. 1) Get Order If A=B then download Order 2) Add order to list. 3) Schedule update.
  Sketch diagrams and take a pic if that helps. Keep it simple. Do not accept a product owners solution without investigating and continuing through the whole BRPF system. Your solution may be a good solution and it may not! It’s cheap to find out now.
• Investigate What will be affected? existing system, clouds, classes, objects, schedulers, journeys, apis, processes builders, disruption etc. Your solution should always integrate into the system not be a hack. You can make assumptions on how things work at this stage. Is there already something that fulfills the requirement? Maybe there’s even something in development that will full fill this need. Do not duplicate work. You may be able to integrate this work with something already running and save a lot of time and duplication of effort.
• Communicate talk to the product owner again when you have your best solution, present your research, describe solution, discuss any improvements, give time estimate on how long each part could take and decide priority and pick due date for a prototype.
• Organise Add research learning to the story. The story is the collection point of all information now. all documents and files, that you will need e.g. Design files etc collect them on the story. Set the due date. Keep your story up to date with information and changes.

(P) Prototype

• Understand what to build,a prototype must be based on your research, DON’T BUILD ANYTHING ELSE, else go back to research. We are not looking for a final build on the first go, do not over invest in finishing touches, any part of the project if likely to change still.
• Build A prototype is a proof of concept not a final build, it’s goal is to test that all the parts of your research can work. it may be; code stubs, api calls, classes, photoshop designs, html pages / email, queries, dashboard layouts, an object. You might have prototypes of different parts. Keep evolving your prototypes in incrementally until it’s on course to fulfill your original needs.
• Communicate Demo the parts of the prototype to the product owner and show how it will work, Low effort, minimum-time work so you can check if you have the best solution. Get tweaks / changes and approval to make a final build candidate.
• Organise On your story record any info from demo, Set due date for final build date. When dates need to change communicate and reset expectations.

(F) Final build

• Build Some increment of your Prototype build becomes the basis of the first final build, create your final build as planned in sandbox – never develop on live unless no other option. Quality, class naming, object naming, filed naming, scheduler naming, code comments, code indentation, readme files. These are all expected to be high quality from here on in.
• Test that your build does what it’s supposed to do. Is it exactly like as per design? Record your tests on video screen record and attach to story. Test if your code affects any any other process in the system. Fix bugs, if your code has no bugs you have not tested correctly. All code has bugs. Try harder to break yours.
• Communicate YOU are putting your build forward as your candidate for final build to go into the live system. Don’t make a product owner have to go and manually generate test results to see if it works. Use video / screen shots to show that the solution works, attach to story and talk to the product owner.
• Reject If there are problems with your final build you did not discover in testing or minor changes from the product owner then, agree a due date for your next final build candidate, update due date and comments on story. Restart the final build stages, and create the next final build candidate.
• Accept If you and the product owner are happy you’ve solved the original problem then set the set a date for moving to live environment. Move code live, Apply all the final build stages checklist ^^ to the live build.
• Organise On your story record that its gone live with a comment and change status to ready for review. Finalise the read me and Include a link to the read me in the comment. The story will automatically close in 7 days with a positive, the product owner will be asked to select a negative experience if the BRPF process was not followed.

END of Process
(B) (R) (P) (F) > Brainstorm > Research > Prototype > Final Build