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.
Visual retrospective board
Anyone who has worked with me knows of my love of physical Agile task boards, automation and visualisation of everything (to make my life easier 
).
At my current role we have a wiki that is used for capturing retrospective information (along with other stuff). I found that each retrospective was one long list of bullet points under a heading (i.e. Keep Doing, Stop Doing, etc....). Speaking to the team/s I found that they didn't use the Wiki very often as they found it dull.
So to address part of the issue I wrote a small JQuery powered retrospective board. The package can be found here.
The board consists of 5 separate floated div's, png thumbnails (*.gif, *.jpg, etc... all supported) and obviously the js and css files. If your a web designer / developer you can easily add more sections.
I cannot take the credit for the JQuery part, that has to go to Addy Osmanu. I have just taken the code and manipulated it for my own purpose. Feel free to play around, you can increase the card / padding / border sizes (remember to not only change the CSS but also the inline css code within the js) or change the font size of your card.
I have included in the package both a standard web and Media Wiki versions (Media Wiki requires some special attention to make work).
Below is a screen shot example of the retrospective board embedded in Media Wiki
Carl Bruiners Media Wiki Retrospective Example (click to enlarge)
My CSM Certificate
I've been updating each of my profiles recently, and when paying my Scrum Alliance sub's I noticed a link I hadn't seen since 2008, a link to my CSM certificate. Instead of printing this off and sticking in on my office wall I thought I'd share it online with you (I've had to take so precaution to protect my certificate though).
Scrum Bargaining Board
An interesting discussion with Simon Cromarty, aka the Agile Pirate, on ways to help protect a team from over committing to more than their capacity for a sprint.
Simon then told me about a bargaining board.
What’s a bargaining board?
The product manager lays out the stories they want delivering in the next Sprint. Each card is placed on the board and as long as they do not overlap or hang over the boundaries of the board these stories are suitable
The task cards that are used on the board are relatively sized according to their point size, for example a 5pt story will be exactly half the size of a 10pt story (a personal favourite would be to have a 10pt story sized closer to 12pts).
After some further thought, I began to consider further model improvements. Instead of having just one side of the board for the team, make it double sided with a divider line. Allow the Product Manager to set out additional cards that won’t fit on the PM side of the board, this will allow teams to engage in negotiation conversations;
‘If you would like, instead of doing this 10pt story we could fit in that 5ot (or 7pts) and five of those 1pt stories?’
I would be tempted to make a story that is 10pts in size larger than that of two 5pt stories. So in reality a 10pt story could be replaced with 12pt’s of smaller stories. The reason why is because larger stores run a greater risk of being estimated incorrectly. This also allows greater flexibility in the negotiation between the PM and team.
Scrum Bargin Board (click to enlarge)
We’re Agile – Not
One of my biggest issues is how many companies have latched onto the buzz word, 'Agile'. Agile is NOT a defined framework, but should be used as a word to holistically describe that a company has agility using one or more Agile methodologies, i.e. XP, SCRUM, Lean, etc...
Over the past 2 years I have heard so many businesses proclaim that they are an agile company, often to find that either they are running a mini-water fall model or they've fudged together a poorly implemented agile in name not in nature framework (also see scrum in name not in nature).
Businesses, invest a little in your agile framework, it doesn’t take much effort, cost or resource to achieve. I’ll be posting an Agile audit soon, a tool you can use to see how Agile your company are.
Using User Stories / Stories and Tasks to feed traditional document centric models
Project documentation is often an area I see companies struggling with when it comes to Scrum. A simple way to remove this major impediment is to use your user stories to drive your more traditional functional specification and for your techie stories (not user stories) / tasks to be used for your technical documentation. For project imitation I find it best if the product manager can supply;
- High level brief - No more than 1-3 paragraphs
- High level goals - 1 paragraph with bullet points per feature
- Acceptance criteria - based on the high level goals, often a high level goal will generate multiple acceptance criteria. A validation rule, if you have a high level goal with no acceptance criteria, then it is not deliverable, so either remove the high level goal or change it so that it can have acceptance criteria.
There is often a need to document every aspect of what is to be built, but the reality is we know that often adopting this approach means that what we expected at the beginning of a project is not what is delivered. Heavy upfront documentation will not promote lateral thinking, and allow either the business or supplier to deliver the most suitable product for market.
N-tier stacks only one way
N-tier is vertical only. Once I had a debate with two other very talented developers about how many layers an n-tier application can have. We discussed what number realistically could replace the 'n' part, the most common being 3-tier / layer (Presentation, business and data or model, view, controller) along with some 4-tier / layer (add in service/s). Whilst there are genuine 5+ tier / layer solutions, after 4-tiers / layers it becomes very difficult to see many more layers.
The other two developers disagreed with me on this point, arguing that tiers / layers are not only stacked vertically, but horizontally as well. As much as I could see their argument, to this day I cannot agree. Tiers / layers are vertically stacked and inside each there are objects which we work with.
N-tier vertical only (Click to enlarge)
N-Tier / Layer Architecture is important
Many newbie developers often 'lump' their code together into one or two layers and find it often hard why we should use n-tier structures when developing. N-tier allows us to have clear separation between our UI, business objects and data objects.
A very recent piece of work I managed involved taking a legacy single layer model written in classic ASP and separating it out into manageable layers using .NET services. By creating a DAL and Services layer this helped the developers to deliver code at a far faster rate than the previous single layer as they did not have to 'untangle' the code they were working on and most importantly allowed quick diagnostic / resolution of problems as it was easy to identify the layer where the issue originated from.
Tiers / layers are important in application architecture.
N-Tier Architecture (Click to enlarge)
Difference between a user story and a story
A user story defines the requirements of the business and is written by the PM along with a BA (if available / possibly the same person), the user story is then broken down into individual stories that can be delivered against, which in turn is broken down into individual tasks.
Sounds simple, but in practice it is often not achieved. If you don’t break down User Stories you’re always working against Epic scale stories. It is critical to break down user stories into multiple stories so that each story is deliverable within an iteration (or if using Kanban ensures it can fit into the swim lanes).
It is important to break down stories into tasks so that you have a clear vision of what needs to be achieved to deliver the story. Having tasks also allows us to understand during an iteration how much time is remaining. Story estimations are finger in the air stuff, in particular if you are using relative points as your measurement, task hour / day measurements helps us to understand the actual remaining time against the original story estimation. Long term this will help improve your team’s ability to better estimate both user stories and stories.
On a side note, even though acceptance criteria is only a must have for user stories and stories, I also encourage teams to have acceptance against a task. Doing this increases QA throughout the whole of the process.
Be Adaptive
My biggest gripe with businesses / teams / people are those who forget one fundamental rule about (most) Agile methodologies and that is that they evolve. The best implementations of an Agile methodology is when they appear seamless. These Agile implementations fit the business like a snug glove and deliver high quality deliverables on a quick regular basis.
Evolve your models, keeping them rigid and static is against the sprint of Agile. If the team think they can find a better way to work, facilitate this and give it a go, if it fails, fine, don't stop evolving.