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.
Agile Awards UK 2012 – Nominated…
Yesterday I received the good news that I have been lucky enough to have been nominated for 'The best Agile Coach or Mentor' award at the Agile Award UK 2012. Its always nice to be recognised by your peers.
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.
Is limiting what my partner can buy a bad thing?
My partner is a shopaholic, she loves nothing more than walking around shops for hours. One of the more distressing parts of the 'shop' is when she is faced with multiple choice and has to make a decision based on what would be best, often making a quick decision becomes a drawn out one.
An example would be stopping at a petrol station, asking the kids what they would like to snack on and then not being able to find the chosen snack for one of our children. At this moment the simple selection of a snack for our children becomes a nightmare when faced with the selection of 30+ choices of chocolate. Which snack do I buy? What type of chocolate is closest to the one requested? How big is the requested snack? etc... My partner will openly say that she would prefer to have a limited choice in which too choose from for our children.
Without upsetting my other half on her ability to make choices, I'd like to ask the question; Is an infinite choice select really best for your PO / PM? Or is it better to limit the options available for selection? As a team how much time is wasted defining stories for 30 chocolate bars (package design, chocolate content, etc...)? Is it prudent to limit the amount of choices available?
When I'm working with newly formed teams who have no Agile / Scrum experience I explain to them that the Product Backlog is like a wish list, so technically you could create a story that puts a pig on the moon. As a team progresses you quickly realise that creating 'pointless' stories has a cost; excessive backlog grooming. Create a intelligent, realistic deliverable / achievable product backlog, one that doesn't take excessive time to manage. I always advise teams to keep 'just enough' user stories in the Product Backlog, enough for selection by the PM / PO and enough for the team to barter with.
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
Introducing the really simple Agile tool
After many years of using many different tools, I wanted to create a 'back to basics', uncluttered, simplified Agile project tool.
The purpose of this tool is to offer support for Scrum and Kanban (XP practices also such as TDD, Pair Programming, etc...) and remove all of the additional 'fat' other tools have become bloated with. You'll be able create views that are valuable to the Agile team (Agile tools are not just for management), no server side technology required*, visual MMFS (minimal marketable feature set) unique 'tricks of the trade' tools direct from Scrum Masters, ability to customise the tool around your Agile processes and lots more features. The best bit is it'll be free for 1 to 1,000,000 users.
This is an open source project, I have a day job, this project will get updated in fits and starts. Please fork and contribute whenever you can, I'd love to get a MMFS version out for the summer, but I'm no JS guru so it may take a little longer
At present most of the GUI work is going on, once this has finished it'll be the none-server side SQLite stories to be worked on and then lastly it'll be the server side support stories. The GUI stories are currently estimated as 6 man months of effort.
Github source: https://github.com/cbruiners/A-really-simple-Agile-tool
Agile Edge presentation
Just a few hours ago along with Pritam (George) Seehra I presented to the Agile Edge 2012 gathering a presentation covering the following;
- The Agile team and “the management”
- Scrum Masters – Getting them and keeping them
- Are all Agile teams made equal?
- The Continuous Integration glue
The format was different to your usual death by PowerPoint, instead we had had 5 simple slides and then most of the time was spent discussing most of the points noted. When I get home (train broadband is awful) I'll upload the presentation. Click here for the presentation.
Special mention to the J P Morgan gang, it was great connecting.
Agile test curve
This post is an update to my original post Testing Curve. I've had a few emails asking for a more detailed graphic and some advise on avoiding the unheathly test curve.
Agile Test Curve
Don't allow test debt to build up in your Sprints. Start testing as early as possible. Tips on how to avoid the unhealthy test tidal wave;
As a Team
- Have smaller size stories in your Sprint backlog. Never, ever play an Epic.
- Use BDD to capture all test scenarios, this will help the tester test the right area's as well as the edge cases.
- Automate as much of your testing as possible, reduce the testers manual efforts.
As a Developer
- Manage your WIP; complete a story before working on another so that you release a story for testing sooner rather than later.
- Minimise bounce back in Sprint. Run unit tests to ensure that the testers are testing on test ready code.
As a Tester
- Prepare your test environments at the beginning
- Look at the team task board to see what is going to be ready next for testing and make sure all test cases are in place.
Agile ALM
Do you have an Agile Application Lifecycle Management plan?
Agile ALM's are good when taking waterfall centric teams on the Agile journey (ALM's are not Agile specific, arguably they are waterfall in their nature). If you are converting a waterfall team, draw up a ALM, they'll be able to relate to this very easily and quickly. I have a PowerPoint slide that has the high-level view above and then a transition smart graphic that covers each one in greater detail. Use each section to your advantage, highlighting Agile practices / benefits against each of the above.