Carl Bruiners Agile / IT Development Consultant

Carl Bruiners
21Feb/122

Agile Edge presentation

Agile Edge 2012Just a few hours ago along with Pritam (George) Seehra I presented to the Agile Edge 2012 gathering a presentation covering the following;

  • The Agile team and “the management”
  • Scrum Masters – Getting them and keeping them
  • Are all Agile teams made equal?
  • The Continuous Integration glue

The format was different to your usual death by PowerPoint, instead we had had 5 simple slides and then most of the time was spent discussing most of the points noted. When I get home (train broadband is awful) I'll upload the presentation. Click here for the presentation.

Special mention to the J P Morgan gang, it was great connecting.

5Feb/120

Agile test curve

This post is an update to my original post Testing Curve. I've had a few emails asking for a more detailed graphic and some advise on avoiding the unheathly test curve.

Agile Test Curve

Agile Test Curve

Don't allow test debt to build up in your Sprints. Start testing as early as possible. Tips on how to avoid the unhealthy test tidal wave;

As a Team

  • Have smaller size stories in your Sprint backlog. Never, ever play an Epic.
  • Use BDD to capture all test scenarios, this will help the tester test the right area's as well as the edge cases.
  • Automate as much of your testing as possible, reduce the testers manual efforts.

As a Developer

  • Manage your WIP; complete a story before working on another so that you release a story for testing sooner rather than later.
  • Minimise bounce back in Sprint. Run unit tests to ensure that the testers are testing on test ready code.

As a Tester

  • Prepare your test environments at the beginning
  • Look at the team task board to see what is going to be ready next for testing and make sure all test cases are in place.
22Jan/120

Personal online security

I've spent a lot time working on security projects, ranging from securing personal child information to PCI / DSS credit / debit card security.

I also spent time advising a steering group on social media behaviour and recently I had to give a lecture to a family member on what not to do online.

In the modern world of the web, social media / social sharing is making it even easier for a would-be hacker to obtain data to compromise your integrity.

Things to remember;

  • Don't use your real name. Try obfuscating your true name; use a nickname instead of your real name
  • Use your date of birth as your pin number or a mixture of birthdays (partner and your day or month or year, I managed to disarm a relatives alarm just by trying two combinations of their birth of date)
  • Try hiding your family members you are linked too on your social sites (Facebook, Twitter, etc..), a lot of security identification methods use mothers maiden names
  • If you have to leave a phone number on a public site / social media site use a mobile and not a landline number, ideally don't leave any contact telephone / fax number
  • Keep pictures secure on social media sites, don't share with everyone

Using some of the points above I'll reverse these and give you an example of how easy it is to access account details and change them;

You accept an anonymous friend request on a social networking site, once accepted this 'new' friend can see your relatives (scanning your friends list with the same surname), your mobile phone number and your date of birth (information area). Your new friend rings your mobile a few times until they get through to your voicemail which announces the carrier you use. Your new friend now rings up the carrier, and they ask for personal identification; your name, your date of birth and your mothers maiden name. Your new friend now adds a second line to your account and requests the SIM card be sent to an alternative address, your new friend runs up hundreds of dollars on your mobile account over a period of a month. Like most bills, you don't receive a paper copy of the bill and you only notice that there is a problem once your current account has been debited and left you no money to pay your rent / mortgage, school fee's, etc... Now imagine trying to prove to your mobile phone carrier that you didn't set up the additional line and explaining to your other bills you cannot afford to pay.

The example above is relatively mild in terms of damage a 'would be' hacker could achieve. I have many friends who I could create new credit accounts; banks, credit cards, etc... based on data publicly visible on social networks. The possibilities of damage is endless; fake passports, access to personal accounts, etc...

22Jan/120

Over the GUI test automation, Excel and a little VBA

