Software development improvements from a recent sprint retrospective I participated in.

Wheel-of-FiveIn my current contract the use of agile processes is relatively new to the organisation as a whole and certainly to our team. This means we are still refining our processes, so things like sprint retrospective meetings were we meet at the end of a sprint and try and figure out what things went wrong and hence we should do less of, what things went right and hence we should do more of, what we can do better etc. are very important.

We had one of these sprint retrospective meetings recently and it was one of the better ones I’ve been involved in any previous role or project. I thought it would be nice to share some of the suggestions which came out of it, as I’m sure you have had similar suggestions particularly when agile was relatively new in your environment. Suggested process changes from our retrospective are below:

Split the daily scrum into multiple ones based around project teams. The team as a whole is 8-10 .net developers, format to date was one big stand up corresponding to multiple projects, meaning we all had to listen to other people talking about projects not related to us. For next sprint we are going to do separate scrums for each project (although we are going to keep the one retrospective for shared learning purposes), which should save us time.

Move the daily scrum to morning time, we had been previously doing it in the afternoon, nothing particularly went wrong or anything, just most of us are used to doing it in the morning from previous roles. Also having them early allow us to work on removing any identified blockers that day, whereas with scrums closer to the end of the day, issues are more likely to be forgotten about as people are starting to head off home shortly after the scrums. I suppose too that morning scrums align better with the three questions which are most commonly suggested for daily scrums, what did I do yesterday, what will I do today? and any blockers? A question about the best times for the standup on Quora has lots of different viewpoints. We are going to try morning scrums for a sprint or two at least anyhow and then review at another sprint retrospective.

Actually stand up in the daily scrums to encourage quick and to the point scrums. CurrentlyAAEAAQAAAAAAAAPqAAAAJDc5Y2YyM2VjLTllM2QtNDY1Yi04NDUyLTFhZDJmOTA2MWQ5Nw some of us seem to stand, some of us sit. I guess sitting during the scrum could possibly kind of maybe make it seem like a break. For the next sprint sitting will be frowned upon and be punishable by having documentation related tasks assigned to the culprits.

Stick to high level task related conversation in daily scrum, what I did (5)Daily scrum meeting 3 questionsyesterday, what I will do today, anything in my way? Really technical things should be ‘taken offline’. Everyone is going to be mindful of this during the next sprint, hopefully it will save us a small amount of time anyhow.

Finish one vertical slice/use case set of the application completely
before starting on new pages, unless a very good reason not to. At the moment we appear to be doing a few tasks from one page, then another few from a different page. At the end of the sprint when at the client demo we then need to say to the client you can test this page, but not this particular feature etc. Next sprint we are aiming to very selectively breakup parts of a particular piece of functionality that different team members can work on without stepping on each others toes (the system is not huge) so essentially we are going to try and go down (finish a section completely) rather than across (adding new pages).

Quick peer review of proposed steps to implement before someone begins on a new type of task/page. Although the team is very collaborative, there has been occasion were a developer (myself included) has gone off on a tangent and implemented something that was completely not needed or in a manner that was superfluous or more complex than it needed to be or just down right wrong. This quite often resulted in a lot of lost time due to rework. To minimise the chances of this we agreed for the next sprint that for any task that is new to the application(s) and hasn’t been done before will we get the person assigned the task to briefly outline the problem space and in four or five bullet points how they propose to implement the feature or page. After that the rest of the team will peer review and hopefully if something obvious is being missed as a collective we will be able to spot it.

tumblr_inline_nog5m4UVp61ry6czh_400Deploy to dev and uat via Visual Studio publish tool with web.config transforms so no manual manipulation needed. We were kind of half doing this but the deployment process is very easy to get wrong so for all future sprints we are going to lock this down fully as its quicker and more reliable.

Apply TFS label to the source code at the end of sprint so we can know what we presented to the clients, what version we fixed bugs in, introduced bugs in, easily restore, more easily prepare changelog files by comparing labels for sequential sprints etc.

Overall I think the team found the sprint retrospective very valuable, we are certainly looking forward to seeing if the process changes above have a positive effect on the burndown chart. Please share some of the suggestions that have come out of your sprint retrospectives too, particularly the ones that made a big difference for the subsequent sprints. Also note that I am actively building my LinkedIn network so if you’re an IT professional and interested please connect with me on LinkedIn. 

WordPress preview post not working… quick workaround

WordPress preview post links not working? Sick of unsuccessfully trying different things you’ve found on Google like I was? Pretty much every article I read offered a different solution. Some suggested it was related to a bad theme update, others that is was related to caching, others still pointed the finger at mod rewrite/isapi rewrite rules. Eventually I gave up and just went with a preview post workaround.

