Think Big: How Design Plus Data Will Change Your Business

Is design thinking catching your attention? It should. Data insights not available before now can transform your business models and allow you to lead in your industry when you incorporate elements such as predictive, mobile dashboards and machine learning. This wave of change is forcing data architects to re-think and re-design how programs and applications must be built. To truly innovate, design teams need to push the design thinking envelope on almost every project.

“You can have data without information, but you cannot have information without data.”
– Daniel Keys Moran, computer programmer and science fiction writer.

Since the invention of the first computer, the world has been on a digital light-speed journey – one that has seen massive change in how we interact with our world and with each other. Today, there are more than 2.5 billion[i] smart phones carried in people’s pockets – each more powerful than the ones used to run the spacecraft that landed the first men on the Moon.[ii] In particular, how we interact with and gain insight from data has gone through an incredible transformation. We have evolved from relying on simple historical reporting – from the days of simple reporting to now, where tanker.

The Way It Was

Reporting has always been a critical element for a business to thrive and we have been accustomed to seeing our reports – our data – in fairly standard and historic terms. Let’s take a straightforward quarterly sales report at a consumer retail company, for example. Simple data, like units sold, prices received, cost of goods, volume of shipments and so forth, would be gathered and stored over a three-month period and then used to generate a few charts and graphs. Conclusions would be drawn from this static data and the company would shift strategy based on the conclusions.

Perhaps the conclusions were accurate and maybe they weren’t. Regardless, that’s how it’s been done for a long time: based on the data available.

The Way It Is

Today, the capability exists to break down data into far greater detail, do it in real-time and through disciplines like machine learning and artificial intelligence, draw highly focused and accurate conclusions not at the end of a business quarter but at the end of each day, and, in many cases, as it happens.

IoT Changes Shipping Industry – Reduces Risk and Cost

A client that operates a fleet of tankers equipped with IoT sensors wanted to move beyond its basic data reports and drill deeper into the technical data gathered aboard its vessels. Optimus utilized elements from Microsoft’s IoT Suite, including Azure Data Factory, to create visually appealing reports and dashboards that contained information gathered from thousands of sensors throughout the fleet.

The results meant a far more in-depth data analysis than the company had been getting, delivering more accurate insight for more accurate business decisions. When it comes to tankers, a simple mistake can cost millions in terms of lost time, environmental disasters, financial penalties, missed deadlines and more.

Optimus solved the client’s existing problem while building a platform for continuous improvement with data analysis using Microsoft Azure tools. Because the data can be aggregated in the cloud, the client can analyze greater amounts of data over an extended period of time, thus further enhancing their shipboard operational analysis and implementing global cost saving efforts as a result.

Now, a business can make highly informed decisions immediately and adjust accordingly. Of course, it’s not simply analyzing a few traditional data points, like sales; it’s analyzing where those sales took place, in which store locations, even in which aisles or departments, at what time of day, from which shelf the customer chose a purchase, what the customer’s likely income level is– in other words, the more highly specialized the data, the more highly specialized and precise the conclusions that can be drawn.

Because it’s possible to generate highly detailed data and analyze it from so many different perspectives, every sector of the economy is making use of data analysis.

In the manufacturing sector, factory operations are being revolutionized[iii] by both big data and analytics. Sensors generate endless streams of data on the health of production line equipment, data that’s being examined by the minute for the slightest indication of a potential problem or defect. Conclusions are drawn and actions implemented immediately to avoid any breakdown and disruption in the production process. There’s a positive ripple effect to this: customers don’t experience delays and the company doesn’t experience a loss of revenue.

The virtually unlimited storage capacity in the cloud, coupled to highly sophisticated computer algorithms that can perform serious analysis in, literally, seconds, is placing tremendous demands on data architects. Programs and applications must be agile enough to allow for updates, added features and improvements without delay. This has meant developing new architecture that can not only run a program at lightning speed but can be altered or updated in the areas where it needs improvement, much like making incremental improvements to a car model but without re-designing the whole car every time.

Gone are the days of a monolithic software structure where data warehouses needed a year or more to be designed and several more months for data to be inputted. If missing data was discovered, it would mean an entire rebuilding of the program.

Microservices and Teams

Today, Optimus Information designs architecture so that updates, changes or improvements can be made to one area of a program or application without having to open up the whole program. By using microservices in our software development, Optimus has created functional teams whose responsibility is to just one area of a program. A team focuses only on its specific area and generates improvements without impacting other teams or resulting in an overhaul of an entire software product. Tremendous amounts of time are saved for our clients and the cost of updates or re-designs is driven down dramatically.

Optimus applies the same method to data gathering. By means of advanced tooling, our clients can store raw data, without pre-aggregating it, run a query on that raw data and have the answers they need in a matter of seconds. Previously, it would take weeks to get a result because the data would have to be assessed and compartmentalized as it was gathered and placed into structured environments before a query could be run. This is what we call modern data warehousing. The focus is on agility and speed.

