Responsible Rapid Development Part Two

Pros, cons, good things, and bad to keep in mind during Responsible Rapid Development; that's where we're headed now. The following may enrage or delight you, but be reassured that this is all based on real-life experience; both successes and failures thereof.

Part Two?

Part one of my Responsible Rapid Development (ReRpD) series introduces concepts and strategies for developing a new product or feature in an accelerated time frame, while mitigating risk of failure as much as possible. Where part one focuses primarily on planning, scheduling, and personnel from a project leader's perspective, this article defines specifics and things to consider when doing the actual work; reference this article if you're doing a presentation on rapid development.

Pros, cons, good things, and bad to keep in mind during ReRpD; that's where we're headed now. The following may enrage or delight you, but be reassured that this is all based on real-life experience; both successes and failures thereof. These tips and lessons are best applied to ReRpD but can be applied to other less urgent forms of development practices.

Large organizations and small regularly face the unexpected, so don't expect that you won't find yourself in a rapid development situation.

What is it, Really...

Development - Updating or Creating a product feature, or creating something entirely new. It can apply to anything from building construction, software development, or toy design, to writing an article like this one.

Rapid - Completing two-weeks worth of work in three days. Cut out optional processes, consolidate responsibilities, and simplify task planning so that more time is spent advancing the project.

Responsible - Minimizing the negative impact(s) of a rapid pace of development. Going fast at anything comes with higher risk. Being responsible is to take steps to minimize, avoid, or completely eliminate those risks.

In a nutshell Responsible Rapid Development is pushing the pace to the max, without crossing the red line.

Note that Rapid development typically refers to new development, NOT maintenance. Sometimes maintenance falls into the category of new development and sometimes new development doesn't; deciding whether a project can be developed rapidly depends usually on how tedious the work is.

Pros / Benefits

There are many benefits to rapid development both in business and personal life. The need to get something done quickly is something we're all faced with at some point. Here are some of the key points to keep in mind when considering ReRpD in a business setting.

• Incredibly fast turn-around in deployment of new features, updates, and improvements
• High speed adoption of market trends and innovation
• Order of magnitude greater advantage over market competitors
• Higher retention of staff due to excitement, challenge, and motivation (from potential)

Cons / Drawbacks

Like all the best things in life, there are down-sides to rapid development as well no matter how responsible you are. Consider the following before you plunge your business down a rapid development rabbit hole.

• Higher risk of sub-standard product
• Higher risk of employee burn-out
• Sub-standard customer support due to rapidly expanding feature set
• Blurred lines between what is functional, and what may be functional in the (near?) future

Good Practices For Rapid Development

• Communication!!!! Information must flow so that constructive decisions can be made in a timely manner. Don't over do it though, as excess communication prevents your team from doing their work. Ask questions frequently no matter where you sit in the corporate ladder; don't guess, find out for sure.
• Incremental Projects. Don't just go and say we need to achieve world peace or something, and dive in. If your new project or feature is too lofty to tackle in one bite, break it down into smaller easily-defined parts, and tackle those as discrete individual projects. Smaller pieces reduces risk of the project wasting too much time by pursuing something infeasible, and allows you to then reassess and develop improvement or replacement projects as you progress. This is important at the high-level planning stage, but also for boots on the ground where the work's being done. Small bites!
• High-level goals. Identify (or find out) what the product or feature must do, and ensure it is cemented in your brain. The how is important but there is typically more than one solution to a problem. Gather your options quick, and pick the quickest solution that best meets the project goals (yes quality can be one of those goals).
• Prototypes. Churn out test versions of what you're working on soon, and often. Many problems are easier solved later in the project, which makes planning easier and more accurate. Build something with as many shortcuts as needed to get to a usable stage, then review and reflect on what the best way to build this for real is. Maybe the prototype isn't that far off from the best option, or maybe it's a complete throw-away; either way you'll have a clearer picture of the challenges you're facing, and be better of in the long-run.
• Demos. Don't be afraid to show things off! You can't possibly anticipate all scenarios, so get your prototypes done and into the hands of peers, colleagues, friends, family, whoever. Don't worry about making the demos formal, and don't worry if your finished product isn't perfect; even the roughest prototype will still provide invaluable insight for you and your team in the hands of an outsider.
• Flexibility. You must accept that things will change, and that it's highly likely that you'll have less information than you wish you had. If you're the one doing the work, consider this your license to create. You're in the driver's seat, so let loose and let's see what you are capable of! Of course then you'll try it out or do a demo and realize you've gone about things all wrong, but that's ok because you didn't hesitate, and so solutions have been found sooner than later. Open yourself to feedback, advice, and changing priorities, and you'll get a better final product sooner than you would have otherwise.
• Research/Investigation. Sometimes something just isn't quite as clear as you hope or might think. Don't just jump in and trust that you'll find your way; you can easily get caught in a trap where failure is the only possible outcome, but you don't see it because there's already been too much investment to turn back now. Instead do some research by reading or prototyping; investigate options again by reading and prototyping. You will either find the most optimal solution much easier, or even that there simply is no solution, and that a completely new approach is needed. The sooner you find any of this out the better, so don't be afraid to look before you leap!

