Our Process for Custom Implementations of SDK
Our favorite thing in the world is to build data science tools for the global health world. We like it so much that we want to do it often and do it together, so we’ve adopted a process that makes working with us just as fun as using the tools we create together. This way of working is often referred to as agile development (or Scrum). We chose to work within the Scrum framework because it’s undeniably beneficial for you and for us. We believe wasting our time and your money is a crime, so it makes us happy to work in the most efficient way possible, leading to quicker delivery and more money in your pocket. Our process looks a little like this:
The beauty of this process is that we’re collaborating and communicating regularly (that’s the do it together part) so that you will receive a new chunk of working software at the end of every sprint (the do it often part).
So that’s the gist, but if you want to learn more specifics, keep reading about the Roles and Meetings involved in our process.
When you partner with Secure Data Kit for a custom implementation, you’ll be working with a small interdisciplinary team comprised of three main roles: Product Owner, Project Manager and Dev Team. Once you’re paired with your team, you’ll know them more affectionately by their first names - so don’t worry too much about remembering the role names.
You’ll start by talking strategy with a Product Owner. This person is the member of our team that will communicate your vision to the team. The Product Owner will work with you to prioritize a list of feature requests based on what will bring you the most value first - we call this list the Backlog. This is one of the most important parts of our process, because it allows us to hit the ground running and deliver you a product that will bring you tangible value right away.
Once you have a Backlog that’s filled and prioritized, your Project Manager will call the team together and facilitate an internal meeting to get the ball rolling. The Project Managers on our teams differ from your typical project manager - they do a lot less task assigning and spend the majority of their time squashing any roadblocks that crop up to leave a clear path for the dev team to do what they do best. It’s also their responsibility to guide you and the team internally through the process and make sure everybody’s working as efficiently as possible.
Last but definitely not least, let’s talk about the people who are going to be doing the work, they’re called the Dev Team. The Dev Team has every type of talent they need to complete your project - UX / UI designers, engineers, quality assurance testers, you name it, it’s on the team. The developers work to build the product, but it doesn’t stop there - other team members will come in to ensure quality assurance, which is a fancy way of saying that they make sure we did what we said we’d do, and we did it well. The Product Owner and Project Manager exist to serve this team. After all, they’re the ones building your product and we want to make sure they have everything they need to do incredible work.
What comes to mind when you hear the word “meeting?” I’ll bet it’s anything but visions of freedom and creativity, but we’re trying to change that. The truth is, we need meetings to operate an efficient business, but we cringe at that thought because companies are historically so horrible at putting these things in place and doing them well. The process we follow is designed to increase communication and collaboration, and we do that through a consistent cycle of mostly internal meetings that we not only survive, but thrive off of.
The Strategy Meeting is a face-to-face sit down meeting between you and your Product Owner. During this time you’ll share your vision, fill a Backlog with feature requests and ideas, and work to prioritize that Backlog based on what will bring you the most value first.
Behind the scenes your Product Owner will be clarifying each work item into digestible chunks so that our Dev Team can tackle them most efficiently. Once the Backlog is ready, your Project Manager will pull the entire team together for a Sprint Planning Meeting. This is an internal meeting where the Dev Team is briefed on the items in the Backlog, and they commit to completing a certain amount within a set period of time (usually two weeks) called a Sprint.
Every day during the Sprint the team answers three questions in a Daily Stand-Up: What did you accomplish yesterday? What will you accomplish today? What obstacles are in your way? The purpose of this meeting is to ensure everyone knows what’s going on, and to bring challenges to the surface so that the Project Manager can work to squash them and foster a more efficient work environment.
Once the Sprint is complete, the Dev Team calls the Product Owner to a Sprint Demo, where they’ll show off all the work that was completed during the Sprint. The Product Owner gives their thumbs up, and then we share all our hard work with you!
After we’ve collected your feedback, we get together for an internal Retrospective where we identify things we can improve upon in the next Sprint. It then becomes the Project Manager’s #1 goal to improve those specific items throughout the next Sprint.
Once we run through the process once, we turn around and do it again. And again, until we have a product that looks beautiful and functions seamlessly. And even then, actually, we don’t ever really stop. We’re continuously improving on what we’ve built through regular iterations.
Well, that’s it! There’s our process. It fits on just 3 pages, leaving a ton of room for our team members to work freely, flexibly and most importantly efficiently.
- Before we begin the work, we’ll have a Strategy Meeting where your Product Owner will meet with you to set priorities to ensure we’re working on the things that will bring you the most value quickest.
- Our team hunkers down for a 2 week sprint, with a goal to deliver the most valuable functionality at the end of that sprint.
- We meet internally every morning to talk about how things are going, and the Project Manager will make it their main goal to squash any impediments that crop up.
- At the end of each sprint, we’ll show you what we accomplished, and then collect any feedback you have based on the work we completed.
- We’ll meet again for another Strategy Meeting, prioritize functionality, and start the cycle over with another sprint.
- We repeat this process until you have a fully functioning product that we’re all proud of!
The beauty of this process is that we’re collaborating and communicating regularly (that’s the do it together part) so that you will receive a new chunk of working software at the end of every sprint (the do it often part).
So that’s the gist, but if you want to learn more specifics, keep reading about the Roles and Meetings involved in our process.
Roles
When you partner with Secure Data Kit for a custom implementation, you’ll be working with a small interdisciplinary team comprised of three main roles: Product Owner, Project Manager and Dev Team. Once you’re paired with your team, you’ll know them more affectionately by their first names - so don’t worry too much about remembering the role names.
You’ll start by talking strategy with a Product Owner. This person is the member of our team that will communicate your vision to the team. The Product Owner will work with you to prioritize a list of feature requests based on what will bring you the most value first - we call this list the Backlog. This is one of the most important parts of our process, because it allows us to hit the ground running and deliver you a product that will bring you tangible value right away.
Once you have a Backlog that’s filled and prioritized, your Project Manager will call the team together and facilitate an internal meeting to get the ball rolling. The Project Managers on our teams differ from your typical project manager - they do a lot less task assigning and spend the majority of their time squashing any roadblocks that crop up to leave a clear path for the dev team to do what they do best. It’s also their responsibility to guide you and the team internally through the process and make sure everybody’s working as efficiently as possible.
Last but definitely not least, let’s talk about the people who are going to be doing the work, they’re called the Dev Team. The Dev Team has every type of talent they need to complete your project - UX / UI designers, engineers, quality assurance testers, you name it, it’s on the team. The developers work to build the product, but it doesn’t stop there - other team members will come in to ensure quality assurance, which is a fancy way of saying that they make sure we did what we said we’d do, and we did it well. The Product Owner and Project Manager exist to serve this team. After all, they’re the ones building your product and we want to make sure they have everything they need to do incredible work.
Meetings
What comes to mind when you hear the word “meeting?” I’ll bet it’s anything but visions of freedom and creativity, but we’re trying to change that. The truth is, we need meetings to operate an efficient business, but we cringe at that thought because companies are historically so horrible at putting these things in place and doing them well. The process we follow is designed to increase communication and collaboration, and we do that through a consistent cycle of mostly internal meetings that we not only survive, but thrive off of.
The Strategy Meeting is a face-to-face sit down meeting between you and your Product Owner. During this time you’ll share your vision, fill a Backlog with feature requests and ideas, and work to prioritize that Backlog based on what will bring you the most value first.
Behind the scenes your Product Owner will be clarifying each work item into digestible chunks so that our Dev Team can tackle them most efficiently. Once the Backlog is ready, your Project Manager will pull the entire team together for a Sprint Planning Meeting. This is an internal meeting where the Dev Team is briefed on the items in the Backlog, and they commit to completing a certain amount within a set period of time (usually two weeks) called a Sprint.
Every day during the Sprint the team answers three questions in a Daily Stand-Up: What did you accomplish yesterday? What will you accomplish today? What obstacles are in your way? The purpose of this meeting is to ensure everyone knows what’s going on, and to bring challenges to the surface so that the Project Manager can work to squash them and foster a more efficient work environment.
Once the Sprint is complete, the Dev Team calls the Product Owner to a Sprint Demo, where they’ll show off all the work that was completed during the Sprint. The Product Owner gives their thumbs up, and then we share all our hard work with you!
After we’ve collected your feedback, we get together for an internal Retrospective where we identify things we can improve upon in the next Sprint. It then becomes the Project Manager’s #1 goal to improve those specific items throughout the next Sprint.
Rinse & Repeat
Once we run through the process once, we turn around and do it again. And again, until we have a product that looks beautiful and functions seamlessly. And even then, actually, we don’t ever really stop. We’re continuously improving on what we’ve built through regular iterations.
Well, that’s it! There’s our process. It fits on just 3 pages, leaving a ton of room for our team members to work freely, flexibly and most importantly efficiently.