Down the Road from Microsoft by Design

Optimus specializes in working with IT departments of companies that don’t or can’t spend the time and money to develop the cloud-based software architecture needed today. Optimus uses a suite of leading edge services, on the Microsoft Azure platform, that allow us to select exactly the right components to solve a client’s problem. We are physically located close to Microsoft’s Vancouver and Redmond development centres

Optimus is a Microsoft Gold Partner and, in that role, we work very closely with Microsoft on new product previews and trials that are in development, giving feedback that improves our customer’s end product. Optimus employees have often already kicked the tires on new Azure features before they are released. This keeps us at the forefront of rapidly changing technology but let’s us give feedback as enhancements are designed.

If you want to enhance and sharpen the results of your data analysis, we invite you to contact us. We are happy to explore some “what-if” scenarios with you to help propel your data insights – and your business – forward exponentially. Reach out and schedule a virtual coffee anytime.

iOS App Deployment Options

Clients often ask ‘how can I deploy my app internally so just our staff sees it?’ Or ‘how can we sell our app to other companies without listing on the App Store?’ This article explains the different iOS app deployment options and pros/cons of each.

There are basically three ways to deploy your application. Either it goes into the public App Store where everyone can see it, a B2B deployment, or an Enterprise deployment where it is only available to your internal staff.

Option 1: Public App Store

The App Store is the huge marketplace for apps that we’ve all grown familiar with. As of this writing, there are over 1 million apps in the App Store. This is where we download all the major publicly available apps from Salesforce to Angry Birds. Every iOS user has access to the App Store and has their credit card setup with their iTunes account.

Pros

  1. Exposure to largest user base
  2. Opportunity to be ‘Featured’ or in the top rankings

Cons

  1. Competing against 1 million+ other apps
  2. Goes through Apple’s approval process prior to each release
  3. Can only filter user groups by OS version and country

Option 2: B2B Deployment

B2B deployment is where you can sell your app directly to businesses by registering their Apple IDs or providing them with redemption codes. B2B apps cannot be listed in the App Store (and vice versa) so it’s one or the other. There are opportunities to make different versions with different functionality, but B2B apps go through the same approval process as regular App Store apps.

Apps distributed via B2B have the same pricing model as the public App Store meaning they can be priced anywhere from free to $999.99. They are also created using the same Apple Developer account that is used for App Store deployment.

Pros

  1. Easy distribution directly to specific users via Apple’s Volume Purchasing Plans for Business or Education
  2. Ability to heavily customize the app for specific organizations beyond what would be suitable in the public App Store

Cons

  1. Goes through Apple’s approval process prior to each release
  2. Restricted to using public APIs and functionality

Option 3: Enterprise Deployment

If you’re looking to launch an app that is explicitly for your employees then Enterprise Deployment is ideal. This allows you to create a completely custom app that doesn’t have to go through Apple’s approval process. This means you don’t have to worry about their policies and can push the limits of your app beyond what is suitable for the public app store.

Pros

  1. Doesn’t go through Apple’s approval process meaning there are no delays and you aren’t limited to typical policies
  2. Can distribute the app internally without first registering devices
  3. Utilize advanced enterprise features for enhanced encryption, VPN, and MDM integration

Cons

  1. No exposure to users outside of your organization
  2. Requires an Apple Enterprise Developer account to publish apps internally

(image credit: florianplag)

Scoping out a Minimum Viable Product (MVP)

Scoping-a-Minimum-Viable-Product-1 Scoping out a Minimum Viable Product (MVP)

Scoping a Minimum Viable Product

Whether you’re a startup or a member of a large organization, when exploring mobile solutions your imagination will quickly get away from you and the project size will slowly balloon to a point where it’s no longer feasible. This is where you have to focus on scoping out your minimum viable product (MVP).

An MVP (sometimes referred to as minimum valuable product) is the least amount of work you have to do in order to demonstrate value to your users. Whether your users are internal to your organization or consumers, your MVP has to be worth their time to install, get familiar with, and become part of their regular routine. In addition, it has to be within a reasonable budget in order to justify the upfront and ongoing development costs.

Scoping out an MVP is a process of generating ideas and refining the initial scope. Through series of brainstorming sessions you flush out ALL of the potential features of the solution. Write down every crazy idea that comes to mind and keep a long list of items that would make this solution great. Once you have a big list of all the key features and ideas, then start to pare down the feature set and complexity until you are left with a concise version 1.0 that solves a particular need. Don’t worry about this long wish list of features, once you have users they’ll help you prioritize.

