9 Steps to Jump Start a Project

Simple steps to quickly collect requirements and iterate before starting development.

As a software developer when starting a new project it is common to just want to jump directly to build the new application or feature immediately, thinking that all the planning beforehand is irrelevant for you. While from a developer’s perspective this might seem better because you can get something out the door faster, most of the time it isn’t because you end up with code that is not easy to maintain and scale.

The problem with starting development right away is that most of the time you have no clear direction of what NEEDS to be part of the project, and when requirements change during development, iterating on what you’ve done so far will be sub-optimal, since you might have a completely different approach if you start with a blank canvas.

My team and I have been going through a process to jump start a project to help everybody get on the same page and define what NEEDS to be created and how this can possibly be created before writing a single line of code. In this article I will be going through the steps that we’ve been following. Keep in mind that we have iterated on these steps several times based on what we learn each time we run through them, and these steps might vary for your team or project.

1 — The Gathering

Get a room with all the people you think need to be involved. At a minimum I would have someone technical and someone that understands the business, since we want both sides to be on the same page of what is about to be developed. You don’t want to have more than 5–6 people in the room since this is just a jump start and you want to keep times to a minimum.

Recommended things to have in the room:

• Whiteboard — The biggest whiteboard or any writing surface that you can find, since there will be a lot of brainstorming and idea capturing along the way (if using a whiteboard, make sure to separate sharpies from the dry erase markers, I can’t tell you how often we accidentally mix them up).
• Sticky Notes
• Snacks

2 — KISS

Don’t get too excited, in our case it means “Keep It Simple Stupid”. We write this in big all caps letters on the board before anything else. It is common to get sidetracked on things that become super complicated and might not be valuable. So whenever we start getting into one of these situations, someone points to the board and if we all agree that we are going into a rabbit hole we write the idea down and have a conversation about it, sometimes those things never happen because they were assumptions that weren’t actually needed.

3 — Go with the flow

Now we got everyone in a room with all the supplies and the KISS mindset. Let’s start!

We like to start with a simple flow diagram of the process, in our case our Product Manager has already given it some thought and has something predefined but not required. We start going through the flow and defining any decision points that will be happening and what the results will be. This is helpful because it can give the technical resources a good idea of how the application will flow and provides and opportunity to bring up questions and start iterating on that flow based on any new findings, and remember to KISS.

4 — Who are you and what do you do?

With a simple flow defined we need to identify the key users and their roles. What we like to do is add the users and roles into a row and give them a meaningful name (i.e. Applicant, Environment Administrator, Application Administrator, Location Manager, Employee).

At the same time we start identifying each of the business concepts, and identify the user that will interacting with that concept. We write these on the board with color coded boxes where each color is one of the users we have identified. If there are two users that can interact with the same business concept, we just duplicate the box with the other user’s color.

5 — Get your story straight

We now start defining user stories. Using the list created on step 4 we write at the top of it “As a …” and on the right side of each row we will start adding the user stories. We do these with sticky notes since they will be moving around.

You will end up with sticky notes that look like this:

• I want to hide ‘X’ field. (This would be on the Application Administrator row)
• I want to add an application. (This would be on the Location Manager row)

Here is a great article explaining how to write good user stories.

At the end of this step we go through the flow and the business concepts and make sure we have not missed anything.

~If you want to take it a step further you might want to do full user story mapping, here is an article that talks about story mapping and a few tips and tricks.

6 — Split ‘em up

At this point both the technical and the business people have a good idea of what we are building. What we like to do next is jump to the technical side. We follow OutSystems 4 layer canvas design, which helps by clearly defining the Modules the application will be composed of and what layer they belong on (Orchestration, End User, Core, Library), we split these into single deployable units, so that we can easily iterate on these independently. Before splitting a module, we make sure if they will need to be deployed separately or simply if the module will become big enough that it will be hard to maintain. We then find any logical splits so that we can minimize the occurrence of multiple developers working on the same module to avoid merge conflict.

7 — Validate the modules

Having all the potential modules defined, we visualize any interactions and draw them on the board. We want to start validating our architecture and to accomplish that we follow 3 simple rules specified in this article. This step requires multiple iterations even after these meetings since we need to go back to these diagrams and update each time a new concept or feature is added to the application. This is important for the future of the application, since this is the point where we can start over engineering something making it hard to maintain.

8 — Dig deeper into the modules

We then take each module and identify the pieces that will be part of the it. For example for an End User module we can have:

• Location Manager Dashboard.
• Application page (where the applicant will enter their information).
• Application list page (where the location manager will view all the submitted applications).
• Field configuration page (where the application administrator can configure the forms).

Here you can start figuring out if you need modules to be services that have REST endpoints exposed or if it will be a component that needs to be directly consumed by any other modules. And keep in mind that this might change your module structure since you can start finding better groupings or separations that end up with different module definitions.

9 — Wrap it up

Now you have a good definition of the application both from the business and the technical side. Now we go through the flow and look at every piece that we have written on the board and make sure that everything is covered on every level.

Next Steps:

• Take pictures of everything on the board and document somewhere. We use Confluence by Atlassian to keep all of our documentation and notes.
• Take all the User Stories sticky notes and add them to your system of choice to manage stories.
• A good thing to try is to build a prototype or a proof of concept. This is very useful because you can have something for sales to use, or something you can present to clients or end users to start gathering feedback. Here is a article by Allen Helton, that talks about how to create rapid prototypes and really get something valuable quickly. Rapid prototyping is a valuable exercise since you don’t have to spend a lot of time on it but you get very good information out of it and let you course correct immediately instead of 3 months later when you are done with the application.

Closing thoughts

I can’t stress enough how important iteration is, not just for this process, but whenever you can iterate on something in smaller pieces, you can get immediate feedback and correct yourself quicker. You don’t want to spend too much time building something that might not really solve the problem. It saves time in the long run, even though it might seem like you are throwing away a lot of code at the end, the benefits are huge.

This process has helped us out find issues we had never thought about early on, and as a developer really having a clear idea of what you are building, who you are building it for and how it is planned to be used, has helped me change the way I develop applications.

Keep in mind that this process might not fit directly with your team, even for my team this process changes slightly every time so don’t be afraid to try it out and adjust it as needed.

Does your team do something similar? Did you try these steps? How did that go? Please let me know in the comments.