WCF on .Net 4.x ReST Service with IIS 7 or 8 = HTTP Error 404.17

So my newly created WCF ReST service (or webHttp service, as MS more accurately like to call it) runs fine in Visual Studio 2012, using IIS Express. But when I switch to IIS proper (in my case, IIS8 on Windows 8) I get:

HTTP Error 404.17 - Not Found
The requested content appears to be script and will not be served by the static file handler.

Most so-far extant posts on how to fix this, refer to how to fix it for .Net 3 on Windows before Win8: Use "%WINDIR%\Microsoft.Net\Framework\v3.5\Windows Communication Foundation\ServiceModelReg.exe" to register or to repair registration of WCF components. (The other gotcha being, having the right AppPool settings for .Net version & for 32 vs. 64 bit).
This doesn't work for Windows 8 / .Net 4.X. Instead you must open the control panel "Turn Windows Features On or Off" and tick the box for Http activation:

Windows Features - Windows 8 - Net45 - WCF - Http Activation Tickbox
Windows Features - Windows 8 - Net45 - WCF - Http Activation

Which should fix the issue after a couple of minutes.

Agile Adoption

If a team or organisation wants to adopt agile, should they do it all in one, or gradually? How do you overcome problems in agile adoption?

Agile Principles when Adopting Agile

Agile is not about process and methodology; it's about people, relationships and learning and so turns out to be very much democratic and consensus based. Effective adoption presupposes that you've got the team(s) on board; if you have to impose agile, you're probably doing it wrong. You can't adopt faster than your teams and individuals are motivated to adopt.

If you apply the agile manifesto to the project of 'adopt agile' then you'd adopt agile incrementally, of course. I suggest an obvious principle: You can't adopt faster than you can learn.

Agile's take on organisation & adjustment is that teams self-organise with regular reflection, which enables you to see what's not going well and consider ways to correct. There is no learning without feedback. Adopt incrementally with regular reflection and adjustment.

Agile teams puts work items in priority order, in to deliver the greatest business value first. Look at your current pain points – what's not working well – and find out which practices are found to address them. Prioritise changes which add most value.

Risk management is arguably a missing subject in agile, so let's add that here: soberly consider what, at this stage, you are capable of adopting successfully. First adopting practises you're capable of to maximise your chance of early success. The choice to deliver value or to attack risk first is a judgement call. When you're doing something new the risk of failure is high, so that judgement is largely about knowing how new to your team(s) the changes you're making really are.

Finally, agile starts with the vision of a wider community learning. Any fool can learn from their mistakes but the wise learn from others' mistakes too. In the past 10 years, others have already tried out all the mistakes for you. Call in someone in who's done it before.

Software Architecture vs Agile Development

I'll be speaking at the International Association of Software Architects UK Summit in April, together with Alan Gawthorpe.

IASA UK 2013 SummitOur subject is "Doing architecture with agile teams" and in a short session we'll be covering both the 'human' angle of working with agile teams and the more technical question of what kind of architecture might count as agile (and is it any better than non-agile architecture).