Digital Flightplan - Takeoff

Are you fascinated by the idea of building mobile / web applications in a better way? Setting the focus on key business functions, preventing overspending, minimizing overhead, maximizing efficiency, and actually getting products shipped to users? If yes, then this guide is for you.

This guide is aimed at business and project owners, who are keen to develop software like a lean startup. The tips & tricks introduced are the distilled learnings from our work with 100s of digital projects ranging from multinational conglomerates to modest startups. We are confident our guides can save you time, help reduce risks and make your projects run smoother.

We we can help you make development projects great again! :)

Terminology

If you're not familiar with software development terms you might benefit from refrening this list for some of the terms used in the guide.

• DevOps = DevOps is a software engineering culture and practice that aims at unifying software development and software operation.
• POC = Proof of Concept
• MVP = Minimum Viable Product
• Test / Code Coverage = A measure used to describe the percentage of the application’s source code that is executed when an automatic test suite is run
• GDPR = General Data Protection Regulation, regulations to strengthen and unify data protection for EU citizens
• User Interface / UI = The user interface is the space where interactions between humans and machines occur.
• Wordpress = WordPress is a free, popular and open-source content management system.
• WooCommerce = WooCommerce is an open source e-commerce plugin for WordPress

1. POC, MVP, what the devil?

The Problem

We are living in the age of acceleration [1], where the rate of change is constantly accelerating and old methods of doing things fail to keep up. Software development methodologies are no exception. A large number of organizations still miss the flight when it comes to running their software application projects effectively.

This is evident in the staggeringly high number of IT projects failing in either all or some of the core measures like budget, time or shipped features. [2]

One reason for this is that software projects are typically run following the traditional waterfall model: (1) Setting the time frame and budget; (2) Proceeding to a planning stage, where designs and other legit-looking schematics are produced. Sure this model makes you feel well prepared. The thing is, these two steps take a lot of time and they all happen before any actual development work is done.

This approach could work if you are building something simple and you know exactly what you need. This is rarely the case. More often this sets up your project for failure by having a plan that is already deprecated when you start, a budget that is not tied to reality and a time frame that was pulled out of the hat. Most application projects are complex and have too many variables to be successfully run in this manner.

“No business plan survives first contact with a customer.”
-- Steve Blank

Another common reason is that the development process gets detached from business needs. This results in a waste of resources as wrong features are being developed, and heavy process overhead is killing any potential for a turnaround.

You need an efficient way to communicate between the development and the business side. Otherwise, you’re doomed to waste a lot of hours on heavy, soon-to-be useless specs and then still end up developing the wrong features.

The Solution: Enter Lean Startup Methodology

Companies - large and small - have a great opportunity to learn from startups when it comes to running application development projects. By adopting startup-minded practices, you can run software projects with less risk and a better chance for success.

The guiding principles of lean startups are:

• Experimentation over planning
• Customer feedback over intuition
• Iterative design over design upfront

You should be able to use minimum resources to learn from real user feedback and analytics to guide your process - no matter whether your users are internal stakeholders or external clients.

There is nothing quite like having the actual product at hand when discussing usability and features. We humans are not good at visualizing complex products and interactions by reading specs or looking at mockups.

“If a picture is worth 1000 words, a prototype is worth 1000 meetings. “
-- A Saying at IDEO

To follow these ideas, you can approach building software in a better, more modern way. Taking a lesson from the lean startup approach you can approach a new project with a two-step process:

1. Put together a Proof Of Concept (POC)
2. Build a Minimum Viable Product (MVP)

Proof Of Concept (POC) is a project that tests the core ideas and concept internally for technical and business feasibility. By first building a POC, you get to start with minimal risk without a risky long term commitment.

The goals of your POC could be for example to:
Learn if the technology works and is suitable to solve your business problem
Be able to take that prototype to your next meeting with stakeholders so you can have less and better meetings
Try working with a new team/vendor; test multiple teams with small POC projects and choose the best to work within the long term

Real-life example: We observed a great example illustrating how not to do things in a large-scale client application project. One of the project’s development managers was describing his team’s quarterly achievements having spent three months designing and developing a demo application. The big achievement was the 95% unit testing code coverage. Now the demo was ready by their terms, and in the next quarter, the goal would be to present the concept to stakeholders for the first time and get first test users in to gather feedback. In his own words: “...To see if this application is of any use.”.

By now you might see some issues with the approach highlighted in the example. Next time ensure you are building something of use by getting some real feedback earlier in the process. Especially before investing considerable effort on building a demo project with 95% test coverage.

