Retrospective Experience – Self-Assessment plus Circles and Soup

After recapping the previous sprint retrospective actions, where I’m pleased to say we made a handful of small improvements, I introduced the team to the notion of team self-assessments. We all agreed it was worthwhile, so completed SAFe ScrumXP Self-Assessment which despite some disagreements took about 15 minutes.

I won’t share the result, but it’s nice to have a baseline and have clear indication of places we need to improve. We will definitely be repeating this exercise in the future.

We then proceeded through the 5 stages of a retrospective.

Stage 1 – Set the Stage

I noticed in the previous retrospective – see Retrospective Experience – ESVP, Sailboat and Constellation – that there were a lot of negative comments about things we really didn’t have control of. I was therefore worried that this was going to be another negative retrospective and although it risks going against the advice:

“It is extremely important not to use a retrospective to identify purely negative parts of a project”

I thought I’d give a broad context of “anything goes”! I had some positive points up my sleeve, so I decided the risk of focusing on the negative was worth it.

Stage 2- Gather Data

The team split into pairs (with one group of 3) for 15 minutes to discuss the various topics they would like to raise.

Stage 3 – Generate Insights

As I was expecting a lot of negative comments, I decided I’d use a technique I’d recently read about called Circles and Soup. This categorizes all the points raised into the following groups:

  • The team have direct control over so can take direct action
  • The team have influence, so their action would be a persuasive, influencing or recommending action
  • The team may have no control or influence, but they can choose actions for how to respond collectively when they find themselves swimming in the soup​

I was hoping the team would then be able to get some closure on the things out of our control and subsequently put less thought into.

Stage 4 – Decide What to Do

After the groups presented their points to the rest of the team, we then used Dot Voting to pick out the points the team thought were worth further discussion. We then took the top 5 most voted for things and brainstormed some solutions that we could try. It’ll be my job over the coming sprint to make this happen.

Stage 5 – Close

I thanked the team.

Personal Retrospective

The team didn’t produce anywhere near the number of negative comments I thought they would so I’m not convinced Circles and Soup was the best technique to use. It was definitely worth trying, but I think it would be nice to apply this technique once you knew there were a lot of negative things being mentioned, rather than doing it regardless.

What went well?

  • Individually the Self-Assessment and the Circles and Soups worked well.
  • We identified a few team worries about external factors that we can think about and prepare for.

What could I have done better?

  • I should’ve researched and explained Circles and Soup better. I thought it was a self-explanatory technique, but after introducing it to the team, it was clear that it wasn’t. As I couldn’t explain it simply also shows I didn’t fully understand it! I should stop assuming these things are simple and/or the whole team are as keen as me!
  • I distanced myself from the team discussion, so had no idea of the issues being raised. If I was more involved, even if it was just observing more closely, I could’ve swapped out Circles and Soup for something else.

What should I not do again?

  • Although I’ve been acting as ScrumMaster to the team for 18 months, using these types of techniques is new to me. As such, I don’t have the confidence to swap out techniques on the fly. That should come with time though, so I’m not beating myself up about it. Time will tell.
  • Another sign of my inexperience is that I’m too keen to try out all the new techniques I’ve heard of! I’m not convinced doing both a Self-Assessment and a “normal” retrospective is right. I’ll need to read more into this.

Verify WordPress Backups Using Azure

I suffered some minor data loss today which I managed to restore from backup, but not before a few minutes of “why can’t I restore”. It reminded me of the classic quote:

“Backups always succeed. It’s restores that fail.”

I then realised that although this site is backed up via the excellent UpdraftPlus Backup / Restore / Clone plugin for WordPress I’d never tested the backup.

So, I did some digging and it seems the general advice is to see if you can open the zip file the backup process produces. Now call me a skeptic, but that makes me a little uncomfortable. Restoring on top of this site (shudder) or restoring to a sub-domain was also unappealing and then I remembered Azure.

I’m lucky enough to have a MSDN subscription which gets me some free Azure time, but there always seems to be free trials out there. Once I was logged into the management portal the process was very simple. Click New -> Compute -> Web Site -> From Gallery -> WordPress and fill out the following two dialogs:

