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.
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!
Epic Task Cards
So many times I have seen immature SCRUM teams include Epic Task's within a SPRINT without them being broken down.
SCRUM is about taking large pieces of work and breaking them down into smaller tasks which are easier to estimate against, develop against, test against, etc... This along with variable SPRINT lengths depending upon the total of the cards (aka mini-waterfall), are my BIGGEST dislikes!
SCRUM / SPRINT Burndown Chart
Following on from my keep SCRUM simple, I thought I would share with you an example burndown, this example shows an unheathly burn down, as you can see the SPRINT flat-lined for the first 2 days.
Burndown chart (Click to enlarge)
When I upload my template spreadsheet I will also post how to track individual team members velocity.
Dynamic SPRINT Backlogs – Ditch Product Backlogs :-)
Anyone who has worked with me will know my dislike of Product Backlog, and in particular Grooming
Product Backlogs. I cannot stress how much of a waste of time grooming items that could become obsolete or change dramatically is.
I have witnessed teams take 2-3 hours to groom a backlog, based on a average team of 5 thats cost the business 10-15 hours of work effort (1 to 2 man days), this happening every two weeks then becomes a 2-4 day loss every month (for those interested, 24-48 days p/a), any good Manager could tell you thats unacceptable.
If you are asked to build a car, would you budget for all variants of car? NO! This is a waste of resource (I'll be doing a few articles on 'Lean' soon, and that's all about minimising wastage).
Instead make your SPRINT Backlog more dynamic, allow the PM / PO to define your SPRINT backlog the day before you start your SPRINT and get the team to only estimate for those SPRINT items! At a higher level, and for resource planning purpose's, the PM / PO can create a simple gnant pipeline / roadmap chart.
At the SPRINT planning session, enable your team to ask simple questions to the PM / PO, i.e. 'What car style do you want your car to be? Is it a 3-wheeler? Does it have leather seats? etc...
Encourage the PM and PO (or development manager) to sit down the day before to briefly discuss the next SPRINT backlog.
Grooming Product Backlog is normally long winded, often pointless, and normally leads to presumptions being made by the team.
Quick, Intuitive, Simple SCRUM Tools
I have had lots of people ask me which software I use when running their SCRUM's; TFS, OnTime, etc. All have their merits, but my personal favourite, is a wall with different colour post-it notes and some black tap.
My problem with software tools are that they over complicate the process, not having a wall also means a lack of instant visibility to the PM and stakeholders, something I promote (I like the business walking up to the wall and seeing the flow of work. Having the wall also self-promotes SCRUM.)
To supplement my SCRUM wall I use a simple Excel spreadsheet which generates my burndown chart and tracks progress. I will post up my template tomorrow spreadsheet tomorrow.
Below is my current SCRUM wall, I use different colour cards to acknowledge different task types (Green - Product Backlog, Red - Developer Task, Yellow - Tester Task, Orange - Impediment);
Scrum Wall (Click to enlarge)
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.
Keep your SCRUM wall fresh
A SCRUM wall that represents your desk often means (if its like my desk 
) that it needs a refresh, do it daily (and encourage the team to pro-actively move cards when they change state) , I normally get the team to refresh their wall immediately after the morning daily update.
On a side note, I don't allow more than 1 or 2 cards in the 'In Progress' section of the wall, alot of developers complain about this, but I always ask them if they are using 2 keyboards at the same time? It is IMPOSSIBLE to physically be working on more than two items at any given time. If you find there is any possibility of a developer working on multiple task cards at the same time, then the team has poorly constructed its task card desk for the SPRINT, task cards should be independent of other cards, coupling of cards should be frowned upon.
Simplify Your SCRUM
SCRUM should be a light weight, simple methodology to run with. I use the word should, because too many businesses are over complicating their SCRUM models.
Keep your SCRUM simple, don't spend hours and hours grooming a product backlog when items in that backlog are subject to change / may never be included in a SPRINT, stand up when doing daily updates, make sure that transparency between all stakeholders is maintained, etc...
I like SCRUM because it is a lightweight, simple and evolving methodology, don't kill it by try to add on unnecessary complications.
SCRUM in name, not in nature
A growing concern of mine is that so many companies have poorly implemented SCRUM. The kind of issues I've encountered are;
- Sprint lengths constantly growing because the Sprint backlog has not been completed on time
- Sprint backlogs being treated as a product backlog - with the Sprint length being set to complete all of the backlog (mini-waterfall)
- Prioritisation of items within the Sprint Backlog, no team freedom to select from the Sprint backlog
- Lack of protection for the SCRUM team
There appears to be a trend of using Agile / SCRUM in name but then to run a so called SPRINT more like a mini-waterfall.
The most worrying trend is that the issues listed above normally originate either from the 'SCRUM' expert who implemented SCRUM (and therefore also their bad habits) or from very senior people in the business (who the lesser beings won't question).
Like many PRINCE2 Project Managers, who have problems with PINO (Prince in name only), we as SCRUMMER's must now also face the reality that allot of SCRUM implementations are poor, and that there are many SCRUM implementations that are;
- 'SCRUM in name, not in nature'.
Like our fellow PRINCE2er's, we as SCRUM masters must educate all levels of the business, and sometimes that can prove hard, particularly with more senior management, but demonstrate sucessfully why we do have certain processes (like fixed length SPRINT iterations) in place to ensure that they, the business, gain the most benefit from SCRUM.