Bad Practices for Rapid Development

• Scope Creep!!!. Define the task or project from a high-level, and then leave it there until you're done. Allowing changes into the goals of the project can have a devastating impact on the project, even for seemingly small changes. Changes to project scope add a fog over what is supposed to be a laser focus on the project goals, resulting in a confusion of priorities. Doubt in the value of the work being done will creep in, and productivity and quality will suffer. Of course as well, adding to or changing the project goals will more than likely lengthen the time to complete the project; if you're already on a tight schedule, best to leave well alone and reflect when the project's done.
• Fixed or Rigid Schedules. Avoid as many self-inflicted distractions as possible, so that energy and effort are more likely applied to actual work. Examples include daily meetings, weekly updates, set workday and break start and end times. Imposing such structures breaks the creative train of thought not just for the meeting, but also the lead up to the meeting to ensure one is not late. It's still important to have your breaks and update meetings, but allow them to happen more naturally (as needed and as convenient) and you'll be more productive.
• Planning Details. You're at the beginning, you cannot possibly see all ends. At the beginning of a task there are always unknowns whether or not they are big or small. Trying to force something to happen a certain way is an invitation for trouble. When assigning a task to a group or individual (or yourself), give them as much info, guidance, and/or suggestions as you can, but do not force them to follow it. A good rule to follow is complete the task however you see fit, but if you don't follow the suggestion(s), your way had better be better.
• Enforcement of Standards. Standards are a good thing and should always be followed as closely as possible, but rapid development is not a time to be strict about it. The priority is that the project properly meets the goals of the project and as long as it's not too far out of line, the how is less critical. This one may be harder to accept than others, so you may have to try to find some middle ground depending on the urgency of the project.
• Team Meetings. Getting the whole team together to discuss things like work, issues, successes, etc. are good things, but are also a luxury you can most likely get on fine without. The more individuals in a meeting, the higher the chance that someone attending really didn't need to be there; increase efficiency by reducing work disruption, and limit meetings to the minimum number of individuals required. If the whole team IS the bare minimum needed, consider a different type of meeting instead; for example instead of a team update meeting where all members give updates on status and challenges, have a group leader meeting individually and share only notable/critical details with other relevant team members, or have all members send a text update via email or a messaging application.

Considerations

Some things are neither good nor bad but can still affect your project in large ways; here are some things to consider and/or accept while doing rapid development.

Work Debt

Also called tech debt (when doing technology development), work debt is when a task is completed in such a way that may not be ideal long-term. The debt part is that work will later have to be done to fill in or correct any shortcomings, in the current work. In many cases work debt is frowned upon for a number of reasons:

• It's often easier for someone to complete the work now while they're fresh in the details of what's required; much harder for someone to do a good job later.
• If the shortcomings are not addressed, they can lead to more serious and/or unexpected troubles later on.
• Cost of maintaining the product is increased later in its life, thus costing the project more money than it could have.

