The first thing we do when we start a new project is to align our teams on the preferred management approach. At Solid Digital, we build marketing websites, Smart TV applications, mobile apps, custom web applications , you name it. We’ve also dealt with different types of organizations, fulfilling the needs of startups and established brands or service companies.
What continues to ring true is that the project type and company culture fit determine how much management and which controls need to be put in place. It’s better to be aligned from the beginning and to plan with the end in mind.
In every new engagement, we ask ourselves these questions:
- What type of project is it (site or app)?
- Will this project have multiple phases?
- How simplistic or complicated is the project?
- How big is the team involved?
- What does done look like?
The answers to these questions determine how we should run the project. At Solid Digital we have 3 flavors of project management methodologies that we use.
Streamlined waterfall:
This is the common Gantt chart style of project management that we are all used to seeing. It is mostly sequential and tasks or phases are lined up in a nice waterfall. This is a very good methodology for things in a particular order and working towards a traditional schedule with a small team. It fails on bigger projects or teams doing many things at once. Small projects that run on longer timelines generally are managed in this way.
Agile-fall Light:
Next next level up would be our Agile-fall Light methodology. Agile-fall is how we describe our version of the Agile methodology. It keeps the concept of sprints, velocity and scrum but also works with organizations that have very common constraints (time, budget, etc). Pure agile breaks down somewhat in this scenario and is better understood at a product company or within your own organization. All work is broken down into user stories, splint into proposed sprints (2 weeks at a time) and tracked using agile reporting methods. This approach is great for projects that are a little longer, more complicated or has a bigger team. It fails if the project is on the complicated side or requires a robust test plan.
Agile-fall Pro:
Projects that are large, have multiple phases, require larger teams or are a consumer facing product all fall into Agile-fall Pro category. With agile-fall pro we do everything we do in the agile-fall light version with some key additions.
- We include time to QA the plan and architecture. The wrong architecture can cost unnecessary time and $. Creating a visual plan helps align teams from different companies.
- Implement 70/30 rule: In each sprint 70% of the time is spent on new features and 30% of the time is spent on harding the product.
- Maintain the test plan: We start with the test cases that we know about and the test plan gets more detailed with every sprint. As issues are found, they are added to the test plan. Keeping this up to date is crucial for regression testing.
- MVP planning: When building a minimum viable product, never “fake” anything. Nothing is worse than thinking you are done with a feature to only find out that it looks done but there is more to do.
- Regression testing: Once things are fixed, they need to stay fixed. If an issue pops up a couple of times it should be added to the test plan. Every few sprints the entire test plan should be gone through to make sure thing that are fixed stay that way.
