Deliver Your Xamarin App On-Time and On-Budget PART 1

Recently, I gave a talk at the Xamarin Developer Summit that revolved specifically around ways to reduce delivery risk for a Xamarin cross-platform mobile project. During the course of writing the talk, I realized that I really had too much content for a 45 minute presentation. So, I decided to post it as a series of three blog posts. Enjoy!

So, what’s the problem?

You don’t have to google very long to find surveys like this:

The biggest example is the famous CHAOS Report by the Standish Group. Basically, the folks over at the Standish Group did an extensive leadership survey and then analyzed, categorized and boiled down their findings into ten weighted ‘factors for success’. Each of these represent a category in which leadership should direct resources to improve a software project’s probability of success.​

These are the 2015 report results, which are free online at the time this blog was published. You can purchase the newer reports online. The Standish Report isn’t the end-all-be-all in this space. It fuels its fair share of ‘healthy discussions’ online.​

​I am going to use these factors to weight and group the following series of 25 tips and tricks specifically for delivering Enterprise Xamarin cross platform software projects.​

Part 1: Communication Cadence

Executive Sponsorship 15%
User Involvement 15%
Clear Business Objectives 4%
34% of the problem is here, according to Standish CHAOS Report

Before we can talk about communication, who is on the team? Development teams come in a whole bunch of different sizes. Here is roughly the range in which they come.

Tip #1: Weekly Progress Videos and Screen Caps

The best way to keep communication channels open between the members of the team is to set a cadence – much like the rhythm of a song – or brushing your teeth every night. Set up some good communication habits and it becomes much easier to keep it going. The Agile Manifesto has a similar strategy with ceremonies.

Make progress videos as you are writing/testing your code. Record and store them as you go. Make a habit of making a quick video when merge you branch or make a big commit.​

Don’t worry if the videos aren’t perfect – these videos are intended to show progress, open communication channels and get everyone on the same page.​

Use Vysor or Reflector, or other screen casting software. Use a separate channel in Slack, Teams, Discord (or whatever your dev team uses to communicate) to post your progress videos. This builds a project diary and avoids lost emails. Additionally, team members have the ability to chime in with inline comments and play the videos over and over again, if they need to. This practice allows stakeholders a bit of time to think, ponder and give great feedback. It starts a conversation, where are conversation is needed.​ C-level executives are busy and so are you!​

Picture this – you are walking down a hallway, on your way to a meeting. A co-worker, tangential to your project stops you to ask how the project is going. Now you don’t have to launch into a summary of what is going on – just invite them to check out your ‘Progress Video Channel’. ​

How to get the cadence rolling and engage a stakeholder that is too busy for their own good?​

• Explain this process and set this expectations when the project starts​
• Set a personal recurring reminder to post videos every Friday morning ​
• Set a personal recurring reminder to check for responses every Wednesday – basically giving a time limit for comment and/or acknowledgment​
• If Stakeholders have not commented on last Friday’s videos by Wednesday of the following week, schedule a meeting! Once they figure out they can avoid another meeting by reviewing your work… they may choose to engage on their own time!​

This is THE BEST WAY I have ever found to communicate effectively with busy C-level stakeholders. Give it a try!

Tip #2: Do NOT Write Any Code Without a Mock-up

Whatever the project situation is, from verbal-only requirements to extremely detailed written requirements, a low-fidelity mock-up or wire-frame speaks a thousand words. ​Most importantly, it helps avoid dreaded requirements surprises.

Developers often get push-back if they try to formally document missing requirements, but especially in the absence of good requirements, Low Fidelity Mock-ups get the job of documenting what needs to be written very quickly, and rarely attracts “you’re wasting time” push-back.​

Low Fidelity Mock-ups helps team members understand that the mock-up is NOT A SCREEN CAPTURE.​

The hand drawn-ish look help team members understand that the design is flexible, not set in stone.​

In contrast, High Fidelity mock-ups are typically what a graphic designer would build. Try to reserve High Fidelity Mock-up Software – MockPlus, Fluid UI, Moqups, JustinMind, etc. for designers – it can get really tedious.​

Use a software like Balsamiq (great web and desktop tools) or if your project is really small, start out with whiteboard drawings that you can keep in a shared space to capture edits.

Tip #3: Make and Use a MUST KNOW List

Even if you have fairly detailed written requirements, make a MUST KNOW LIST of high level items that could potentially impact your architectural decisions. Make a point to ASK EACH ONE with stakeholders and, if necessary, describe in detail what you mean. Do this before any code is written.​

You would be surprised what can be learned about requirements when stakeholders are specifically asked these types of questions.​

This is my list, please feel free to use it or make your own.​

• Android, iOS and UWP
• Persistent Storage – online/offline mode​
• Globalization & Localization​
• Authentication & Authorization​
• Should any device permissions block the user from using the app?  Location, camera, push, etc. ​
• Analytics and Crash Reporting​
• API Versioning & API Authentication​
• Distribution – iTunes/Google Play or Enterprise​
• Any accessibility concerns?​
• Any company specific best practices?​
• Any specific color, branding or other UI considerations?​
• Any unique requirements? HIPAA? Other security concerns?​