Azure Create Website 1

I didn’t bother filling out the “Deployment Settings” section as I would be deleting the site as soon as I was done.

Azure Create Website 2

Once Azure has done it’s thing, go to the websites dashboard and find the URL which will be something like “”. Go there and WordPress will lead you through the installation steps of setting up an admin account. Once that’s finished, all that remains is to install your backup plugin of choice, upload your backup file and hit restore.

If all is well, after a little while (depending on how big your site is) you should see your blog, but hosted in azure at “”. All your links will redirect to your original domain, so be careful which site you’re on, but you can verify that everything has come back correctly.

Scrum Retrospective Experience – ESVP, Sailboat and Constellation

I recently conducted my first Sprint Retrospective since becoming a Certified ScrumMaster and although I think it went ok, I’m sure there’s room for improvement. I’m hoping that by writing about it I perform a more in-depth personal reflection than I normally would and if someone else finds it useful or can provide feedback, I’ll be very happy.

Brief Background

This is an established team that has great morale, but they’ve been through the ringer a bit. I was worried the enthusiasm for Agile was fading, or worse, we were just going through the motions.

Five Stage Retrospective

When I first joined, I asked twitter about the various retrospective techniques others liked and Ben Linders kindly responded. So when I saw the book he’d written on the very subject – – was cheap I bought it!

Unsurprisingly, I followed the 5 stage retrospective mentioned in that book and used the techniques within.

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide what to do
  5. Close the retrospective

Stage 1 – Set the stage.

The aim/context of this Retrospective was two-fold:

  1. Understand the teams opinion of our sprint retrospectives
  2. Discover the biggest issue/worry that we currently have

We used ESVP Check-In to discover the first, which resulted in 4 E, 2 S, 2 SP, 1 ESV and 1 P. I’m reading that as I was partially correct in my fear that the team were beginning to lose faith in retrospectives, but it wasn’t as bad as I thought.

Stage 2 – Gather data.

To gather data from the team, I used the Sailboat Retrospective technique. I’m pleased to say it resulted in a lot of post-it notes, so the team were clearly engaged, but I’m worried/disappointed about the number of negative things that were noted.

Stage 3 – Generate insights.

The team talked through each post-it on the sailboat, discussing in-depth the reason for it being there. I used this time to try and see how strongly the team felt about the issue, if they all agreed and how big an issue it was.

Stage 4 – Decide what to do.

There were too many post-it notes to tackle at once, so I used the Constellation technique on a few I hand-picked and a few I asked the team to select as most important.

Not only did this get everyone back on their feet and engaged (there was a definite increase in discussion afterwards) but is a really clear indicator of the teams feeling.

We then took each one from most important to least important and came up with some actions to hopefully resolve the issues before the next retrospective in 2 weeks.

Stage 5 – Close the retrospective.

Nothing special to note beyond thanking the team for the patience and enthusiasm for a new approach. I also asked for feedback, which I’m hoping will come willingly over the next couple of days.

Personal Retrospective

In summary, I’m really happy with the retrospective. I certainly gained some insight and I think the team got something out of it.

What went well?

ESVP, Sailboat and Constellation proved very nice techniques.

What could I have done better?

I’m slightly worried I led the Generate Insights stage too much. I think the team lost interest a little and some of the momentum was lost.

What should I not do again?

In preparation for the retrospective I ran out of time to think about stage 4 onwards. I think that led to the loss of momentum.

Just Write Something

I’ve just renewed the hosting and domain for this place and in two years I’ve written 14 posts… including this one!

Clearly I’m not an active blogger, but during some reflection I’ve come to the conclusion that I’ve been putting off a lot stuff. What’s worse, when I do sit down I seem to get very little done as I’m over-thinking.

Turning Point?

Like anything nowadays, I turned to my friend google (other search engines are available) and came across this post from Scott Hanselman Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE which rung very true.