It’s critical to pare down the features in version 1.0 so that you can reach a launch date without the project ballooning out of control. By identifying the feature set that will prove whether the app is useful or not, you will reduce the noise and complexity during the development process. It’ll keep timelines short with clear deliverables. It’ll reduce risk by ensuring that scope is clearly understood and reasonably sized that it can be delivered in a shorter time frame.

Not paring down the project scope will leave you with a longer term plan that is exponentially more prone to budget and timeline risks. The more features you try to cram in, the more likely something will go sideways. The motto is essentially, get it in the hands of end-users as-soon-as-possible.

In our experience, we’ve seen more projects fall into the category of feature creep (or feature bloat) and almost none fall into the category of being so pared down it’s not valuable. If an idea has merit and it solves a particular need, the smaller the better (at least to start).

A good example of an MVP: Instagram

  • Minimalist feature set
  • Perfected the small set of features it launched with
  • Didn’t build out a web version until it was needed
  • Focused on a single platform until it had a good level of adoption
  • Upon proven adoption, scale the supported platforms

How to trim the scope of Your project

Here are 5 tips to trim the scope of your project and create a simple MVP

  1. Narrow down the target users. Focus on a specific user group that has a specific problem. Solve the problem for one user group at a time.
  2. Remove features that aren’t CRITICAL for version 1. If it’s even slightly optional, plan it for version 1.1+
  3. Target a single platform – even if you’re developing a multi/cross platform solution. Nail it on one platform, then migrate.
  4. Keep the user interface and interactions relatively simplified. By under investing in fancy animations early on it’ll make it easier to quickly change workflows and functionality.
  5. Pick a go-live date, then work backwards. If your go-live date is 30 days from now, then you can’t build features that will take 2 months. Work backwards from a go-live date (preferably one with business implications).

(img source: yandle on Flickr)

3 Mistakes to Avoid in Mobile App Development

3-Mistakes-to-Avoid-in-Mobile-App-Development 3 Mistakes to Avoid in Mobile App Development

Since mobile app development is constantly evolving at a rapid speed, mobile application developers are constantly learning and growing their skills and products, never quite ahead of the curve in this fast-paced sector of software development. The release of smartphones with new features is surging ahead at breakneck speed, providing a multitude of challenges for the forward-thinking mobile app developer.

Here are the 3 mistakes to avoid in mobile app development:

1. Incomplete Market Research

Knowing your market is an important step in the mobile app development process, not only to determine whether or not your proposed project has an audience, but also to know exactly how to fulfill that audience’s requirement. You should know what you hope to achieve and how your audience will use your app.

You should also be aware of other similar products on the market and how yours will differ. If you are planning a similar product to an app that already exists, you should know exactly how your mobile app would improve upon the existing product. You may even be able to use the existing app as a template for your success – or as an example on avoiding failure.

Knowing the marketplace is extremely important – particularly in the planning stage. You should know, not only your audience, but also the audience for the platform to which you plan on marketing. Making a cross-platform mobile app provides more than one singular audience and must be researched as such.

2. Ignoring End Users

You’ve got a great idea for a mobile app, you’ve done your market research to determine the need for the project, and you’re on your way to building what you think is the greatest thing since Angry Birds. But you didn’t continue your market research into feedback from end users.

It is an absolutely essential part of the development and design process to reach outside your team to engage with potential end users. You want to ensure that every aspect of your mobile app translates well to using it in the real world.

Make sure your testing process involves obtaining feedback from end users so that you can make any changes to the app to ensure its success upon release.

3. Misplaced Focus on Graphics & Features

Every developer wants to create a beautiful app – a mobile app that will put all others to shame with its effective design and varied features, prompting the user to treat the app with the reverence displayed by a typical Apple devotee. This graphics and featured focused attitude can easily overtake the development process. By adding too many graphics or animations, your mobile app can result in slow loading times or a poor user experience.

Remember, graphics should enhance functionality – not the other way around. Too many features can have the same effect, creating an overly complicated application that decreases its popularity by its complex environment. By creating a simple journey for your end-users, you will gain more traction than through adding useless bells and whistles.

Avoid these three primary mobile app development pitfalls by remembering to plan and research your market, test within your audience, and keep your design clean and focused, and you’ll start ahead of the curve!

How to Outsource Mobile Application Development

Looking to outsource the development of your next mobile app or website? Here are a few tips from the trenches.

Tip #1: Choose a Vendor with Proven Experience

When choosing a vendor, be sure to select someone that has been-there, done-that. At least make sure they have successfully launched some apps on your chosen platform – then go test those apps, read their reviews, and preferably talk to their client references. Bonus points if they have worked in your particular industry or on your particular problem before.

Tip #2: Ensure Open Dialogue, Frequent Checkpoints, and Live Demos

