Carl Bruiners Agile / IT Development Consultant

7Mar/120

Book review: Kanban by David Anderson

I've recently finished a book by David Anderson, Kanban, on my new best gadget, my Kindle.

Its not a bad book but in the earlier chapters David makes statements like; 'it works because its Kanban, because it just does...'. The first few chapters are very skin deep without much supporting evidence as to how or why Kanban made a difference.

Don't let it put you off to much as the book does improve and after the early chapters David begins to demonstrate his mastery of Kanban backed with examples. Its not in the league of books like Scrum / XP from the trenches, but its a good book for those looking to investigate Kanban, but for more seasoned Kanban  experts you may be hard pushed to find lots of value in this book.

Side note: If you don't have experience or knowledge of TOC, it might be worthwhile also having a copy to review alongside, for example David will make reference to Drum-Buffer-Rope and unless you've read or worked with TOC the explanation of Drum Buffer Rope isn't clear.

4Mar/121

Introducing the really simple Agile tool

After many years of using many different tools, I wanted to create a 'back to basics', uncluttered, simplified Agile project tool.

The purpose of this tool is to offer support for Scrum and Kanban (XP practices also such as TDD, Pair Programming, etc...) and remove all of the additional 'fat' other tools have become bloated with. You'll be able create views that are valuable to the Agile team (Agile tools are not just for management), no server side technology required*, visual MMFS (minimal marketable feature set) unique 'tricks of the trade' tools direct from Scrum Masters, ability to customise the tool around your Agile processes and lots more features. The best bit is it'll be free for 1 to 1,000,000 users.

This is an open source project, I have a day job, this project will get updated in fits and starts. Please fork and contribute whenever you can, I'd love to get a MMFS version out for the summer, but I'm no JS guru so it may take a little longer :-)

At present most of the GUI work is going on, once this has finished it'll be the none-server side SQLite stories to be worked on and then lastly it'll be the server side support stories. The GUI stories are currently estimated as 6 man months of effort.

The really simple Agile tool

Github source: https://github.com/cbruiners/A-really-simple-Agile-tool

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.