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.
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
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.
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.
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.
Cone of uncertainty
Cone Of Uncertainty
Above is a cone of uncertainty, this image demonstrates how larger stories come with greater risk when not broken down further.
Small stories between 1-3 pt’s shouldn’t have a grey area because for the team to know that a story is so small they should have a good grasp on what is required to deliver that story. I have placed the 5pt story on the line border of having grey matter, as though 5pt stories are of a size where the team should know whats required to complete the story, I have found in practice that this is not always the case and often 5pt stories end up being more like a 6pt’ish story .
As the story sizes increase, so does the grey area, and the grey area is not directly relational to the ideal inner cone. Get your scrum master to keep track of estimations, the actual time taken to deliver and from this you will be able to calculate your teams multiplier for the ‘grey area’. You can then use this in your sprint planning sessions as a safety buffer.
How do you minimise the ‘grey area’? Due to the nature of large stories it is not possible to remove the grey area completely, but you can utilise methods to reduce the ‘grey’. Having well defined stories and story acceptance criteria all help reduce uncertainty around a story. Though I’d rather spend time out of a meeting, if you have a 10 pt story and your grey area multiplier suggests a 3pt buffer, but a meeting would only take 30 minutes to help add clarity to your story, do the meeting as this may reduce the 3pt buffer. Do all that you can to reduce the grey area, but accept that you will never be in a position to completely remove this grey matter.
Improving Sprint capacity planning – The safety buffer / net
If your team consistently struggles to meet their sprint commitments because they are over optimistic with their story estimations, try to create a safety buffer or safety net.
Often teams try to create a safety buffer by only filling their sprint backlog to 60-80% of their capacity, though this approach is reasonable it is not very flexible or accurate.
Instead if we measure the uncertainty around estimated story points and use this metric to determine how much of a safety buffer we need to put into place, this gives us tighter accuracy and improved burn rates.
To demonstrate this (please note this excludes any JDI, BUA, etc..);
Team A has a velocity of 20 pts per sprint, they are planning to include stories made up of ten 1pt stories and five 2 pt stories. In this case we know that for the team to know an item is a 1pt or 2pt story they must have a clear idea of what is required to get the job done and the cone of uncertainty is virtually nothing. Based on the size of the stories I would recommend either no buffer or a very, very small one.
Team B also has a velocity of 20 pts per sprint, but their stories are individually larger in size, they have a 10pt, 5pt, 3pt and two 1pt stories. As there is a element of uncertainty surrounding the 10pt, 8pt and 5pt stories, I would recommend that the team builds in a greater safety buffer than Team A as there is an increased chance of there being more unknowns that will occur whilst the team is working on these larger stories.
How do we determine what the size of a safety buffer should be based on the stories being considered for a Sprint? This would require the Scrum Master to keep track of the teams points estimations and then at the end of a sprint note how big an item of work actually was, you then can use this figure as a multiplier for future stories of the same size.
For example if when a team plans a 10pt story, they actually take 12 points worth of effort in Sprint 1, then in Sprint 2 they take 14pt’s to deliver a 10pt story you have a multiplier of 1.3 for a 10pt story. If the team selects a 10pt story in a future Sprint your safety buffer would be 3pts.
Scrum Solutions
Driven by all things Agile
As a few of you are aware, I setup a company, Scrum Solutions, to supply Agile specific stationary, software (inc. iOS and Android) and consultancy.
Though we have already taken a number of orders, it brings me great pleasure in announcing our go live date of our web site will be the 11th July, www.scrumsolutions.co.uk. This will give our customers greater flexibility to explore and order our extensive range of products as well as review purchase order history.
To celebrate the arrival of the web site, I am pleased to announce that Scrum Solutions is a sponsor of the Agile Diner UK 2011 and I will be presenting the award for the Best Agile Coach / Mentor at the event.
The ‘Agile Pirate’
As many of those who know me know, I don't like soap box preachers, those who preach but incapable of putting it into practice.
I've been working @ GE now for just over 3 months and during that time I've had the pleasure of working with Simon Cromarty, aka 'The Agile Pirate'. A person who can demonstrate what he preaches and deliver success.
Simon is the best Agile guru in the UK. Simon is genuinely too modest to even contemplate that idea, but pound for pound Simon would be Manny Pacquiao of the Agile world. He is a great advocate of everything Agile.
Simon has helped me to grow, improve and galvanize my views around everything Agile. I wish him the best of luck, Redgate have done a great job of landing Simon, and I look forwarded to working with you again one day.