Anytime you’re sending work outside of your office, there is a communication gap. If someone is sitting a few tables over, it’s easy to walk over and get a quick verbal status update; however, if someone is working remotely, be sure to set regularly scheduled huddles to make sure things are on track. I emphasize on regularly scheduled because this is key. Set a conference call/screen sharing session for at least once per week to touch base and see the latest version of the app.

There are two key benefits to doing this. First of all it establishes a good rhythm where both parties know when they’ll have their next opportunity to share notes and receive feedback. This reduces the number of short emails back and forth. Issues can be consolidated into a single list for discussion.

The second major benefit is that you, the client/product owner, gets to see the app while it’s being built. This will greatly increase the number of issues spotted early on which will save massive headaches down the road. By investing this time to take a quick look at the app you’ll spot all sorts of little quirks that you hadn’t previously thought about. Don’t allow shortcuts here where updates are simply verbal – if you can’t see the feature, you can’t assume it’s done.

Tip #3: Use the Same Tools

Project teams use a lot of tools when planning, designing, developing, testing, and supporting – be sure to use the same tools. If you’re outsourced team is going to use some handy tool for bug tracking, get access to it. Same for project management. Be sure you’re looking at the same dashboards in the same systems. This will save energy by ensuring that everyone has the latest copy of the available information and that little is lost in translation.

Tip #4: Conduct Code Reviews

Conducting code reviews is particularly important early on to ensure that your quality standards are being met. If you don’t have internal resources to conduct a code review, hire a third party to spend a few hours going over the code. Make sure that it’s of high quality, well designed, and properly commented. This upfront investment will both validate that you’re working with a good partner and it’ll set the bar so they understand the quality you’re looking for.

Bonus points: ensure they’re using a technology stack that will work for your long-term vision.

Tip #5: Plan for User Acceptance Testing

User acceptance testing is where you get the app and get to test that it’s working as designed. This is your opportunity to go through all the scenarios and make sure the app is perfect. The two keys to successful UAT is that it’s done thoroughly and promptly. Be sure to schedule time in the project for this. Make sure your internal team is available to properly conduct UAT, that you have a good process for reporting issues, and that you’ve accounted for time in the project for both your UAT and the outsourcing partner to resolve the issues.

Pro tip: during UAT, avoid scope creep and change requests. Focus on getting the current project complete before adding new features.

Tip #6: Remove Roadblocks & External Factors

When working with a third party, it’s easy to lose hours, days, and weeks because of external factors. For example, if the developers need some updated design assets, or have queries, or are relying on another party for API details. These types of delays will limit the efficiency of the team and ultimately slow down the project – plus, if you’re working with a hardline partner, they may use these as excuses to delay the project. The best advice here is to prepare everything in advance of outsourcing. Some changes will inevitably come up, but try to scope the project in a way that enables the external team to execute the project end-to-end without the opportunity to cite an external factor as a delay.

Tip #7: Clarify Scope of Deliverables

What exactly are you going to get at the end of the project? Some partners will deliver just the source code. Some will give source code and design assets. Some will just give the application itself and not the source code. Depending on your commercial arrangements, I would suggest requesting the following (at least!):

  1. Source Code (preferably in the form of a code repository that includes the change-log and versions along the way)
  2. User Stories
  3. Design Assets (their original copies, not just the final versions. Chances are a few months after launch you’ll want to make some minor changes).
  4. Test Cases & Results
  5. Technical Architecture

As I explain in more detail in another blog post, there is value in documentation.

Tip #8: Clearly Identify Acceptance Criteria

Acceptance criteria is essentially an agreed upon criteria that will be met in order to consider the project complete. It could be as simple as “all user stories are complete as designed and test cases serve as validation.” Making this acceptance criteria clear makes it easier for both parties to understand how the project will finish. This will avoid cost and time overruns caused by time & materials projects running longer than expected. Focus on clearly defined acceptance criteria so the project can finish and you can move onto the next phase.

Tip #9: Choose What to Outsource

Outsource wisely by choosing projects or components of the project that aren’t worth your time or you don’t have the in-house resources. The best things to outsource are clearly defined, well-scoped, and easy to confirm. Outsource items that have a clear start, finish, and deliverables. If you outsource loose requirements or general R&D without fixed time and price upper caps, you’ll end up with a slow trickle that doesn’t result in successful deliverables. Bonus points if you can outsource something that you’ve done before and have a clear process for. It’s much better if you know the scope of what you’re trying to outsource and your goal is to free up your resources. Outsourcing new projects works, but is more challenging in terms of coordination and you can expect it’ll take longer to stabilize.

At Optimus we help clients outsource mobile application development by providing end-to-end services from project management to design, development, testing, and support. Connect with us if you’d like to learn more about how to make your next mobile project a success.

The post How to Outsource Mobile Application Development appeared first on OptimusMobility.

