Carl Bruiners
I specialise in all things Agile (XP, Kanban, Lean), in particular Scrum. I have a passion for taking on 'problem' projects / teams and turning them into a sucess as well as promoting automated test driven practices.
More 
I am an enthusiastic, dedicated and accomplished Systems / application Architect, Project / Product Manager, Development Manager and Application Developer who thrives on delivering first class products.
My background is that of a developer who became a product / project manager and the head of application development. I am a certified SCRUM Master and have solid knowledge of PRINCE2.
I Work well on own initiative and can demonstrate high levels of motivation and organisation required to meet targets and deadlines. I have excellent interpersonal skills and communicate well at all levels.
Details
Contact Carl Bruiners
Carl Bruiners Twitter
Carl Bruiners LinkedIn
Carl Bruiners Scrum Alliance
Tags
Recent Posts
- Agile Awards UK 2012 – Nominated…
- Sovereign teams
- Mr Ching keynote speaker at Scrum Gathering Atlanta 2012
- Is limiting what my partner can buy a bad thing?
- Dubai
- Heston and Ramsey got it so wrong…. and why Scrum could help in the kitchen
- Mr Eddie Thomas
- Big update coming for the really simple Agile tool
- A really simple Agile tool – DB structure
- The really simple Agile tool – update
- Book review: Kanban by David Anderson
- Introducing the really simple Agile tool
- Agile Edge presentation
- Agile test curve
- Personal online security
- Over the GUI test automation, Excel and a little VBA
- Identifying an Epic using apple strudel
- Reap the QA rewards by reducing defects
- Development stuff
- Difference between UI and UX
Categories
- .NET (5)
- Agile (29)
- ASP.NET (2)
- Book reviews (1)
- c# (2)
- Continuous Delivery (2)
- Continuous Integration (1)
- CSS (1)
- Development (2)
- ITIL (1)
- JavaScript (1)
- JQuery (1)
- JS (3)
- Kanban (12)
- Lean (11)
- Misc Stuff (21)
- Product Management (2)
- Project Manageent (8)
- QA (2)
- SCRUM (34)
- Scrum Solutions (3)
- Security (1)
- Sharepoint (2)
- Silverlight (1)
- Technology (8)
- Test Automation (3)
- the really simple Agile tool (2)
- Travels (1)
- Uncategorized (2)
- VB (3)
- XP (10)
Blogroll
- Clarke Ching
- Karine Bosch
- Mike Cohn
- Peter Drayton
- Robert Lindström
- Scott Gu
- Simon Cromarty
- Stu Nicholls
- Tobias Zimmergren's
Archives
- April 2012 (8)
- March 2012 (4)
- February 2012 (2)
- January 2012 (7)
- December 2011 (3)
- October 2011 (3)
- August 2011 (3)
- July 2011 (3)
- June 2011 (9)
- April 2011 (9)
- March 2011 (3)
- December 2010 (1)
- November 2010 (1)
- October 2010 (10)
- September 2010 (1)
- August 2010 (3)
- July 2010 (3)
- February 2010 (2)
- December 2009 (1)
- November 2009 (3)
- October 2009 (6)
a really simple Agile tool
Powered By UserVoice.
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
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).
Testing Curve
Following on from my post, Testing in SCRUM / SPRINT, I wanted to share with you a diagram I have used many times to help explain why testing must start as soon as possible within a SPRINT and why it is important that task cards are testable as a self entity (Unit test).
It is incredibly important that teams do not have 'Epic' task card's included within their SPRINT, as this possibly hinders the ability of a tester to start testing early, as the 'Epic' wouldn't become testable until development is complete, hence delaying the test phase.
Note: I include an initial 'peak' to allow for testers writing up their test scripts
Agile testing curve (click to enlarge)
The unhealthy testing line has a tidal wave at the end of the SPRINT, unlike the nice calm waters of the healthy testing curve. Tidal waves should be avoided at all cost, as you run a greater risk of failing a SPRINT; the tester may not be able to complete all the testing within the time period and more than likely the QA will be compromised due to the pressure on the testers to pass a release as shippable.
If you see a very calm testing period at the beginning / middle of your SPRINT, be careful this may be the calm before the storm!
Testing in SCRUM / SPRINT
One of the area's were SCRUM is not very strong is testing. Most of the SCRUM models that have testing (EVERYONE should have testing) as part of their SPRINTs normally adopt XP's TDD. This is completely fine, TDD is great, but there are also additional / alternative ways to gain better QA (Quality Assurance) by implementing a simple QC (Quality Control) framework within your SPRINT's.
My current SCRUM wall has 5 phases;
- Not Done (SPRINT Backlog)
- In Progress
- Ready for Test
- Test
- Done
Phase 1 and 2 belong to the developers, before a task card can be promoted to 'Ready for test' it has to be peer reviewed (both at a functional and a code level). Phase 3 and 4 belong to the testers, only a tester can promote a task card to done. If it fails a test, the tester places the item back into phase 1, 'Not Done'.
I find this model enables the team to achieve very high QA. For a task card to be promoted to 'Done' requires it to have passed through two testing phases, firstly the peer review and then the testing team.
If QA is of the most importance (*note: that SCRUM normally has some tolerance built in for bugs, but certain work, such as life critical medical software, cannot afford any bug), then you can introduce an additional testing phase between Test and Done where by a task card must be peer reviewed through a senior tester / another tester before being promoted to Done.
I started of this entry by mentioning TDD, and the simple QC model I have given should ideally be used in addition to TDD (which I am a fan of), so that you enable your team to achieve high QA with minimal disruption to their daily workflow.