A guest post from Fearless software developer Pat Kelsh.
Most of Fearless’ work is done through medium and long-term contracts with federal, state and local government agencies. Often the goal is defined ahead of time, before a proposal is even written, the size of the team and work you need to do are known, and you have time to adjust if things take an unexpected turn. But sometimes a client needs something fast, there’s no time to formally build a team and they might not even know the full scope of the problem. Your client doesn’t need the answer. They need something to justify an idea or a new funding priority. You get a 12 week deadline and vague idea of a problem. This is when you need to do a rapid prototype.
With the clock already running and without knowing what you need to do, all the stress and pressure of normal software development is enhanced and if you’re not careful, it can overwhelm the project and burn the team out.
But don’t panic. Take a deep breath and remember the fundamentals.
While the pace may be quicker, still do regular stand ups, planning, and retrospectives. Focus on delivering the best version of what the client needs. And rely on your team, both on the project and at Fearless.
Don’t worry. You’ve got this.
Fearless’ approach to rapid prototyping
In the best-case scenario, we want to take our time, get everyone onboard and focus on delivering a complete, quality product to the customer. But sometimes you don’t have the time to do everything just right and what your customer really needs is for you to build something fast so they can demonstrate this is the right direction to get additional funding.
It’s going to be tough, no way around that, but there are a few things you can do to deliver a fantastic MVP:
- Document Everything: Documentation is the lifeblood of any project, but its utility is heightened when you are developing a rapid prototype. With things moving so quickly, you don’t always have time to dig into any one issue. Everything is in flux and even the core challenge you are trying to solve can be swept away in all the chaos. It is absolutely vital you create a strong foundation of documentation to keep everything grounded. If you get nothing else out of this article, remember this: make a singular project README to house all your notes. While normally you’d want to separate out documentation into reasonable, logical pieces, with rapid prototyping you often don’t even know what the logical order should be. Create a single file, give it the basic sections of Who is on the team, What are we trying to build/solve, Where can I find things, and How do we plan on building this. As information becomes available and things become clearer, fill in the details of each section. As new people are on-boarded, point them to the README and regularly reread it to maintain your understanding of what you are building.
- Single Contact for Onboarding: Since everything is moving so quickly, even the team you are working with is going to be in constant flux. People may be coming and going as your understanding of what you’re building and the skills you need to get it done change. With time so limited, having a new team member build their way up to being a full contributor the way you would in a normal project just isn’t going to cut it. Assign any new member a single contact for onboarding. Ideally, this contact will be someone who works closely with the new team member.
- Get Every Practice Involved Early: There are several main practices in Fearless that contribute to delivering great software services. Product gives the vision, Design lets us know how people will interact with the system, Engineering makes it all possible, and Delivery keeps us on track and coordinates with the customer. All practices play a role when we do our normal development and they need to play a role when we are building a rapid prototype. In typical contract-driven development, things can come together slowly as various parts of the problem and the end solution. But when working on a rapid prototype, you need to bring in representatives from each of the practices right away. Time is tight and you do not have time to let ideas percolate, only to find out that the idea isn’t going to work 2 weeks later. Bring in people from every practice at the start, preferably the actual people working on the prototype. They can give everything the sniff test, even if there isn’t a full days worth of work for them every day. It’s better to catch a problem early than let dependencies stack on top of an early design issue and have to refactor and scramble late in the game.
- Control Your Resources: When time is limited and everything is in motion, it is best to have firm control over your infrastructure and other tech resources. Push to build the prototype on platforms and services you can control access to. This is especially important when working with the government. Getting people access to different resources can take time, time the project doesn’t have. Getting clearance is a slow process, and it is easy to get dragged into lethargic debates about things like routing with teams that don’t share your hard deadlines. Infrastructure-as-Code techniques to give your prototype the flexibility to be spun up automatically on a new infrastructure platform. Build your prototype on a platform you can control, giving access to the people that need it. Once the prototype is ready for delivery, deploy it to the customer’s environment. Optimize for the speed of your team.
- POC vs MVP: You might receive some pushback on this but it is vital that you clearly define with your customer whether you are building a “Proof of Concept” or a “Minimum Viable Product” and that you hold to that decision. This can be a subtle distinction and some customers may not see much difference but defining this can be the difference between a success and failure when it is time to deliver. An MVP is, at the end of the day, a fully fleshed out product. While it might not have all the feature bells and whistles, what it has is fully formed and understood. CI/CD pipelines are established and testing plans are implemented. The infrastructure you need is defined. Edge cases are handled. Interfaces have been designed and tested for 508 accessibility. Everything to bring the prototype into production has to be done when making an MVP. On the other hand, making a POC involves finding the happy path and demonstrating that it works. The need for testing or edge case handling is reduced, but the finished prototype is not ready for production. While building “just” a POC might be attractive to customers, they need to understand that what they get at the end of the prototyping will not be production ready and changing tracks midstream will jeopardize the entire project. Once the team has determined and budgeted their time for a POC deliverable, adding on the extra work to make a MVP will require a herculean effort.
- Everybody’s Human: This is the most important guideline, both in rapid prototyping and in life. Remember that everyone is human and that you are human. Everyone will be under pressure when delivering a rapid prototype and not all people will be feeling the stress equally at the same time. The customer will probably be feeling the pressure from their end too and might not even know what they want, even as you go through the necessary design steps with them. Give each other space and support, reach out to team members who are in the thick of it, and try to share the load. A little consideration for each other can go a long way. And remember that you, yourself, are also human. Don’t just power through when too much gets piled on your plate, whether from the project, other things at Fearless, or just life in general. If you’re starting to feel overwhelmed then reach out, see if your teammates can pick up a bit extra, see if features can get cut, see if you can get some extra support. Don’t martyr yourself.
Hopefully you’re feeling better about tackling a rapid prototype. You’re putting together something from nothing in less than 12 weeks so things could get tough as you’re trying to put it all together but if you’re smart, work as a team, control the scope, and keep everything documented then things should be a lot easier. Don’t panic, take your time, and don’t let perfect be the enemy of good. When it’s all over the customer will be impressed with what you’ve done and your team will have pushed government services leaps and bounds past where it was before.
