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.
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 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.
ITIL, SLA’s and Agile
Three years ago I sat down for two days with a chap who used to be the IT Director for the Pru, one of the questions he asked was if we had SLA agreements (or as I prefer I(nternal) S(ervice) L(evel) A(greement) for SLA's for departments within the same business) and I replied 'kind of', in one sentence he taught me a valuable lesson when he then responded 'there's no such thing; either you don't or you do', luckily I'm a quick learner so when the session continued with another question, 'what percentage of delivery against SLA's should you as a business be promising?', I replied 100%.
If you go into a car garage and buy a new car you wouldn't be happy if the salesmen said that the warranty was only valid 70-80% of the time if your engine blew up, so why do so many IT businesses guarantee only 80-99% SLA's, why not aim for 100%.
All to often IT departments say that it isn't possible to achieve 100% SLA's, or they build in silly clauses. Why is it so difficult for IT departments to strive for 100% SLA's, the Japanesse train system is measured on failure by seconds (unlike the UK train companies which are on deemed to be late or early if they arrive or leave 10 minutes either side of the stated time!) and even based on these ultra tight they achieve 99+% against their SLA's to millions of daily commuters.
I have spoken with many Agile experts over the years and it surprises me how many are unaware of ITIL, though my bread and butter (as well as my beliefs) is that Agile is the best way to develop software, I am a great believer in using the right parts from PRINCE2 and ITIL, in the same way we build our Agile model up using the best parts of Scrum, XP, Kanban, etc.... we should be open to using other non-Agile principles and judge them on their own merits, if it works for your business then why not embody it and build it into your Agile model.
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.
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
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.
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.
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.