Tip #4: Early UAT

When I set expectations for early UAT with stakeholders – I tend to explain it this way:​

via GIPHY

“Let’s think about the early UAT app as if we were setting out place-settings on a dinner table. We are going to get the UI and all of the user interactions ‘just right’ with static, mocked-up sample data – think of this as the plates, cups, silverware, etc.

Then, I am going to rip the tablecloth out from underneath and replace it with data from the server. The plates and cups and silverware are all going to stay in the same places, but the underlying data source is going to be replaced with the middle-ware and back end API endpoints and Database.”​

​Use a QA device with sample data only. No exposure to APIs. Keep it as low risk as possible. ​

Early UAT gets stakeholders involved. It helps them more intimately get to know the project. They feel more like they are in the ‘inside’. Having the device with them allows them more opportunities to share with other executives in-between meetings.  They give better feedback. Word travels about your project. Interest and excitement build around your project.​

By providing this to stakeholders EARLY in a project, it gives THE BUSINESS time to think about it and it gives US developers more time to react to changes. We should EXPECT changes, not dread them. And I think we would all agree: if you have to change the plan, it is easier to change early in a project than late in the game.

This practice dramatically reduces surprises. and provides a solid starting point for conversations between stakeholders and the development team.​

First step to delivering an Early UAT version of the app to stakeholders, you need to invest time in building out sample data. ​

You are going to need it for unit tests, anyway, so build it in such a way that you can use it for both.​

Analogous to the sample data we used to build in the olden-days, when dinosaurs ruled the earth, for WPF apps Win 8.1, vanilla non-Xamarin UWP, for the Visual Studio Designer or Blend.​ Now that Xamarin.Forms XAML supports design time data – you can use sample data for this purpose as well!

	public static class DemoSession
	{
		public static int SampleSessionId0000 = 1851998887;
		public static int SampleSessionId0100 = 1372120977;

		public static Session SampleSession00
		{
			get
			{
				return new Session()
				{
					SessionId = SampleSessionId0000,
					Title = "SampleTitle",
					ShortTitle = "SampleShortTitle",
					Description = "SampleDescription",
					RoomId = DemoRoom.SampleRoomId0000,
					StartTime = DateTime.Now,
					EndTime = DateTime.Now,
					DataVersion = 0,
					CreatedUtcDate = DateTime.Now,
					CreatedBy = "SampleCreatedBy",
					ModifiedUtcDate = DateTime.Now,
					ModifiedBy = "SampleModifiedBy",
					IsDeleted = false,
				};
			}
		}
   }

If you use any sort of code generation, this is a great candidate for a template. Mainly because this is a ‘one-and-done’ opportunity for code generation. You typically don’t re-gen sample data. ​

I usually use static classes with static ids separated out, so that I can reference them from other objects if I need to.​

I didn’t bring my helmet and so I am going to try not to get tomatoes thrown in my general direction. So, in an effort not to bring different XF architectures and frameworks into the mix… I am going to start with a basic, brand new Xamarin.Forms app in VS 2019, the shell template gives you an IDataStore interface with two implementations – AzureDataStore and MockDataStore.

This contains CRUD (Create – Read – Update – Delete) methods for the models. This example doesn’t have a persistent data layer. It just loads API or mock data into memory and serves it up.​

The next step to delivering an Early UAT version of the app to stakeholders, you need to use dependency injection to swap Sample Data with live data from your API. ​

If we break out the process of loading of the data from the process of serving the data to the UI, we can use dependency injection to swap out the loading implementation (tablecloth), without disturbing any of the dishes (UI). ​ In this next iteration, I added a SQLiteDataStore for persistent storage.

You can also load the UI directly from the MockDataStore. This is useful if you have time sensitive or security sensitive data that is never stored in persistent storage.​

This pattern is super powerful. It enables us, as developers, to provide a UI that is basically functional to stakeholders without investing time and energy building out a backend database, API layers, nor the middle-ware data sync layers. It honestly really just becomes the dishes on the table.​

The template architecture uses the DependencyService in the App.xaml.cs to toggle between the Mock data and the API. ​ If we break it up a little more, as we would if we were building an Enterprise solution from this starting point, it would look something like this… with the toggle between the sample data and the API data is better placed in a Startup.cs. Please see a working example of this here at the Xamarin Dev Summit GitHub Repo.

Here is the service layer when the process of uploading data is broken out as well. ​ Using the default DI container in .Net Core, you can see that the services are registered as singletons.   Namespace: Microsoft.Extensions.DependencyInjection

For more info on this DI pattern, check out this MS Build Conference Video by James Montemagno and Glenn Condron. Specifically right around the 16:30 minute mark: https://mybuild.techcommunity.microsoft.com/sessions/77337

​The end result looks something like this. Video shows first swapping from Sample Data to API data and back again. ​ I programmatically log the sample user out, log them back in, drop all of the SQLite tables and then rebuild and populate them, using the user’s auth token. ​

Don’t miss Part 2 and Part 3 of this really long blog post!