From the number of comments, I’m clearly not the only person and there seems to be various ways people (try to) overcome it. I particularly liked the Chistopher Svec’s comment of “I usually have these 2 xkcd comics close at hand to help remind me to Just Do It / YAGNI” referring to &

And if by coincidence, the first post on Christopher’s blog (at the time of writing has a title of:

“Doing nothing is cheap. Failure is cheaper.”

Sums it up nicely. Off to think about coding :)

70-486 – Useful Web API Tutorials

While studying for 70-486 I’ve found a couple of useful resources for studying Web API. Before listing each one, it’s worth pointing out that this is before the March 2014 refresh of the exams.

If you have little programming experience, I recommend you follow them in this order as they get more complicated as the list goes on. If however, you’re already comfortable with MVC and Entity Framework you can probably skip to the penultimate or even last option.

Microsoft Virtual Academy

The whole 70-486 Jump Start is definitely worth investing your time in. Obviously there’s no actual tutorial with this, but it’s a great starting point.

Build RESTful API’s with ASP.NET Web API

This is a nice and quick introduction to Web API that will not only get you up and running with Web API, but also a simple client to consume the service. Importantly, the code on the site works as is and is easy to follow.


  • Very easy to follow
  • Introduces Service Layer/Repository pattern
  • Shows how to capture JSON in IE! (I admit never knew this)
  • You build a simple client
  • Brief debugging in Visual Studio
  • Publish the example to Azure (I didn’t try this)


  • Download a 100+MB file for code snippets (which you don’t technically need)

Using Web API with Entity Framework

Although this is a 7 part tutorial of Web API with EF it’s not 7 times larger! It has the added bonus of introducing another part of the exam, Entity Framework, but nothing beyond the very basics. Again, you construct a client to consume the service, but this time with a little more detail.


  • Uses EF, so if you’re not familiar with that you get exposure and if you are, it’s a slightly more “realistic” tutorial
  • More involved Client UI
  • Uses Knockout.js (the MVC template I used has 2.2.0 installed so pay attention to version numbers)
  • Authentication, albeit the installed MVC template forms authentication (blink and you’ll miss the credentials)


  • 3 technologies (Web API, Knockout.js and Entity Framework) covered so a lot to pick up
  • starts slow, but gets quick quite rapidly, e.g. part 7 (hint: you can login as “Administrator” on the homepage)

Detailed Tutorial for Building ASP.Net Web API RESTful Service

As the name suggests, this is a more detailed tutorial of Web API than the other resources and although it’s well done, I wouldn’t recommend you start off with this one if you’re a beginner.


  • Covers Entity Framework, Dependency Injection and the Repository pattern so more “real-life”
  • Versioning
  • Full source code on Github


  • May have been me, but I think some bits have been missed as I had to refer to the code a couple of times to get things going
  • Doesn’t explain using Fiddler (and why should it, so make sure you’re happy with either Fiddler or some equivalent like F12)
  • Isn’t finished so no caching.


If you want a quick overview of Web API in preparation for 70-486, the above 4 resources should get you well on your way. I haven’t taken the exam yet, so who knows if it was worth the effort, but for those familiar with WCF, Web API appears to be very nice.

Installed Markdown

I’ve taken the advice of Scott Hanselman and Rob Conery in their Get Involved! Pluralsight course and have installed Markdown (or perhaps more accurately the Markdown on Save Improved plugin). I haven’t even begun to get to grips with the syntax, but I can certainly see how much easier it’s going to become to write posts.

Speaking of which, I’ve realized why I’m finding it harder and harder to write. (Excuse the over use of Markdown)

“I’m basically doing very very little SharePoint at the moment!”

In my 9-5 job (which is more like 8-5 + work from home) I’m acting as a Product Owner and in those rare moments where I do get some “me time” I’m revising for 70-486.

The Get Involved! course warns about using names that pigeon hole you into something, so I’ve dropped the SharePoint from the blog name.

New Focus – 70-486 Developing ASP.NET MVC 4 Web Applications

