An assortment of thoughts.  Mostly tech related.

Brooks Law - Lines of Communication calculator - SIRI Shortcut

I’ve always loved the power of this visual from Lighthouse, representing Brooks Law and the number of lines of communication that exist in a team of a given size. It really demonstrates the mounting challenge of keeping people on track and in sync as team size grows:

Image Source:  Lighthouse

Image Source: Lighthouse

Large team size presents significant overhead in terms of comms between the members of the team. The Scrum Guide has standardised on 6 +/- 3 as the best team size - so, between 3 and 9 people, PLUS the Scrum Master and Product Owner.

I can never remember the formula to calculate the number of relationships, despite it being quite simple - n*(n-1)/2 - so I put together this super-simple SIRI shortcut to help me out.

So…when you need to put the case forward for smaller team sizes this handy Siri shortcut can quickly prove a point. Simply enter the number of development team members and it spits out the number of lines of communication between the team members. Enjoy!

Click  here  to download the Brooks Law/Lines of Communication ‘calculator’ shortcut to your iOS device…

Click here to download the Brooks Law/Lines of Communication ‘calculator’ shortcut to your iOS device…

Multiple Concurrent Sprints in a Single JIRA Project

…or having multiple teams work out of a single project in JIRA.

Out of the box, it might appear that JIRA doesn’t allow multiple teams to work out of a single backlog of work in JIRA, given that backlogs exist in specific individual JIRA projects. As a result, most teams set themselves up with a new JIRA project and work out of that.

This makes things a little difficult, especially for some scaling Agile frameworks such as LeSS (Large Scale Scrum) or Nexus, where having multiple teams operating out of single backlogs is demanded.

There’s a hidden, lesser-known feature in JIRA software that when switched on will enable this kind of operational behaviour and allow several teams to operate out of a single JIRA project.

It’s done by enabling something called parallel sprints in JIRA. To do this you need to have the ‘JIRA Administrators’ global permission.

This JIRA Software knowledge base article explains the simple process to enable parallel sprints.

Screen Shot 2018-10-16 at 3.50.07 pm.png

There appears to be a couple of gotchas, though…

The article explains:

Please note the following caveats when using Parallel Sprints:

The Velocity Chart will not show the velocity per team.

The current implementation assumes that the teams perform estimation identically, which is unlikely in practice.

These could be a deal breaker for some, but there could be workarounds.

I’m not quite sure what the second point refers to. I know JIRA can have story points or time as the estimation unit, so it could be related to that. If it’s in regard to teams and their different considerations of how much effort a story point represents, that makes sense, but I’m keen to see what this looks like in practice.

Velocity charts can be generated manually if needed.

Useful to know if you find yourself with multiple teams needing to work out of a single Backlog using JIRA Software. I’m writing this as a prompt for myself as much as it is for anyone else… ;)


The 7th Principle as a *drop the mic* moment...

I was chatting with my good friend, colleague and agile-coaching-expert, Craig Smith, the other day. It was a wide-ranging discussion as part of a debrief following a long term assignment with a client.

For whatever reason the conversation weaved its way to a discussion about the Agile Manifesto and how to best remember it. I have another post coming on that soon, but there was one principle that Craig referred to as a ‘drop the mic’ moment for him and what he described has really made it stick for me, too.

I think he’s mentioned it a bunch of times in his presentations (which are excellent BTW)…

This one.

7. Working Software is the primary measure of success

The 7th principle of the Agile Manifesto - really is the essence of it all. All of the other stuff is great, and yes, its all important and we should follow the other stuff too, but this is what it’s all about. Agile is not about merely about doing things differently and working in different ways, it’s about doing things differently in order to do what we are supposed to be doing - and doing that thing better.

If we are not measuring ourselves against this critical yardstick, we’ve got it all wrong.

It’s easy to get caught up in all the patterns, events (I can’t bring myself to use the terms rituals or ceremonies any more), practices and more, but ultimately are we building our software (or whatever it is we are paid to do) better than before?

This has really resonated for me and has become sticky in my mind. I hope it will for you.

So. Working Software is our primary measure of success. That’s what counts.

*mic drop*


obama mic drop.gif