Fullstack development start-to-end - Part 1: Software Development Lifecycle
Written by Thomas Coldwell on Saturday, July 3, 2021 4:09 PM
Welcome to a series of blog posts I've decided to write about software development as a whole. While I've been learning over the last few years I've seen numerous blog posts telling me I should be doing testing or using linting tools or multiple environments as well as far too niche blogs talking about how to do it all with a very opinionated stack. This gave me the confidence to get started with individual areas of software development, but never made me feel like I had the ability to build something start to end without running into other issues or being worried that everything would suddenly break because I'd missed some crucial but not-so-obvious config.
Hopefully this series will help put a lot of this to rest and focuses on a tech stack agnostic way of shipping good, quality software that you have confidence in and that your users will love. If that sounds good to you then let's get into the structure this will follow:
- Part 1 - Software development lifecycle & roles
- Part 2 - Initial project research
- Part 3 - Software development toolbelt
- Part 4 - General software best practices
- Part 5 - Software testing
- Part 6 - Git and version control
- Part 7 - QA and deployment
- Part 8 - Iteration and innovation
Before we can get into the lifecycle we need to outline a few clear roles for your team. This helps us scope the responsibility of different phases and sessions within the lifecycle so it doesn't become one team member doing all the work or let us miss important things because nobody thought it was their job. There is a few key roles that we'll cover here, but it's important to note these DON'T have to be different people. In fact in a lot of startup environments you're never going to have enough people to manage all of this or if you are flying solo you might do all of these jobs at once. A better way to imagine these roles are hats - they can be worn by different people, but generally one person owns one or more hats:
- Executives COO, CTO, CEO
- Domain Advisors
- Product Manager
- Scrum Master (technical lead)
- Product team members
Software Development Lifecycle
During software development there are lots of different lifecycles; each on their own timescales. The most common one you'll have likely heard about is sprints, which are normally 2-4 week time-blocks in which you or the team works to ship incremental, new features and improvements. In total though I have found its best to keep the following three lifecycles in mind:
- Long term project plan (3 - 5 years) - over this grand timescale, what do you envision your idea or product may eventually solve? This is a crucial question and helps set the stage for all of the actions we take on smaller timescales; ensuring we are working towards some core objective and not deviating too far off course
- Epics (1 - 2 months) - these help to us to focus on what are key business objectives are and deliver major features to the product. The short timescale let's us account for business objectives changing which typically happens over this kind of timescale, but obvious may change more or less rapidly dependent upon what industry your software is for (e.g. crypto = fast, ecommerce = fairly slow)
- Sprints (2 - 4 weeks) - these are where the work actually gets done and involves the team actively planning out how features are going to be built in workable tasks and user stories (commonly referred to as tickets)
How to create a long term plan?
For most software developers this isn't too much of an issue or even a requirement, but for new products or startups a long term plan is your North Star and keeps everyone moving towards the same goal. There's a few different ways to formulate this but the best option is usually to:
- Get your team in front of a whiteboard - this just makes it much more open and illustrative for people to share their grand ideas
- Start by going around the room and write a whole list of things you want to achieve; big or small get it written down - this could include being bought by Microsoft, preventing cancer or helping create societal equity
- The next step is to then start getting realistic about these ideas and whittle them down to things you and your team can knowingly achieve - maybe you can't prevent cancer altogether but your software can help identify much faster than anything available today
- Once you've got this list you can then look and see what things have the best time-value cost, that is which objectives will create the most value for your users in the least amount of time and with the least amount of complexity? You can then sort your objectives by this metric and add a rough timescale to each and the dependencies between each - what you should then end up with is something resembling a Gantt Chart that you could either digitize in Microsoft Project or whatever works for you (Notion is my go to for this kind of project management)
- Share this with everyone and keep it very visible - this will become a reference for a lot of decision making in the next sections
- Take a break
What becomes an Epic?
An epic is usually going to be one or more of these long term goals that you've put down - it could be creating an MVP or adding stories to your social media platform (RIP fleets). To keep things agile however, epics shouldn't just be a trickle down from your long term plan - in addition we need to take into consideration your objectives as a business which are changing fairly rapidly as well as user perspective and technical changes.
A good way to be able to formulate these epics is with something called a Program Increment Session. The idea here is that we get everyone in your company to come together and share ideas on the landscape of your business from opportunities into lucrative user markets to you needing to spend some time clearing up all the flash animations your site was built with originally (RIP flash). The aim of the session is to take all of this input and be able to create a big list of user stories which can range from new products down to changing the color of your login button. Once you have exhausted through your sticky notes you'll hopefully start to notice themes of things that need to be done - maybe it's a big overhaul of your onboarding flow to improve user acquisition or improving the accessibility of your app either way you can start to group these off and these become the headlines for your epics!
Once you've got these down they can actually help form a lot of your product backlog (we'll touch on this shortly). These sessions should generally be run every 6-8 weeks or so (whatever works for you or your team) and really take some time out to run them effectively, don't just try and squeeze it all in and hour's meeting and let everyone have a chance to voice their ideas.
Sprints and Scrum
- Scrum structure e.g. consists of 4 key different ceremony types
- Product backlog -> Sprint backlog (through sprint planning sessions)
- Sprint reviews
- Sprint retros (kind of optional for small teams - PM should identify issues)
- Tips for having an effective sprint