How to Outsource Mobile Application Development

Looking to outsource the development of your next mobile app or website? Here are a few tips from the trenches.

Tip #1: Choose a Vendor with Proven Experience

When choosing a vendor, be sure to select someone that has been-there, done-that. At least make sure they have successfully launched some apps on your chosen platform – then go test those apps, read their reviews, and preferably talk to their client references. Bonus points if they have worked in your particular industry or on your particular problem before.

Tip #2: Ensure Open Dialogue, Frequent Checkpoints, and Live Demos

Anytime you’re sending work outside of your office, there is a communication gap. If someone is sitting a few tables over, it’s easy to walk over and get a quick verbal status update; however, if someone is working remotely, be sure to set regularly scheduled huddles to make sure things are on track. I emphasize on regularly scheduled because this is key. Set a conference call/screen sharing session for at least once per week to touch base and see the latest version of the app.

There are two key benefits to doing this. First of all it establishes a good rhythm where both parties know when they’ll have their next opportunity to share notes and receive feedback. This reduces the number of short emails back and forth. Issues can be consolidated into a single list for discussion.

The second major benefit is that you, the client/product owner, gets to see the app while it’s being built. This will greatly increase the number of issues spotted early on which will save massive headaches down the road. By investing this time to take a quick look at the app you’ll spot all sorts of little quirks that you hadn’t previously thought about. Don’t allow shortcuts here where updates are simply verbal – if you can’t see the feature, you can’t assume it’s done.

Tip #3: Use the Same Tools

Project teams use a lot of tools when planning, designing, developing, testing, and supporting – be sure to use the same tools. If you’re outsourced team is going to use some handy tool for bug tracking, get access to it. Same for project management. Be sure you’re looking at the same dashboards in the same systems. This will save energy by ensuring that everyone has the latest copy of the available information and that little is lost in translation.

Tip #4: Conduct Code Reviews

Conducting code reviews is particularly important early on to ensure that your quality standards are being met. If you don’t have internal resources to conduct a code review, hire a third party to spend a few hours going over the code. Make sure that it’s of high quality, well designed, and properly commented. This upfront investment will both validate that you’re working with a good partner and it’ll set the bar so they understand the quality you’re looking for.

Bonus points: ensure they’re using a technology stack that will work for your long-term vision.

Tip #5: Plan for User Acceptance Testing

User acceptance testing is where you get the app and get to test that it’s working as designed. This is your opportunity to go through all the scenarios and make sure the app is perfect. The two keys to successful UAT is that it’s done thoroughly and promptly. Be sure to schedule time in the project for this. Make sure your internal team is available to properly conduct UAT, that you have a good process for reporting issues, and that you’ve accounted for time in the project for both your UAT and the outsourcing partner to resolve the issues.

Pro tip: during UAT, avoid scope creep and change requests. Focus on getting the current project complete before adding new features.

Tip #6: Remove Roadblocks & External Factors

When working with a third party, it’s easy to lose hours, days, and weeks because of external factors. For example, if the developers need some updated design assets, or have queries, or are relying on another party for API details. These types of delays will limit the efficiency of the team and ultimately slow down the project – plus, if you’re working with a hardline partner, they may use these as excuses to delay the project. The best advice here is to prepare everything in advance of outsourcing. Some changes will inevitably come up, but try to scope the project in a way that enables the external team to execute the project end-to-end without the opportunity to cite an external factor as a delay.

Tip #7: Clarify Scope of Deliverables

What exactly are you going to get at the end of the project? Some partners will deliver just the source code. Some will give source code and design assets. Some will just give the application itself and not the source code. Depending on your commercial arrangements, I would suggest requesting the following (at least!):

  1. Source Code (preferably in the form of a code repository that includes the change-log and versions along the way)
  2. User Stories
  3. Design Assets (their original copies, not just the final versions. Chances are a few months after launch you’ll want to make some minor changes).
  4. Test Cases & Results
  5. Technical Architecture

As I explain in more detail in another blog post, there is value in documentation.

Tip #8: Clearly Identify Acceptance Criteria

Acceptance criteria is essentially an agreed upon criteria that will be met in order to consider the project complete. It could be as simple as “all user stories are complete as designed and test cases serve as validation.” Making this acceptance criteria clear makes it easier for both parties to understand how the project will finish. This will avoid cost and time overruns caused by time & materials projects running longer than expected. Focus on clearly defined acceptance criteria so the project can finish and you can move onto the next phase.

Tip #9: Choose What to Outsource