After the POC, you’ll want to build the Minimum Viable Product (MVP), which allows you to validate your software with actual customers. To explain what an MVP is, Eric Ries describes it: “A minimum viable product is a product with just enough features to satisfy early customers, and to provide feedback for future product development.”

Creating an MVP to gather insights is a far less expensive approach to product development than starting to build a complete product based on idea level guesstimates regarding what the end-users may find useful. Trying to build all the features you think you need all at once will increase costs and risks for project failure due to incorrect assumptions.

The goals of an MVP are to:

• Get real users & gather insights with less risk
• Validate possible business idea and value by asking for money or measuring time saved for example
• Works as a case study and possible basis for the next stage of developments justifying further investment

Remember, success can be also learning that something does not work - without having wasted big bucks on the learning.

The last step is to understand that there is no last step. A software project is never finished. The MVP should already be usable by real users and the development continues from there, adding intelligently more layers of complexity as the project grows towards more mature stages.

Even if you introduce more processes and complexity to the project, it is critical to keep iterations fast and closely tied to business needs. The slower the iterations, the more resources end up being wasted on developing things you and your users don’t need.

In the next chapter, we will be looking into how you can take this from idea to implementation.

Sources

• [1] https://www.amazon.com/Thank-You-Being-Late-Accelerations/dp/0374273537
• [2] 67% of Large IT projects fail regarding budget, time & features. - The Standish Group, Chaos report

2. Let’s get the party started

Now that you know what you’re building, whether you decide to start with a POC or to proceed straight to building an MVP, both share similarities when it comes to the actual development work. From this point on, we will be talking about MVP in general.

Development Principles

In short, you will want to find the shortest possible path to get the product (or a predefined part of the whole product) produced with sufficient quality. The required quality depends greatly on the context. In some cases, it might be as simple as a single static screen, while in others it might mean several integrations implemented between systems.

Let’s assume the case at hand is somewhere in the middle. Based on our experience, the most common rock to stumble on and fall is created by over-analyzing and spending a few engineering years of work into creating too heavy designs before actually diving in and creating something that people can play with. The key point is that MVP reveals almost always things that were not properly thought out before. This might be new challenges, limitations or requirements that were not discovered in the design phase.

Now yes, a pedantic developer could well state that it then means bad design, but you see, people tend to get a better hold of products (or things in general) by seeing and testing them instead of reading the specification. And that’s the whole point of MVP development. Keep things light, streamline development by cutting e.g. heavy testing baselines, and don’t be afraid to cut corners where possible without compromising concept value.

Real-life example: You’re building an MVP to convince your audience how a new User Interface (UI) with a cool statistics dashboard would help them reach their business goals. Usually, the data crunching part of development requires a lot of effort to get right. But since all you’re building at this point is a UI to prove your point, you should not spend any more time on the data that is absolutely necessary. The development team can cut hundreds of hours on implementation by utilizing a temporary, simulated backend and using an out-of-the-box API-solution to access the data. For example, Google Sheets can be used as a simulated backend [1].

The team ™

What kind of team should you hire for the job? This part is perhaps the most crucial piece of the puzzle (well ok, in addition to the project making some sense in the first place). Here are some key handouts based on our experience:

Avoid giants

Considering that the point is to streamline processes and cut corners in suitable places, don’t hire a giant. We’re not saying that giants don’t have their place in the industry. Small teams specializing in MVPs tend to have the advantage of being multi-disciplined and accustomed to wearing multiple hats, which is especially important when the requirements might be loosely defined and you don’t really know what you’re building yet. Also, in small teams, there is usually more project ownership per person, compared to a big team having a very low ownership level. The level of ownership typically correlates with dedication, motivation and general knowledge of the project.

In MVP development, you rarely know all the requirements beforehand. Hiring a tiny team of MacGyvers (with perhaps an expensive-looking hourly rate tag) who can easily switch from coding to cloud environment configuration to UI design to demo video production, will usually be hugely beneficial in terms of cost-efficiency vs. a giant. A team like that can efficiently communicate with the business side and course-correct swiftly as the requirements move, giving you 10x the results with 1/5x the people.

Software Management Frameworks

Use a team that is not too rigorously requesting pedantic use of a specific software development framework (e.g. scrum). While frameworks usually sound nice on paper and provide nice buzzwords for developers’ CVs, they definitely have their downsides. Most of these are related to people starting to be more interested in completing their tasks within their todo-boards than actually reaching the actual goal.

