Carl Bruiners Agile / IT Development Consultant

28Dec/111

ITIL, SLA’s and Agile

Three years ago I sat down for two days with a chap who used to be the IT Director for the Pru, one of the questions he asked was if we had SLA agreements (or as I prefer I(nternal) S(ervice) L(evel) A(greement) for SLA's for departments within the same business) and I replied 'kind of', in one sentence he taught me a valuable lesson when he then responded 'there's no such thing; either you don't or you do', luckily I'm a quick learner so when the session continued with another question, 'what percentage of delivery against SLA's should you as a business be promising?', I replied 100%.

If you go into a car garage and buy a new car you wouldn't be happy if the salesmen said that the warranty was only valid 70-80% of the time if your engine blew up, so why do so many IT businesses guarantee only 80-99% SLA's, why not aim for 100%.
All to often IT departments say that it isn't possible to achieve 100% SLA's, or they build in silly clauses. Why is it so difficult for IT departments to strive for 100% SLA's, the Japanesse train system is measured on failure by seconds (unlike the UK train companies which are on deemed to be late or early if they arrive or leave 10 minutes either side of the stated time!) and even based on these ultra tight they achieve 99+% against their SLA's to millions of daily commuters.

I have spoken with many Agile experts over the years and it surprises me how many are unaware of ITIL, though my bread and butter (as well as my beliefs) is that Agile is the best way to develop software, I am a great believer in using the right parts from PRINCE2 and ITIL, in the same way we build our Agile model up using the best parts of Scrum, XP, Kanban, etc.... we should be open to using other non-Agile principles and judge them on their own merits, if it works for your business then why not embody  it and build it into your Agile model.

28Dec/110

Continuous delivery, test automation and UA(T)

Everyone talks about UAT, but having a UAT phase is in many ways failure of your development model. Why should a user have to run testing if the requirements were captured correctly through continued engagement throughout the development (using sprint showcase)? Why does a user need to test the software when your automated test coverage should be 100% (unit, functional, GUI, performance, etc..)? Are you building total product or developing against features? Spending hours / days on devising a UAT checklist or strategy?

I have put the (T) of UAT in brackets as part of your continuous delivery model should incorporate the concept of omitting the testing element and instead the user should just be signing off against a deployment to a staging environment.

User Acceptance is an improved model on User Acceptance Testing, it'll minimise the need for User Acceptance and stop you from having to put together a user testing strategy.

26Dec/110

Agile Expert @ GE

Its been sometime since I last blogged, incredibly busy since the end of October and I don't get two minutes spare.

At the beginning of November I moved into the vacant position of Agile Expert with GE Energy :-) after spending 9 months with GE I realised that there was a real chance of achieving great things with GE so I jump onboard their bandwagon.