Outsource wisely by choosing projects or components of the project that aren’t worth your time or you don’t have the in-house resources. The best things to outsource are clearly defined, well-scoped, and easy to confirm. Outsource items that have a clear start, finish, and deliverables. If you outsource loose requirements or general R&D without fixed time and price upper caps, you’ll end up with a slow trickle that doesn’t result in successful deliverables. Bonus points if you can outsource something that you’ve done before and have a clear process for. It’s much better if you know the scope of what you’re trying to outsource and your goal is to free up your resources. Outsourcing new projects works, but is more challenging in terms of coordination and you can expect it’ll take longer to stabilize.

At Optimus we help clients outsource mobile application development by providing end-to-end services from project management to design, development, testing, and support. Connect with us if you’d like to learn more about how to make your next mobile project a success.

How to Stay Agile when Outsourcing Mobile App Development

Outsourcing mobile app development and the agile software methodology don’t naturally fit together – in the below post I’ll outline how to make it work to reduce risk on both sides and give the project the best chance of success.

Key Challenges when Outsourcing Mobile App Development

The core disconnect between agile and outsourcing is the relationship between the cost and scope of deliverables. When outsourcing a project, you want to know upfront how much it’s going to cost and exactly what you’ll receive; however, in order to reach that decision the outsourcing partner needs to go very deep into requirements.

A typical waterfall based team would analyze all of the requirements upfront, do the development, then testing, then deployment. A typical agile team is conducting requirements gathering, development, and testing concurrently throughout the project.

In an agile project, scope is very dynamic and priorities can change frequently. Agile is by definition flexible and quick to adapt. Project scope and timelines are determined more by the available resources and their ability to deliver value. The requirements are very loosely gathered in the beginning and clarified as the item is moved from the product backlog into a sprint. The challenge with this approach is that the size of the item may move from a Small=>Medium=>Large depending on how complex the requirements become during clarification. If the arrangement between you and the outsourced team is too rigid, these changes will result in change requests that will require estimation, review, and approval.

How to Work in an Agile Way with an Outsourced Team

Fundamentally there are two ways to outsource a project. Both ways work with agile teams, but a fixed price project will require more upfront analysis and more accurate project sizing.

1: Fixed Price

In a fixed price project the scope is defined upfront along with timelines and estimated hours. In this model the scope needs to be crystal clear and even then there are risks on both sides that either the scope wasn’t properly defined or the effort not adequately sized.

With a fixed price project, you should expect a Discovery Phase in which requirements are gathered and the scope clarified. This phase would typically result in complete User Stories, Wireframes, Technical Design, Project Plan, and often a proof-of-concept to mitigate any perceived risks.

Once the estimation and project plan is complete, then the methodology can switch to more of an agile delivery model where items are broken into sprint-wise plans with regular delivery review, and sign-off. This approach will increase the visibility into the project and reduce the number of surprises at the end.

2: Time & Materials (T&M)

In a time & materials project the scope can be changed on the fly. This model enables maximum flexibility as the outsourced vendor is simply billing for time. The onus is on you to ensure that scope and goals are efficiently planned. In this model no Discovery Phase is needed and you can dive right into the project.

A typical approach to setting up a T&M project is to assign an upper cap of monthly hours and build a resource pool to fill those needs. A team may consist of business analysts, designers, developers, architects, and a project manager and/or product owner. Some vendors will bill each of these resources separately or bundle them into a single hourly rate.

An important metric in a T&M project is how much value is being delivered per hour. This is important to measure so that key stakeholders/decision makers can see that the delivery team (from business analysts to developers to testers) are working efficiently and consistently delivering quality results.

Managing the Product Backlog

When working with an agile team, it’s all about the product backlog. The backlog is a list of items, ideas, features, and defects that have been captured at some point along the way. Any ideas that come up at any stage, should be captured in the backlog. Whether it’s a good idea in the long-term or immediate term, it should get captured in the backlog so it can be prioritized accordingly. Some backlog items will be very high-level and potentially very large; however, other items will be very small.

When sizing an idea in the backlog, it should be a very very high-level estimate (t-shirt sizes work well – XS, S, M, L, XL, XXL). These estimates will be reviewed during sprint planning.

Sprint Planning

When working in an agile methodology, you should break the project into 1-4 week sprints. In our experience, 2 week sprints are typically most suitable for mobile projects. Grouping tasks into two week sprints gives enough time to put dedicated efforts into planning, development, and review. A shorter sprint than this can cause a lot of overhead compared to the amount of development work that gets completed.

Sprint planning consists of the following activities:

  1. Prioritizing items in the backlog: look at the list of items and decide which ones should be considered for development in the next few sprints. This will be based upon the high-level estimate and the value the item brings to the product.
  2. Sizing items: once the items are moved from the long-term backlog into a list of items that should be considered in the short-medium term, the items need to be sized more accurately. This is where t-shirt sizes get moved into the team’s standard units.
  3. Creating the sprint plan: now that the items have been sized more granularly, the product owner along with the development team decide what items get moved into the upcoming sprint. This is determined by value per unit of effort.

