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.
Sovereign teams
sov·er·eign·ty
1. Supremacy of authority or rule as exercised by a sovereign or sovereign state.
2. Royal rank, authority, or power.
3. Complete independence and self-government.
4. A territory existing as an independent state.
5. A group or body of persons or a state having sovereign authority.
Take a look at the list below;
- Disconnect between the business and IT
- Distrusting environments
- Lack of genuine team empowerment
- Poor Product Management
If you do suffer with any of the points above I would like to introduce you to a new concept of creating a Sovereign Team or Sovereign Teams. Recently I was reading an article by Mitchell Baker (CEO Mozilla) and she touched on User Sovereignty, this inspired me to think about Team Sovereignty.
A Sovereign team is in control of its own destiny, it operates with complete autonomy with the ability to control its destiny. Along with the these benefits also comes responsibility and ultimately accountability.
History shows that a good Sovereign leader listens to their people, just like how a team should listen to their customers.
Taking a pragmatic view, your business isn't going to change overnight, if they are distrusting today it is highly unlikely that they will be trusting tomorrow. Instead of trying to win the war, choose 1 of your teams to act as a Soveriegn team and get business buy-in that the Sovereign team you have is trusted and empowered to make the right decisions. Choose your team wisely, as this team could be the make or break of the opinion of the business towards your department. If it works, create more Sovereign teams, until all of your teams are Sovereign teams.
A word to the wise, as you create Sovereign teams it is highly likely you will encounter individuals who are 'letting the side down', I don't believe the team should call them out (no 'team' leaves anyone behind and encouraging call outs will create a negative culture within the team) so make sure that the line manager of the team members is on board with dealing with 'problematic' team members. Remember any Agile team is only as good as its team members.
Mr Ching keynote speaker at Scrum Gathering Atlanta 2012
I would like to congratulate my fellow GE colleague Clark Ching for being the keynote speaker on the opening day at the Scrum Alliance Scrum Gathering Atlanta 2012.
Heston and Ramsey got it so wrong…. and why Scrum could help in the kitchen
For any of you who watch cooking shows with Ramsey (Hells kitchen) or saw Heston transform Little Chef (for those not in the UK, Little Chef is a highway type restaurant), you would have heard both of them saying to the owners that a restaurant cannot succeed by having lots of items on the menu and instead that the menu should be simplified.
This makes a lot of sense, particularly to fellow Agile people, breaking things down into simple, manageable chunks, I myself someone who preaches this often to my teams. It also supports my theory on having presenting too much choice - Is limiting what my partner can buy a bad thing?, but there are a lot of products that need an extensive choice array? How would you scale this up? Before I continue, this is more than likely obvious to those working on large scale computer games.
Heston and Ramsey have missed a trick, instead of having only one team of chefs, have more than one team making food and therefore increase your selection choice.
Upon a recent family holiday to The Palm Atlantis in Dubai I watched as one of the restaurants produce an enormous array of great food. In contrast to the meal I had at Heston's diner, though the food was good (equal not superior to the restaurant the Palm Atlantis), the menu choice was very limited by comparison.
What does this have to do with Agile you may ask? You can work on a large amount of features as long as you have multiple Scrum teams. Scaling up Scrum is not that hard, nor that difficult, but often scares new Scrum Masters when faced with Scaling up Scrum.
Back to my original point, maybe Ramsey / Heston should come and visit a scaled up Scrum model and then we could show them how to have a large array of options.
This post is contradicted though in my post; Is limiting what my partner can buy a bad thing?
The really simple Agile tool – update
At a major junction I thought I would update everyone of the really simple Agile tool.
- GUI - 60% complete
- Application - 10% complete
- Database - 5% complete
The GUI work is going better than expected, though there is some refactoring of the JS for neatness reasons. The biggest issue has been the way to handle offline storage. I had just implemented some basic Web SQL (SQLite) code, but as some of you may or may not know this has been removed from the W3C specification in favour of IndexedDB.... argh... I'd just got my head around SQLite through JS. It hasn't been helped that the examples for IndexedDB are absolutely shocking, to the point I nearly removed one of the really simple Agile tool's major features; offline storage. Step in http://greenido.wordpress.com/2011/11/29/convert-your-websql-to-indexeddb/ the only working example of IndexedDB, this has been the reason why offline storage is still one of the main features of the really simple Agile tool 
.
I'm hoping that I'll have the really simple Agile tool's backlog visible through the actual tool within the next 2 months (I'm cheating by pre-loading in JSON files that contain the state of the project, you'll be free at this point to do the same, but I would not advise it as it will not support updating features; it'll be read-only)
Github source: https://github.com/cbruiners/A-really-simple-Agile-tool
Agile Expert @ GE
Its been sometime since I last blogged, incredibly busy since the end of October and I don't get two minutes spare.
At the beginning of November I moved into the vacant position of Agile Expert with GE Energy after spending 9 months with GE I realised that there was a real chance of achieving great things with GE so I jump onboard their bandwagon.
The anatomy of a good story
I often get asked what a 'good Story' looks like. Creating a great Story isn't as difficult as people think, nor does it require an understanding of the dark arts.
A good Story should include as much descriptive text to describe the story as needed, though you should resist the need to write down too much detail (http://carlbruiners.com/2011/06/amber-is-heathly-green-means-youve-over-cooked-it-and-red-means-we-havent-got-a-clue/) in favour of writing a concise paragraph or two. To help support this concise paragraph (or two) break it up into a bullet point list which acts as your Acceptance Criteria. Also remember to keep in mind I.N.V.E.S.T (Independent, Negotiable, Valuable, Estimable, Small and Testable).
The only difference between a User Story and a Story is that a User Story must written in business english; i.e something that most people wil be able to understand if they even have a small amount of knowledge about the product. A User Story is from perspective of the User (hence its obvious naming).
A vanilla Story though should start off by identifying the requesting role type;
- As a developer...
- As a tester...
- As a architect...
- As a documenter...
And though you should ideally keep the text as readable as possible, you could add in detail such as a method name or a class name for example. Remember that you should always include Acceptance Criteria for both Story types.
How do you qualify your stories? For User Stories get a BA to read the story, ask the Product Manager to skim over the backlog and always ask the team to review your stories (normally when being chosen for a Release Backlog, don't waste time defining stories that may never get played). As a double check (when the team Scrum Master) I often read the User Stories and if I can understand that unit of work then its a good indication that the story is defined clearly enough.
User story breakdown
Many people have asked me about my blog post concerning the Difference between a user story and story, so to make things even more clear I have generated the graphic below explaining the breakdown of User Stories. I have omitted the acceptance criteria in each of the stories as this post is about the flow of stories, but always remember to add acceptance criteria to your stories.
Story Breakdown
Product Management and Product Owners
After a conversation with a very, very close friend, I realised that the area's I have failed to blog about are;
- Product Management
- Product Owners
As of this weekend I will make the effort to write at least 2 blog posts per week covering the topics around both roles, as there is soooo much I can write on the subjects.
Visual Retrospective Generator (beta)
As we had to delay the launch of Scrum Solutions until 11th August we didn't want our customers to think that we had forgotten about them.
While the rest of the team are busy working on iOS, Andriod and Win mobile projects, I was busy listening to my followers and by far the most popular article on my site was the article and code for generating the Visual Retrospective. At the time I had promised to write an application that will help you generate the visual retrospective.
That application is now ready (admittingly in beta, while I sort out some of the format defects).
Visual Retrospective Generator
MediaWiki Retrospective Example
[Download]
The application allows you to output your retrospective's in the following formats;
- HTML - Visual retrospective wall
- HTML - List style
- MediaWiki
- XML
- CSV
- PNG
The application will allow you to output to multiple formats in 1 click, useful for generating a visual retrospective as well as keeping your PM happy with a CSV formatted list . For what all the options do read the READ ME Visual Retrospective Generator text file that's included in the package.
Quick start tip: Check HTML and check the 'Copy support files' to generate your first Visual Retrospective.
Once I (or the team, nod, nod, wink, wink) have fixed the defects there are some other features in our product backlog for this, I'll post a new blog each time its updated.
And one final thing, this tool is free and will always be free. The only time there will be any costs is for companies wanting to integrate the tool (through its API) into their solution or if a commercial company wants to remove the Scrum Solutions logo or link.
Requirements: .NET 4, Windows XP/Vista/Win 7
Missing a feature? Any negative / positive feedback? Please leave a comment