Unfortunately for those who abhor any form of work debt, if properly managed it can have a positive outcome during any development process; even more so during rapid development. Work debt can be a positive tool in that it can enable:

• Significant reduction in the amount of time to achieve project goals.
• Maintaining the laser focus on task and project goals, by reducing distraction and allowing development to proceed naturally.
• Discovery and documentation of potential improvements both high and low level that could greatly improve the project down the line, while not significantly slowing development of the project or feature in the here and now.

We can accept that there may be a place for work debt under some conditions, so how do we mitigate the risks so that we can take advantage of the benefits? Really the most important rule here is to document the debt. If the debt is forgotten it can surface unexpectedly at the worst times; if you know it's there, you can plan accordingly. Any system for documentation can work for work debt, as long as it meets the following requirements:

• Anyone can add notes/documents about work debt.
• The documents are searchable such that all work debt may be viewed separate from other documents.
• It is always available/accessible at all times that work or planning is being done.
• There is 'buy-in' from all levels to use the system not just for adding, but for reference during work or planning as well.

Work Tickets

A work ticket is a documented task that needs to be completed. A ticket is a great way to keep track of work to be done, that's in progress, is blocked by other tasks/deliverables, is complete, etc. It's also a great place to put all details associated with that task, as it's a single place where all details you need should be available. The ticket contains what the task is and usually some details about what the potential solution looks like. Tickets are assigned to a group or individual, who then does the work.

Work tickets come in all shapes and sizes, and with all sorts of types of data and systems for organizing information. Some approaches are better for accuracy, some are better for quickness, and others spell out in detail how to accomplish the task. With so many variables in play with how tickets are built, there's a big risk that your tickets can actually impede rapid development instead of helping it. There's no one-size-fits-all strategy for how to craft your tickets for ReRpD, but here's some suggestions to keep in mind:

• Provide high-level details only, giving the individual doing the work a wide latitude to apply what makes sense.
• Written with a particular skill-level or skill-set in mind, and then assigned to the individual best suited for the work, who is also available to do the work.
• Assigned to a group or individual by the Project Executor or designate, as opposed to by committee or first-come-first-serve.
• Avoid too many details and specifics on the how, and focus instead on the why. Knowing why something needs to be done helps those doing the work understand their work, and thus make better decisions along the way. Understanding can also lead to previously unanticipated scenarios to be uncovered, leading to a better project either now or later.

Testing

Alright, this one's a loaded one. Bottom line is that you CANNOT release something that hasn't been tested; the tricky part is figuring out how much and what type of testing is needed. There is going to be 1001 different opinions on this topic, but the key is to focus on a) the key deliverables, and b) the quickest route to success. Testing is a bit part of any success, otherwise how would you know that something works? Having said that though, testing can be time-consuming and can lead to greater problems than solutions. So how do we test to ensure a viable product, without sucking all our precious time up? The bottom line is that there's sadly no one-size-fits-all solutions, and you're going to have to determine what you needs are. Having said that though, here are some guidelines for testing during ReRpD.

• Only unit test the most critical of pieces: unit tests can be simple, but often are time-consuming and difficult to get right. They have their place but typically only truly realize their value later, as a product matures. Changes are made, and you must ensure that a feature still works as expected. Build too many unit tests and you waste large amounts of development time. To get the most of your testing, you must weigh the value of the test vs the time spent building the test and running it. I highly recommend you do unit test, but focus the tests only on the most sophisticated and critical pieces of your project.
• Integration testing is your friend: unit tests verify that a single component works, while integration testing ensures that everything is working from a user/third-party perspective. Typically this kind of testing is easier to perform, as it relates simply to using the product or application.

And So...

Really the key to successfully implementing/using ReRpD for a project, is to stay focused on what you actually need to succeed; avoid distractions and non-essentials tasks and meetings. Break things down into manageable tasks, and don't be afraid to spend some time investigating something prior to doing the work. Keep this in mind and you have a good chance of producing your new project quickly and effectively, and hopefully even with time to spare.