Sprint Closure

At the end of a sprint it is critical that the product owner and team review the deliverables from the sprint promptly. This is one of the pain areas when outsourcing because often it becomes an out-of-sight, out-of-mind sort of situation. If it is not clearly agreed upon that sprint reviews will happen immediately after a sprint and items are either signed-off or rejected, you’ll end up with a very large amount of items that get carried from sprint to sprint because they are never being adequately reviewed, revised, and closed. If you fall into this trap, you’ll end up with a large end-to-end testing sprint at the end of the phase.

The lesson here is that whether you are in-sourcing or outsourcing, the teams have to be cohesive and have a good rhythm to their workflow. If you’re aiming for a rapid release cycle, an agile methodology is an excellent approach. The efficiency will be determined by the team and their ability to work together as a seamless unit.

The post How to Stay Agile when Outsourcing Mobile App Development appeared first on OptimusMobility.

How to Stay Agile when Outsourcing Mobile App Development

Outsourcing mobile app development and the agile software methodology don’t naturally fit together – in the below post I’ll outline how to make it work to reduce risk on both sides and give the project the best chance of success.

Key Challenges when Outsourcing Mobile App Development

The core disconnect between agile and outsourcing is the relationship between the cost and scope of deliverables. When outsourcing a project, you want to know upfront how much it’s going to cost and exactly what you’ll receive; however, in order to reach that decision the outsourcing partner needs to go very deep into requirements.

A typical waterfall based team would analyze all of the requirements upfront, do the development, then testing, then deployment. A typical agile team is conducting requirements gathering, development, and testing concurrently throughout the project.

In an agile project, scope is very dynamic and priorities can change frequently. Agile is by definition flexible and quick to adapt. Project scope and timelines are determined more by the available resources and their ability to deliver value. The requirements are very loosely gathered in the beginning and clarified as the item is moved from the product backlog into a sprint. The challenge with this approach is that the size of the item may move from a Small=>Medium=>Large depending on how complex the requirements become during clarification. If the arrangement between you and the outsourced team is too rigid, these changes will result in change requests that will require estimation, review, and approval.

How to Work in an Agile Way with an Outsourced Team

Fundamentally there are two ways to outsource a project. Both ways work with agile teams, but a fixed price project will require more upfront analysis and more accurate project sizing.

1: Fixed Price

In a fixed price project the scope is defined upfront along with timelines and estimated hours. In this model the scope needs to be crystal clear and even then there are risks on both sides that either the scope wasn’t properly defined or the effort not adequately sized.

With a fixed price project, you should expect a Discovery Phase in which requirements are gathered and the scope clarified. This phase would typically result in complete User Stories, Wireframes, Technical Design, Project Plan, and often a proof-of-concept to mitigate any perceived risks.

Once the estimation and project plan is complete, then the methodology can switch to more of an agile delivery model where items are broken into sprint-wise plans with regular delivery review, and sign-off. This approach will increase the visibility into the project and reduce the number of surprises at the end.

2: Time & Materials (T&M)

In a time & materials project the scope can be changed on the fly. This model enables maximum flexibility as the outsourced vendor is simply billing for time. The onus is on you to ensure that scope and goals are efficiently planned. In this model no Discovery Phase is needed and you can dive right into the project.

A typical approach to setting up a T&M project is to assign an upper cap of monthly hours and build a resource pool to fill those needs. A team may consist of business analysts, designers, developers, architects, and a project manager and/or product owner. Some vendors will bill each of these resources separately or bundle them into a single hourly rate.

An important metric in a T&M project is how much value is being delivered per hour. This is important to measure so that key stakeholders/decision makers can see that the delivery team (from business analysts to developers to testers) are working efficiently and consistently delivering quality results.

Managing the Product Backlog

When working with an agile team, it’s all about the product backlog. The backlog is a list of items, ideas, features, and defects that have been captured at some point along the way. Any ideas that come up at any stage, should be captured in the backlog. Whether it’s a good idea in the long-term or immediate term, it should get captured in the backlog so it can be prioritized accordingly. Some backlog items will be very high-level and potentially very large; however, other items will be very small.

When sizing an idea in the backlog, it should be a very very high-level estimate (t-shirt sizes work well – XS, S, M, L, XL, XXL). These estimates will be reviewed during sprint planning.

Sprint Planning

When working in an agile methodology, you should break the project into 1-4 week sprints. In our experience, 2 week sprints are typically most suitable for mobile projects. Grouping tasks into two week sprints gives enough time to put dedicated efforts into planning, development, and review. A shorter sprint than this can cause a lot of overhead compared to the amount of development work that gets completed.

