In the past, we’ve shared our secret sauce for strong software teams, and those principles apply to teams of all sizes. However, when your development team is small (we’re talking 1-15 team members), there are a few specific best practices to be successful.
Strong People
It’s probably no surprise that the first one is all about people. We talk about people a lot, and that’s because you can have the sharpest tools and the cleanest processes, but without strong people, none of that matters! As we shared in our Software Core Principles blog, we know that 65% of a team’s productivity is a result of the right people with the right aptitude and attitude, and the rest comes from processes and tools. You can’t build enough processes to protect you from poorly performing people! And, frankly, who would want to?
You’ll likely start with 1-2 developers and add more as demand and budget permit. So, this isn’t a one-and-done step. Always be on the lookout for sharp staff to add to your team. Take your time and pick the best.
Pro Tip – We see many small teams start by selecting tools. Please avoid that trap. Tools are not a silver bullet. Start by picking sharp trainable people with a “Can-Do” attitude.
Process is a distant second and you will naturally pick technology so we’re not going to even cover it. But, back to process — there are some simple processes you will want to have in place to help you lean forward into success.
Define and Prioritize Requirements
You will likely do most of your requirements work in your Agile(ish) process (see below), but let’s be honest, the project won’t even get off the ground without first defining the need.
Start by defining the requirements in partnership with the key stakeholders. We’re big fans of capturing it initially in Microsoft Word (or Google Docs) because the stakeholders can easily read through it. We also like the idea of organizing the requirements functionally. For example, if you are building a system that allows users to apply for a loan, you might setup the high-level requirements into the following sections: Registration/Login, Application Process, Loan Review, Credit Checking, Notification/Communication, and Back-End reporting. In this document, you can simply use bullets to describe the detailed requirements in a given section. If you don’t define the core requirements up front, your team is likely to spin and churn because there’s no focus!
Go Agile(ish)
We say “ish” here because it’s important to stay flexible. The fundamentals of Agile are sound, and data shows that Agile teams are significantly more productive. However, when you’re a small team, you don’t need to be “by the book”. Get started by doing some small development, then test it, release some functionality to your stakeholders, and repeat. Work through a release schedule that’s roughly every two weeks (but not so structured that it has to be every two weeks). Use the basic core fundamentals of Agile to your team’s advantage and be flexible where you can. (P.S. you can learn more about Agile here)
Even though you defined a basic set of requirements early, we recommend that you create user stories and use this Agile(ish) process to groom (AKA refine, clarify, complete, etc.) the user stories, and prioritize them with a key stakeholder (Agile calls this the product owner). Work hard with this person to get them involved; it’s critical for your success and the project’s success. If you don’t prioritize alongside the project’s stakeholder, you run a strong risk of building something different than they wanted.
One of the reasons Agile is so effective is because the team works together and at the end of a two-week sprint, they meet to talk about what they learned, what went well, and where they can improve. Please be sure to implement these Sprint retrospective meetings. It will dramatically increase your efficiency as your team learns and adjusts.
Reasonable Process Structure
You’re a small team, so let’s be reasonable! You’ll want to have some rigor and structure to ensure you are protecting your software investment, but you don’t need a lot. Here are a few recommendations to building a minimally-rigorous structure:
-
- Capture requirements, tasks, and bugs in Jira, Azure DevOps, or similar tool, and assign a t-shirt size to all work (XS, S, M, L, XL)
- Keep code under strict configuration control. If you have a 3rd party developer, make sure that you have access to all design, code, and database. Ideally, you are the admin so you always have control of the code.
- Test the system. Build test cases and ideally, have someone other than the developer test. As a minimum, we recommend you build both positive and negative test case headers in Excel, where you describe the test, define the expected results, and track whether it passed or failed. You don’t necessarily need detailed steps when you are a small team, but you do need expected results.
- Present to stakeholders early and often. Not only is it important to define and prioritize with your stakeholders at the beginning, but keeping them informed throughout the project can be critical to its success.
Basic Project Management
Keeping your projects on schedule and budget is critical to the success of your team, but sometimes this can seem like a daunting task, especially for a small development team. We recommend keeping it simple! Start by defining a simple project plan that includes tracking cost and effort, and reporting regularly to your senior leadership. Keep these basic at first – for example, use a simple time tracking system to track hours (or just Excel) and start by using one project code for the project. You can always get more advanced later on (by tracking individual functions, like business analysis, development, test, and support). We also recommend using t-shirt sizing to estimate the effort. For example, XS=30 min, S=2 hrs, M=4 hrs, L=8 hrs, XL=16 hrs. To help you and your team get better at sizing, we recommend in every sprint retrospective (approx. every 2 weeks), you review how much work you actually got done vs. what you planned to get done. Invariably there will be many tasks that you just didn’t think about, but that sucked up time. If you do this, you are now measuring three critical project management variables: cost, effort, and work completed.
Lastly, but arguably most important, is to regularly communicate with leadership on your plan and how it’s going. Report on cost per sprint, effort per sprint, and the work accomplished per sprint. Given this simple methodology, you will also be able to begin forecasting when certain major functions will be completed… because you know they’re going to ask! Remember that they’re the ones funding you, so keeping them updated (and happy) is key!
While there are other practices to take into consideration with a small team, we find these are the most important. In short, you can always get more advanced with your methods, people, or processes, but starting with these builds a strong foundation to achieve that growth. Which of these practices is an opportunity area for your team? Let us know!