Always ask yourself: What is the ultimate goal? At the end of the day, the MVP audience is not interested in how well your app is backed up by a perfect software process, or how well it’s covered with automatic tests - they are interested in you shipping the thing and seeing some real-world business value.

Instead of spending a lot of man hours making sure that sprint goals are met - make sure that you get your plane off the ground.

Selecting technologies and tools

Avoiding vendor trap is such cliche advice - yet, advice worth taking seriously. Even in this day and age, many organizations purchase projects with technologies locking them to one vendor. This creates an unhealthy situation where the vendor has way more leverage over you than they should.

Partner with a team that is using well-known and well-supported open-source components. This automatically means that the tech has a huge community backing it up, it’s easy to do a third-party review on project quality and you can easily find other people to continue the work if things go sour with your original vendor.

Do easy things, one step at a time

If you think you are re-inventing something, you probably are. You should not. Even if you were thinking of building the next Google, look first for ways to prove the business goals can be met using an MVP. It’s best to use simulated backend services and mocked up (i.e. fake) data instead of developing heavy solutions from the get go.

Sources

• [1] Rapid Prototyping Hacks That Might Save Your Soul, https://docs.google.com/presentation/d/1zq2NUpd2iSQGZ0Sxq18dcFU-JYuF5hKBYQsSxyLyjtk/edit#slide=id.p

3. What comes after the MVP

You might be facing quite different scenarios at this stage. Perhaps you have produced a quick POC to prove your point inside your company and real development is about to kick off. Or, you may have produced an MVP of a mobile application for your own startup or your client, and that application could already be featured in e.g. Appstore (which typically means significantly more fine-tuning than a dead-simple POC). Whatever your situation might be, usually when it comes to either POC or MVP, the base work is done quick & dirty to get things shipped, with sufficient quality as stated in the previous chapter, remember?

This is the stage where the concept should be thoroughly reviewed. Does the MVP prove its point? Does it successfully bridge the gap between expectations (= business needs) and reality? If not, it definitely doesn’t directly indicate that your case isn’t valid - it simply means that it hasn’t been validated yet.

This chapter is not about validating the idea with an MVP, so let’s assume that the validation is already done successfully. Let’s assume you’ve brought on the wow effects with your neat looking & status-quo disrupting MVP and everyone is onboard & ready to continue on to the next stage.

First, you’ll have to consider what to do with the current MVP version of the product when moving towards more mature stages. On one hand, you have invested in it and the product is working, so it would be great if you can continue building on top of the current version. On the other hand, it might be a valid option to continue development by leaving the MVP as it is and starting the implementation of the next version from scratch.

When deciding whether to start again or continue from the existing MVP, you will want to evaluate if the code written for it is something that can even work for a real product. Often MVPs are created following best practises or might be using prototyping frameworks that are not suitable for an actual customer facing product. Thus it might be actually better to take the learnings from the MVP and start with a blank slate.

Real-life example: An emerging eCommerce startup built its first MVP using an out-of-the-box solution (WooCommerce on WordPress to be precise) to quickly get the first version out in the open. This allowed them to validate the core concept with minimal upfront investment. Once the actual integration and customization work began, they decided to switch to a completely tailor-made solution to prevent possible compromises brought about by the constraints of the platform used in MVP. This is not to say that there is anything wrong with out-of-the-box solutions in general but often, modifying them beyond their original purpose gets unwieldy and hard to maintain.

It is not unusual for enterprise software projects to be in what you could call a constant MVP mode. It is a state where new features are demanded to be developed by the business side constantly. And the project is always behind schedule since new features are expected to be live immediately once they have been introduced in the first place. It is common for this to end up in chaos and a lot of bugs.

Next, let’s go over the common pitfalls of MVP projects when it comes to software quality in the traditional sense and talk about some concrete ways you can overcome them.

On the team

While we recommend a small team of experts for the MVP phase, you and they should both know their limits. Very few people can do it all. Have a realistic look into the requirements, and evaluate if you need to expand the team.

Mapping the requirements to the required team size might be difficult, and that’s perfectly ok - it’s not really supposed to be your task anyway. It often is cheaper to get an outside specialist to step in, analyze the resources needed and help compare business proposals from multiple vendors.

If your project is concentrated around specific technologies, consider hiring subject matter experts for those specific technologies in addition to the MacGyvers from the MVP. A good example of such an expert would be a test automation engineer, who has a lot of experience with setting up such systems. Hiring an expert will often save money in the long run and ensure your project follows best practices.