A couple of posts back I said I was focusing on 70-487 Azure, but it turns out the exam reference isn’t available yet and the learning curve would be quite steep. More importantly, it wasn’t part of the SharePoint 2013 MCSD Certification like 70-486 MVC4 is. Therefore, the new plan is:

  1. Pass 70-486
  2. Pass 70-488
  3. Pass 70-489 (SharePoint 2013 MCSD complete)
  4. Pass 70-487 (MCSD: Web Applications complete)

Work is pretty hectic at the moment, so I’m not putting in as much study as I need, but I’m hoping to get a Pluralsight licence soon.

Automated SharePoint 2013 Dev Farm on Azure

After successfully creating an Active Directory VM in Azure last time and bragging about it to a tame ITPro, they pointed out that I probably have better things to spend my time doing!

Obviously he’s right (or scared that I’m going to take his crown as the only SharePoint ITPro in town) so I followed his recommendation and used these Automated Deployment of SharePoint 2013 with Windows Azure PowerShell scripts from GitHub.

I don’t know if I failed to follow the “Configuring your environment” section correctly, but it failed the first time I tried. Unfortunately the VM I was running in locked up over night, so I don’t have the full error message, but it definitely contained “The WinRM client cannot process the request” as that’s all in my browser history. I tracked that down to a section where it connects to the DC and attempts to assign an attached disk a driver letter and format it using remote PowerShell.

I eventually got it working by:

  1. Clearing out everything from the Azure management portal
  2. Running the script again, but cancelling it immediately after it fails to make the remote PowerShell connection
  3. Delete the DC in the Azure management portal but leave the Cloud Service and Storage account the scripts created in 2.
  4. Re-running the script, but this time specifying -ServiceName and -StorageAccountName created in 2.

There were a few errors in the script, but they were all at the start and along the lines of “X already exists”. I don’t know how long it takes as I left it to run over night, but I can now RDP into the SharePoint box, browse central admin and the visit publishing site the scripts create.

Build a SP2013 dev box on Azure

To say this place has been neglected would be an understatement. I’m going to do 4 things to rectify that:

  1. Broaden the scope from just SharePoint to anything IT related*
  2. Start studying for some new exams – currently Developing Windows Azure and Web Services
  3. Use it like a journal
  4. Read up on WordPress so I know what I’m doing

So to kick things off, I’m killing two birds with one stone by trying to build a SharePoint 2013 Development/Test lab in the cloud on Azures.

So far I’ve managed to complete exercise 3, which is basically creating an active directory box in “spouse-mode” – my new favorite saying that I saw over on Bjørn Furuknap’s blog SharePoint – You’re Doing it Wrong! - which isn’t complex, but hey, you have to start somewhere!

* think but including some Agile/Scrum posts

Saving to a SharePoint List Cross-Domain

What I thought would be pretty easy, turned out to be quite a difficult. I naively thought you could save some user input from http://portal/sites/test to http://my/sites/sp_admin. Turns out, that because this is basically attempting to save data cross-domain, for security reasons this is locked down. I figured it out in the end, but went through a fair bit of trial and error first:

Attempt 1 – Client Object Model
Failure 1 – You simply cannot create a ClientContext cross-domain.

Attempt 2 – JSONP
Failure 2 – I *think* this would actually work as there’s a good blog post about creating A weather forecast WebPart using JSONP. But this was for a secure website, so executing javascript unquestioned seemed like a bad idea.

Attempt 3 – Web Services, e.g.
Failure 3 – Again doesn’t work cross-domain. From the documentation at

Additional Notes: Due to browser security restrictions, most “Ajax” requests are subject to the same origin policy; the request can not successfully retrieve data from a different domain, subdomain, or protocol. Script and JSONP requests are not subject to the same origin policy restrictions.

Attempt 4 – Server Object Model in a Web Part
Problem 4 – The Application Pool of http://portal doesn’t have write access to http://my. I quizzed a friendly IT Pro and he assured it’s by design and again for security reasons!

Attempt 5 – Sandbox Solution
Success! By hosting a Sandbox Proxy on the destination domain and using a sandbox webpart on the source domain, you can pass data cross-domain. I won’t expand on how to write sandbox solutions as that’s very well documented elsewhere.