Sprint planning consists of the following activities:

  1. Prioritizing items in the backlog: look at the list of items and decide which ones should be considered for development in the next few sprints. This will be based upon the high-level estimate and the value the item brings to the product.
  2. Sizing items: once the items are moved from the long-term backlog into a list of items that should be considered in the short-medium term, the items need to be sized more accurately. This is where t-shirt sizes get moved into the team’s standard units.
  3. Creating the sprint plan: now that the items have been sized more granularly, the product owner along with the development team decide what items get moved into the upcoming sprint. This is determined by value per unit of effort.

Sprint Closure

At the end of a sprint it is critical that the product owner and team review the deliverables from the sprint promptly. This is one of the pain areas when outsourcing because often it becomes an out-of-sight, out-of-mind sort of situation. If it is not clearly agreed upon that sprint reviews will happen immediately after a sprint and items are either signed-off or rejected, you’ll end up with a very large amount of items that get carried from sprint to sprint because they are never being adequately reviewed, revised, and closed. If you fall into this trap, you’ll end up with a large end-to-end testing sprint at the end of the phase.

The lesson here is that whether you are in-sourcing or outsourcing, the teams have to be cohesive and have a good rhythm to their workflow. If you’re aiming for a rapid release cycle, an agile methodology is an excellent approach. The efficiency will be determined by the team and their ability to work together as a seamless unit.

User Acceptance Testing

For the past weeks, I have been writing a lot about the tools we use here at Optimus in order to create great mobile applications. Continuing with this trend it is time to check how we perform acceptance testing.

Acceptance testing is a type of testing that happens once all of the code for a given sprint has been finished and this code has passed through our testers, these are the last two steps before we signoff on the build. Here at Optimus happens this type of testing happens in two stages:

  • First the internal product owner (normally a business analyst) performs the testing as if he were the customer. The product owner performs the search in two ways: he first goes over the acceptance criteria that were agreed upon and then a free test is performed where the owner just uses the application as if he were a normal user.
  • After the product owner accepts the build then it is passed on to the customer to perform user acceptance testing and the close the sprint.

Performing this type of testing can be tricky, mainly because it takes quite a bit of time and effort to deploy the builds to different devices in different platforms.
Here at Optimus, because of differences between the platforms (iOS, Android and Windows Phone) we have a different process for each.

  • iOS: For iOS apps we use a great SaaS for application testing through the cloud: TestFlight. This application allows us to send the build to different devices in many parts of the world. We can see how they look in iPads, iPhone 4, iPhone 5, iPod Touches and other iOS devices very easily. All we do is download the TestFlight app in these devices, sign these devices up with TestFlight and, once a build is ready, directly download it from the Testflight app to our device. TetsFlight is great because we can deploy the application to as many devices as we want.
  • Android: For Android what we do is to directly download the .APK file to the phone, this automatically installs the application in our device, but this has to be done manually for each device.
  • Windows: For Windows it is the biggest hassle; there are several steps that need to be taken. First of all you have to have Windows developer tools in your machine as well as have Zune software. You also have to register your device before you can download the application to the device.

As you can see three are very different and for sure the easiest one is iOS through TestFlight.

We look forward to make this acceptance testing process more streamlined with the announced addition of Android and Windows support by TestFlight. This will allow us to spend less time setting tests up and devote more time to testing.

If you have any questions about user acceptance testing or any other aspect of mobile app development, please don’t hesitate to contact us and take advantage of our one hour free consultation.

Showcasing User Interfaces with inVision and AirServer

Showcasing the completed prototype of the user interface is an important step in the development process. It gives you a chance to be absolutely sure that we are building an app that conforms to your vision and a chance to spot major oversights before writing a single line of code.

In an earlier post, I wrote how we use Balsamiq in order to give a taste of what the user experience of the app will be like. When it is time to finalize the UI ahead of development, we use another great tool that allows you to experience how the app will work. The tool is called inVision.

Showcasing the UI of an application is most easily done by showing images through a computer monitor. Although this can work decently, images displayed through computer monitors can be tricky to interpret especially when it comes to the size of elements. The larger scale on the computer monitor can make something look okay when in fact it is too small when displayed in the mobile application.

To solve this problem, we use inVision which gives you an interactive prototype of what the application will look like. This lets you interact with the UI using a physical device without having to create a single line of code.

The inVision app is extremely useful when showcasing the UI to a single stakeholder, but what happens when you are in a conference room and have 20 stakeholders and you don’t have 20 physical devices?

AirServer to the rescue.

AirServer allows us to mirror the inVision prototype on our iPhones to a Mac where we can then share the prototype to a room full of stakeholders through a projector or through conference calling screen share capabilities.

The usage of these two tools gives our UI/UX services a more interactive way of showcasing what we do.

Here at OptimusMobility we work with you to make your mobile vision a reality. Contact us if you have any questions and take advantage of our free one-hour consultation.