Automated testing via the GUI is a risky business and should be avoided as a testing method (Winrunner, Sikuli, EggPlant, etc...). Most of these tools use Bitmap comparisons to identify the area's that the script should work in, the problem with Bitmap comparison tools are that they can easily fail if the UI changes (just a few pixels can often confuse bitmap comparisons), even when the UI doesn't change repetitive layouts (cell's in a spreadsheet) pose a problem for Bitmap comparison tools.

We often explain to teams that they should use the layer below the GUI (GUI's should be a thin layer on the stack), a command line interface, macro mode, API, etc..., but alot of people struggle with this concept.

Think about using Excel, as a tester I need to automate setting different cell values as part of my test case. I could use an over the GUI tool to simulate the user clicking between cells and set the values, but more often than not a GUI testing tool isn't going to be able to distinguish between one cell and another (give it a go, all cells look the same :-) ), therefore causing this test to fail.

Below is some very basic VBA setting values in a Spreadsheet;

Sub SetValues()
Range("A1").Value = "Test Value Cell A1"
Range("P2").Value = "Test Value Cell P2"
Range("R9").Value = "Test Value Cell R9"
End Sub

This code will set the values of the cell's programatically, therefore removing the need to set the cell values 'over' the GUI and also removing the risk of not setting the correct cells with the correct values.

Over the GUI testing often appears reasonably precise to run with when starting out, but once automated and scaled up (particular if part of your continuous delivery pipeline) you will find it fails more often than not and becomes a QA nightmare.

22Jan/120

Identifying an Epic using apple strudel

I recently had a work trip over to Stutensee in Germany, working with a team wanting to investigate the benefits of Agile.

One of the team members asked me to explain the difference between an Epic story and a non-Epic story, to help me explain the differences I referred to a very, very good Apple Strudel I ate the night before at a local bar.

I explained that if you had a family size Apple Strudel that you wanted to eat, would you attempt to eat it in one? or break it up into managable sizes? Hopefully the anwser to this is obvious (for those who it is not, its the second of the two). Now imagine a story that is 'family' sized, too large to 'consume' in one go, which we refer to as an Epic Story, instead of attempting to complete the whole Epic Story in one, you break it up into manageable sizes.

I wanted to share this example with you in case you are fed up with the 'Epic' book / chapters explanation :-)

5Jan/122

Reap the QA rewards by reducing defects

Reducing software defects has huge rewards for a business. I recently put together a slide on the commercial benefit of reducing defects, to quantify this as a cost to the business I put together a simple demonstration on the cost to the business.

Base

  • £58 p/d
  • 10 incoming defects p/w
  • 2 days per defect to fix

Defect Saving - Carl Bruiners

If you reduce the total incoming defects by 40% in the first year you'll save just over £22k, but it is completely feasible to achieve a 99% reduction in your incoming defects and your saving would be £55k p/a.

Any managers reading this will be over the moon, but the developers / testers and release managers will be scratching their heads @ how to achieve this. Defects only occur if you allow them to escape in the first place, look at your testing strategy, automate as much of your testing as possible, achieve continuous integration and aim for continuous delivery. Achieving a 99% reduction would be easier in some environments than others; i.e. a web application is going to be far easier to drastically reduce the incoming defects than a legacy installed application on the desktop (as you may not have the capability to upgrade / update desktop applications as frequently).

3Jan/120

Development stuff

Though most of my function at GE is concentrated on pure Agile (along with development practices; automation, CI, CD, etc...) a good friend asked me to start blogging on my wealth of experience / knowledge on development. As promised to him, I will start blogging on development topics as well as Agile (which this blog has been predominately focussed on).

3Jan/120

Difference between UI and UX

Understanding the difference between UI and UX experts is important if you want to maximise your user experience when designing your product / application.

  • A UI expert is someone who understands how a screen / page should be architected for the best user experience / drive areas of the screen / page that the business wants to promote.
  • A UX expert is someone who is concerned with how the users journey is unfolding navigating your product / application. They should work with the UI experts to make sure that each individual pages fits within the user journey framework

Can a UI and UX person be the same person, yes, but ideally not. UI type people are often designers who understand user interaction at a page level (often consulting analytic metrics on page / screen usage (http://www.crazyegg.com), device usage (mobile, tablets, etc..), screen resolutions (http://www.browsercam.com), etc...).

UX people are often architects who study / understand user journeys, for example an e-commerce UX person would be concerned with how to make the process of finding your product through to purchasing it as simple and easy as possible. Storying boarding would often be done by the UX person.

1Jan/120

Agile ALM

Do you have an Agile Application Lifecycle Management plan?

Agile ALM - Carl Bruiners

Agile ALM's are good when taking waterfall centric teams on the Agile journey (ALM's are not Agile specific, arguably they are waterfall in their nature). If you are converting a waterfall team, draw up a ALM, they'll be able to relate to this very easily and quickly. I have a PowerPoint slide that has the high-level view above and then a transition smart graphic that covers each one in greater detail. Use each section to your advantage, highlighting Agile practices / benefits against each of the above.

28Dec/110

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.