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.
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?
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.
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.
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.
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.