Responsible Rapid Development - Part One
Strap Yourself In
For the uninitiated, Rapid Development (RpD) is the process of creating something new in much shorter amount of time than it should have. It often involves long hours, shortcuts here and there, and is not without risks, but the results can be nothing short off astounding if done right. If you've ever been a part of a small or startup company, you've most likely taken part in RpD whether you know it or not. Thin budgets, limited workforce, and no time to spare are the driving force behind the entrepreneur's work ethic, and quite often it's a sink or swim scenario; develop your product and bring it to market, or stumble and falter until ambition and money runs out.
RpD is not just for small companies and startups; even the biggest corporations suffer emergencies here and there, or are caught unprepared by a competitor's new product announcement. Action needs to be taken or customers will take flight, and shareholders will circle like hungry wolves. If you find yourself in one of these situations, strap yourself in and let product development run on rocket fuel; if you don't, well...you know better than I the cost of failure.
Up For Some Risk-Taking?
Let's say you are an unfortunate soul who's in charge of a team that has to churn out a new product ASAP. There's no choice but to build something fast and loose, but everyone knows that Rapid Development is fraught with risks. Shortcuts lead to inferior products, and rushing projects results in missed steps and forgotten features. Rushing things isn't going to produce the product you need, but is having something better than nothing? For you in this scenario something is better than nothing, so it's time to roll the dice and take some risks. Maybe just maybe, luck will be on your side.
The risks may be unavoidable, but that doesn't mean that they're not manageable. Steps can be taken to ensure that the core of the product is in fact of high quality, and any missed steps or issues are relegated to non-essential features. From here on we're going to be talking about Responsible Rapid Development (ReRpD), and perhaps you'll see that there's hope for you yet.
The Plan
You need to deliver a product, and you're short on time all-round; you need a plan! A ReRpD plan must avoid getting bogged down in less-essential details, and instead maintain a laser focus on critical elements. The plan must outline as briefly as possible exactly what the minimum viable product is, and what the absolute drop-dead date is for delivery. When I say absolute, I mean it. None of this few days before opening to prepare or anything like that; the absolute last minute or hour that you can put the thing in the done category, and all hell won't break loose.
Specifics for minimum viability of the product, and the absolute last date and time for delivery; get these and then get sign-off and agreement from whomever is in charge, so that these cannot be changed no matter what. If there is even the slightest opening for additions or adjustments, the whole project becomes subject to change, and risk increases exponentially. Even if you know there's wiggle room, shut it down immediately; provide them with an 'after-crisis' jar for them to put their requests in. They'll go along with it because it's the price to pay for miracles.
You must have the confidence, ability, and authority to say no to your boss, even and especially if the boss is you!
Meet The Team
ReRpD can be successful with teams of all types, but a few roles are critical to success. These roles may be broken down and/or duplicated amongst more than one individual, but they all report to you the Project Executor (PE).
A Project Executor combines the roles of a Product Manager, Project Manager, and Operations Manager all into one. As the sole individual in charge of high level design of the product and scheduling of the project, and also with the authority to assign staff and resources, a PE is able to make decisions and changes on the fly without the delays caused by extra approval requirements.
The Project Executor is responsible not just for planning the project, but also scheduling, resource assignment, and even getting their hands dirty if that's what's required. They decide what's to be done, when it's to be done, and they are responsible for ensuring it gets done; it may not always get done to the original plan, but it must be done to the approval of the PE.
A PE does not need to have all the skills necessary to do the job, and may surround themselves with those who do. Delegation may be required and is safe for the project, so long as the PE is instantly apprised when issues arise, or when positive break-throughs occur. A PE must be intimately involved with all aspects of the project, so that they may ensure that no person or resource is sitting idle unless there is no choice; essential people and/or resources must be available at the optimal moments to maintain project momentum. If (when) optimal timing is or will be impossible it needs to be anticipated by the PE and/or their team, and additional tasks assigned to fill the gaps.
Tasks and Scheduling
Downtime is your enemy anytime you're trying to accomplish something quickly, so tasks need to be scheduled carefully to ensure everyone always has something to do. Don't be reckless and a slave to this however to the detriment of your team. Many people do not task juggle well, and will perform better if allowed to focus on a single task. Strike a balance between optimization of the schedule, and working efficiency of your staff.
Tasks/tickets need to be slight on details, and heavy on high-level priorities. Focus on the most important items, and allow your team to make decisions on the smaller details. Tasks should be larger in scope to simplify scheduling, while also keeping in mind the skillset(s) of those assigned to complete them. Tasks need to be crafted to match the skills of your team, so that you're making the best use of those you've got. ReRpD is not an ideal time for hand-holding and training staff on new skill development, but if someone (or some team) does perform well, slowly increase the difficulty or expand the type of work assigned to them; show confidence in them, and you help them help you.
Try to anticipate the critical elements of tasks, but encourage and accept feedback from your team on decisions. If you decide not to go with a team-members' suggestion, they must know that further debate puts the project at risk; they must get on board. Do not forget their suggestion if there's even the slightest risk that you're wrong. Make a note and be open to revisiting it should the need arise.
You must be willing to adjust your schedule on a regular basis.
Team Size and Operation
Rapid Development can be accomplished with teams of all sizes, but for it to be done responsibly, the team must be organized into small self-contained units. Each unit must be laser focused on its assigned task, and should be empowered to make the majority of design decisions on their part of the project. Give them the "it must do this" list, and let them fill in the gaps. Check in often to keep track of their decisions to ensure that they're on track. Some teams and/or people will require little to no further direction, and others will require more vigilant monitoring. Either way don't make them feel like you're hovering, just that you're there to nudge them if they steer off track.
Personnel
If the project is long in length, be wary of staff burn-out. Rapid Development is not for everyone. Some people thrive and prosper until pressure, while others crumble and shut-down. Personally check-in often with team members to see how their work is going, and how their feeling. Check-ins should not be scheduled (where possible), and should feel as informal as possible for both parties. Informal meetings promote more honest sharing, which gives you a better insight into how they're really feeling. Don't press for information, take what you can get out of natural conversation; it's better to have quality information as opposed to lots of info that you can't trust. If an employee is uncomfortable or feels their job could be at risk if they talk, then they'll shut down and you'll get nothing. These people are the ones making the project a reality, and are critical to its success. At the end of the day your staff need to feel comfortable with their PE, and you've got to have their best interests in mind.
Whether your team is big or small, you the PE are also at risk of burn-out. Delegate where possible and have trust in your team, and take the time to step back and do a check-in with yourself as well. You have an out-sized influence on this project, so stay fresh to keep the project on track.
Prototypes
Prototype often. Consider yourself a sea captain on a long voyage. The goal is to get somewhere, and you have a plan on which way to go. You're not going to plan your route down to the meter for each coordinate, but rather make adjustments for tide, wind, and weather as you go. Mock screens, sketch in shapes, 3D-print or mold a clay model; do whatever you can to make sure that by the time the product is finally done, you feel like you've used it a hundred times already.
Prototyping brings the unexpected to life so much easier. Try something for real, and you'll know right away whether you've imagined something wrong. Show your prototypes to outsiders to get feedback and first impressions. Let them provide feedback from an impartial point of view. Encourage feedback, and don't take things personally if they don't like it as much as you do. Swallow your pride and accept the feedback; take what they've said, draw your own conclusions, make adjustments, and you'll end up with a better product in the end.
Minimum Viable Product
Back in the planning stage, you gathered the details on what the minimum viable product needs and looks like. Do not stray from this unless absolutely necessary, and strive to meet this milestone as early as possible. Meeting this goal early gives time for additional testing and refinement of existing features, and improves the project's chance for success.
Only once the minimum viable product has met its goals and the satisfaction of the team, can there be any discussion about other 'nice to haves', etc. Don't even permit discussion on completing additional features for the product, until the minimum viable version is rock solid. Last thing you want to do is add new features, only to find out that something was wrong with the critical features.
Risk Management
Careful and upfront management of the risks is critical for all projects, but it is even more crucial during RpD. Not only is the cost of failure often higher in rushed projects, but the chances of catching and/or recovering from mistakes is lower. Before you begin you will be well-served to document the biggest risks to the project. Risks are things like user apprehension, system load, uncaught bugs/issues/failures. Compile a list of the most vulnerable parts of your product/system and/or rollout, and you'll be able to focus energy to test and retest those areas to reduce risk.
Finally
Of course the biggest risk is whether or not you can complete everything in time. Maintain your focus on the minimum viable product, the productiveness of your staff, and all the other stuff I just threw at you, and you might just come out of this with a smile on your face!
Want more? Check out Responsible Rapid Development Part Two.