If you are looking for a refresher on what types of engineers are out there, this short article will help you understand the differences between different types of software engineers.

Corporate software, the good bits

From the eyes of a seasoned corporate DevOps pro, the MVP development process looks like total chaos. Things like code coverage (e.g. unit tests) and automated testing they usually take for granted seem like a faraway dream when it comes to a lean MVP development process.

Here’s some food for thought: you should review beforehand whether you are expecting to continue working with the MVP implementation, or whether you expect to start from scratch. If you are looking to trash your MVP once its proven its point, you may want to spend as little time with e.g. automated testing as possible and focus on shipping. But you still should use tools and practices that make the project testable in case you decide to stick with it after all.

A practical approach: While skipping all code coverage and other such thresholds, prepare your application to be both unit testable and end-to-end testable so you are prepared when it is time to climb that fence. Create sanity checks (e.g. check that all software components are defined) on the unit test side, but focus on manual testing for the main functionality. Set up a UI testing framework (e.g. Selenium), but again focus on a few sanity checks (e.g. checking that the UIs main elements are rendering) to make sure your application is rendered. This approach sets a healthy basis for continuing to add more extensive tests when needed.

DevOps is the utilization (or some might call it culture) of best practices in software development, unifying operations and development parts. These best practices are items like deployment pipelines, continuous integration, and versioning guidelines. There is no reason why these cannot be utilized already in MVP development.

Items that need to be addressed post MVP development include integrating enhanced testing baselines to the deployment pipelines. It is also very well possible that the culture will bring more review points when utilized after the MVP project.

Software management process and backlog prioritization

When developing your MVP, you may run into new business/feature ideas that you consider worth developing. You should write all of these down, but keep your eyes on the end goal - getting the first working version shipped.

Once you have a working product out, it’s time to do the backlog prioritization with all the introduced feature ideas. Often, the learnings from the working product allow you to make more informed decisions on the prioritization. With the learnings in hand, you can plan versions, releases and define stage goals. Of course, this prioritization can be done during the MVP project, if it’s possible time-wise.

This should also be the time to review your software management processes. We are not going to take a stand on any specific processes, given what works for one team and one project might not work for another. In many cases, the MVP stage is done wild west style, which can be ok to get things shipped. If you have already utilized a specific process framework during the MVP development, take a step back and think whether you can and should continue to use it.

Performance and scalability

Does it scale? That’s probably the most common question when it comes to applications developed by startups and companies alike (next to how are you going to monetize it?). This is most often raised by the pedantic engineer type of guy in the meeting. We would argue that it’s definitely more common to overthink than underthink scaling in an MVP project.

You definitely should not worry about supporting 10000 simultaneous users when you are looking to validate your idea and get started with your first test users. Having said that, it is also a well-established factor that you can and should be using well-known components with a large community backing it up. By doing this, you are basically getting a guarantee out of the box that someone else has already utilized the technical solution/approach on a real-world case and scale.

Security and reliability

Unfortunately, some stakeholders cannot be bothered about security or proper testing...until it is too late. If you are collecting user data or any other sensitive data in your MVP, you should be already taking security into account.

This is not a guide for security guidelines though, so we’ll simply leave you with this: Small does not mean secure - often the opposite. By that, what we mean is: it is often seen as a common excuse that a small startup should not have to take care of the security since no one would be interested in them. However, once your project is out in the open (e.g. domain, emails, registered users), security must be taken care of appropriately, along with new EU GDPR regulations. So make sure the team understands what this means.

4. What’s Next

Thank you for taking the time to read the Takeoff Guide. We hope we were able to provide you actionable ideas you can put to use in your organization. Perhaps you have realized that application development does not need to be a constant pain in the behind.

If the ideas in this guide sound intriguing to you, but you think you’d need help to put them into action in your organization - feel free to in touch.

We are constantly learning and writing about our latest learnings. So unless you’ve already unsubscribed, you’ll be hearing from us in the form of more actionable advice around application development.

About Wingmen

Wingmen is a Helsinki and Singapore based consultancy helping companies solve game-changing business problems and test new digital business ideas by leveraging premade or custom solutions.

We are a small group of digital MacGyvers who love to solve real-world problems with design and technology. We have a very particular set of skills acquired over extensive careers. Skills that make us business-minded, full-stack makers, who can wear multiple hats to excel in quickly changing environments.

We push each other and our partners to the next level. And together, we are taking small, meaningful steps towards a better digital future.