WordPress preview post not working workaround

Wordpress preview post not working workaroundWell a quick workaround for you might be to just go ahead and publish the post but set its visibility to privatePrivate content is only visible when you are logged in so can be used to preview posts before publishing to everyone. Note however other editors and administrators will be able to see this content too when they are logged in, but that may be fine for your case. You can set a post to private from the right hand side of the add/edit post page as shown above.

FYI: this is what the post looked like on the site before I made it public


Config files specified in SQL Agent being overridden by design time package configuration

In work, our DEV and our UAT DB environments reside on the same box, but with their own SQL instances. We prefer to store SSIS packages on disk as they are a little (actually a lot) easier to manage that way. Since our DBs are on the same box we could, when configuring SSIS packages just copy the packages to two separate file locations for DEV and UAT and alter the design time package configuration to point to DEV.dtsconfig for one and UAT.dtsconfig for the other.

Rather than this however we attempted to just have the SSIS package in one location and override the default .dtsconfig file which was defined at design time by passing in the the environment specific .dtsconfig as part of the two (DEV & UAT) SQL agent jobs set-up to execute the package on schedule.  This can be done from the configurations tab in the job properties.



We expected the package to take its settings from UAT.dtsConfig as that was what was defined in the job but as we found this was not the case. This is because as of SQL 2008 SSIS packages load configurations in the following order:

  1. The utility first applies the design-time configurations.
  2. The utility then applies the run-time options that you specified on the command line when you started the utility.
  3. Finally, the utility reloads and reapplies the design-time configurations.

which meant the .dtsConfig specified in design time configuration was used. According to Behaviour Changes to Integration Services Features in SQL Server 2008 R2 on the MSDN site one can use /set to change design time settings but not the location of settings.

To get the .dtsConfig specified in the job to be the effective one, we needed to disable package configurations in design time. Not delete the existing one, but just disable it. After that the config file specified in the SQL Agent job was used.

Google recaptcha firewall exception options

Google reCAPTCHA firewall options articleWe’ve implemented Google recaptcha in one of our web apps which is nice and works fine on our local machines. When we deploy to our dev server however we were hit by outbound firewall rules so .Net threw an exception along the lines of ‘Unable to connect to the remote server

Google reCAPTCHA firewall options

Upon investigating what firewall exceptions we would need for our various environments, we noted that Google recommends opening up the relevant port (80 if http is fine, 443 if the web app will run with a secure certificate/https) to outbound connections. This is highly insecure and most likely unacceptable to most network administrators. That option was therefore not a runner for us.

The best practice and more secure approach would be to create rules which are restrictive as possible using only specific IP addresses. We looked into this, however from researching online it seems that Google’s IP addresses change regularly which obviously creates a problem for maintainability and for the reliability of the application. One comment from April 2015 on the ‘How to access reCAPTCHA servers through a firewall‘ recaptcha wiki page in particular worried us:

Hi guys, we are using the Recaptcha solution for almost half a year now, and in this time we had to change the firewalls four or five time already, just to find out today that they have changed again..

We also noted similar comments such as the below:

Yesterday it worked fine once we configured the firewall to allow requests for the IP address that was causing the problem.  But today it’s requesting using a DIFFERENT IP address, which isn’t configured.  Not only is this a problem for us right now, but it makes me uneasy.  What happens if it changes IP addresses again?  More broadly, what is the issue, here?  Why did it use one IP yesterday and another today?

Additionally the ‘How to set up reCAPTCHA‘ wiki page also mentioned that IP addresses can change. One way to mitigate the risk of IP addresses changing might be to catch the exception that is thrown when the app attempts to communicate with http(s):// when the firewall is blocking such communication. The catch block could then perhaps bypass reCATPCHA, considering the request to come from a human and also email IT support who can then verify if in fact IP addresses have changed. Of course this still isn’t a runner for most enterprise applications.

In the end it seems the best Google reCAPTCHA firewall approach for most will be to allow outbound requests on port (80 or 443) based on the hostname Using DNS allows us to abstract out any changes to the underlying IP addresses. Unfortunately however I believe this approach may not work for everyone as some firewalls will not support this configuration, furthermore I believe configuration of such rules is more complicated than the IP address based approach.  That being said it does provide reliability and is certainly more secure than just allowing all outbound connections on port 80 or port 443 so this would be the approach I would recommend.

What Google reCAPTCHA firewall rules are you guys using to enable use of this tool in your applications?