The Infrastructure-First Fallacy

Early in the development of Upkeepr, we had a “lead developer” with a very command-and-control style that created some friction with the rest of our agile team.  This first conflict we had was around developing the core elements of the web application architecture.  For the first couple of sprints, this lead insisted on working on “application infrastructure” while the other devs built out some critical components like OAuth login and refresh tokens.

While the others demonstrated their work product at the end of each sprint, the lead dev failed to create even a demonstrable prototype, let alone a skeleton that the others could hang their work on. 

Now I know, as most experienced agilists do, the importance of creating a working product increment with every sprint.  So, I pushed the team to just deliver something.  It took several sprints of me talking with the lead and other Devs individually about the value of delivering a working increment and my dissatisfaction as a product owner (as entrepreneur, I was playing multiple roles) that we worked through to the point of having a basic working architecture.  But not too surprisingly, the application infrastructure built en-mass, and not delivered and tested incrementally, was riddled with technical problems and shortcomings – most of which had to be reworked for many future sprints. 

In the PSM II class we talked about the importance of team agreements, including the Definition of Done, which can evolve over time. The team needs to start with the fundamental Scrum values of transparency, inspection, and adaptation.  Creating a done product increment every sprint enables these.  Starting with Scrum fundamental values and principles to build team agreements is a much healthier and more effective way to address a friction point like lead developer hero behavior than I took just trying to coach them through “the right way to Scrum” without those fundamentals. 

If I could do it over again, I would take this approach:

  1. Start by sharing with the team the product vision AND the Scrum values and principles.  Ensure the whole team has buy-in before starting the first sprint.
  2. Work with the team to create an attainable sprint goal.
  3. Coach the team to create a rudimentary Definition of Done (DoD) that just has working code to meets the PBI acceptance criteria committed/merged to the main branch, compiling and running. 
  4. Push to create a working increment from the very first sprint and analyze the situation deeply if we fail to deliver value towards the Sprint goal.
  5. Defer creating more sophisticated DoD criteria like automated tests, CI and CD builds until later sprints.  Make the first couple of sprints about delivering something that works, preferably integrating everyone’s work product.
  6. Encourage the whole Dev team to evolve the application infrastructure towards a vision rather than building it up-front.

The goal in these early sprints should not be to build out as much of the product and DevOps infrastructure as possible, but to get the team working together and start a rhythm of delivering a working increment.  It’s counter to my entrepreneur’s urge to realize the product vision as quickly as possible. But, taking it slowly at first will avoid much dysfunction and frustration with all parties.

Return to Blogging

For the last couple of years, I’ve been running a startup to develop an app (Upkeepr) and learning many lessons along the way, which I’ve been thinking about sharing here. Also, I’ve immersed myself in Agile theory again by:

  • Taking the Professional Scrum Master PSM I and PSM II courses taught by Improving
  • Studying for the PSM assessments (and passing)
  • Reading
  • Applying to be a Professional Scrum Trainer (PST) and reflecting on my love of teaching

The two big books that have me thinking deeply at the moment are:

As has always been the case in my blogging, my intended audience is both the public at large who may be interested in my musings on Agility, product development, or technology, and my future self, when I’ve forgotten the clarity of thought I had at some moment or want to continue a train of thought with the next step. Plus, writing often forces me to frame my thoughts and structure ideas into something consumable by others. So maybe this will make me a better Agilist, leader, and entrepreneur along the way.

So, here goes!

Azure Store Table Connection Refused

I’m trying to separate out my Azure environments for local development vs. Dev, Test, Staging, and Production.

For local development I’m using the Azure SDK local storage emulator.  To do that you have some connection strings that look like this:

  <add key="StorageConnectionString" value="UseDevelopmentStorage=true"/> 
  <add name="AzureWebJobsDashboard" connectionString="UseDevelopmentStorage=true" />
  <add name="AzureWebJobsStorage" connectionString="UseDevelopmentStorage=true" />

But today I ran into a non-obvious error:

No connection could be made because the target machine actively refused it

And found this cool post with the solution in the comment.  Basically, the storage emulator turns off after some period of disuse.  There’s a handy little batch script in there to clear out the storage and restart it.


I keep running into this issue about once a month.  I build and deploy my app to my Android device, and at the end of deployment I get the ambiguous error:


This thread in the Xamarin forums gives a variety of different solutions, but I wanted to document it for myself and others in a nice clear list of things to try, in the order of easy-to-do first:

  1. Uninstall whatever version of your app is on the device and try to deploy again.
  2. Install the app store version of your app, uninstall it, and try to deploy again.
  3. In the system Settings/Device/Applications/App Manager on the All tab, find the


    Select it, uninstall it, and then try to deploy again.

This third one is sure-fire way, so you might start with that and skip the trial and error.

Remote Debugging in Azure

I have an app service (API, actually) published in Azure.  Lately I’ve run into some strange problems where the service apparently just crashes with no exception handling.  I have logging all over the place, and it just stops in its tracks when the code makes a specific service call, with no evidence of what’s going on.  All of my unit testing and automated integration tests work fine.  So, I’m breaking down and learning remote debugging of a Microsoft Azure process.

The obvious place to start is the Azure tutorial, here:

I followed the instructions, but had to make a few adjustments.

  • Remote debugging reportedly blocks the rest of the website, so you definitely don’t want to do it in production.
  • I use deployment slots, and have on called “dev” just for the purpose of development testing (and now remote debugging).
  • You have to enable remote debugging in the deployment slot, not the main website.
  • When you attach to the process, you have to use the right userid in the form of <website_uid>__<slotname>.  That’s with two underscores.  E.g. “MySitePublishingId__dev”.  I found this specific ID in the publishing profile that you can download for each site and slot.

Through all of this, I’ve come to the conclusion that the thread is probably not crashing, but rather hanging due to async call returns (deadlock).  But however I work that out will be another post.

.NET Configuration Transformations

I’m playing around with XML transformations today and needed a refresher.  This is a pretty good explanation straight from the horse’s mouth.

I’m deploying to an Azure website, in which case there are ways to keep connection strings and app settings unique to each slot of your website.

However, the setting I need to tweak for production isn’t an “app setting”, but rather a servicemodel client endpoint, which apparently has to be done the hard way. 🙁

Mac Power User

Found this tool today to help tweak the notoriously hard to customize Mac OS.

“Access Denied” exception in self hosted Owin application

HTTP Tests not running on my virtual machine.  Access denied was returned from the Owin Serverfactory. The answer is to run this from the admin CMD console (not PowerShell).

netsh http> add urlacl url=http://locahost:<port#>/ user=Everyone

Source: “Access Denied” exception in self hosted Owin application

Xamarin iOS Certificate Issues

Several times now I’ve encountered issues where Xamarin doesn’t let me deploy an app under development to an iOS device.  In some cases, I’ve found the answer here, but I’m going to lay out the full solution for all cases.

  1. Register your unique device ID (UDID) at Apple Developer Device List.  You won’t have to start here every time.  In fact, if you’ve been developing/deploying to your device for a while and Xamarin suddenly stops deploying to the device, this is not the problem. But if you’ve never used the device for development before, this is where you have to start. You can search for instructions on getting your UDID, but it seems the easiest way is to connect your device and view it in iTunes.
  2. Xcode Certificates.pngRun Xcode and refresh your certificates.  Often times, an Xcode update will require user intervention to accept the Terms of Use, etc. or enter a password to complete installation of the update.  That may be all you have to do.  But if your certificate has expired or you’ve updated the device list in step 1, you’ll have to download the cert again. In Xcode v7 (it has changed over time and probably will again) choose the menu options: Xcode > Preferences > Accounts > [Team Name] > View Details > Download All.  
  3. In Xamarin Studio v5, go to the context menu for your iOS project and select: Options > iOS Bundle Signing. You may have to twiddle with the Signing Identity and the Provisioning Profile.  In my case, they were both set to Automatic after a XS update, but to get it to work I had to change the Provisioning Profile to iOS Team Provisioning Profile.  iOS Bundle Signing

Time to Start Blogging Again

passing-time-2-51854c91a8333I know blogs are passé and no one really follows/reads them anymore.  However, I’ve been doing a lot of development in Xamarin lately and running into new (to me) problems every day, so I’m going to document them here and help the SEO world to find the answers again in the future.

And, I’ll try to remember to throw in some stuff about the books I’ve been reading and other interests now and then.