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…

Farewell, Mungi…HELLO, Aussie Broadband!

Somewhat unexpectedly, my NBN FTTN provider, Mungi (or rather, their Administrators) shot all customers an email on Wednesday evening around 5:30pm explaining that the company had gone into receivership and that my NBN service would soon be terminated. Less than an hour later (while out at my daughter’s Oztag game) we were disconnected.

This put the house into a bit of a funk that evening, with the nearly-and-teenage kids upset as if the house was being starved of oxygen - desperately but unsuccessfully seeking satisfaction from non-online activities. The evening felt like it dragged on for days.

During this time, and as part of the advice from the Administrators, was a suggestion to seek broadband services from another of Australia’s most popular NBN providers, Aussie Broadband. So we lodged an application.


I had been meaning to cut over to AussieBB ever since Mungi deleted their 100/40 plans a few months back, reducing our (very capable for FTTN) connection to a mere 50/20. When NBN first became available in my area, I initially applied for service from AussieBB only to find they were upgrading some equipment meaning a delay of a few weeks. As we were feeling the sharp pain of a modest ADSL connection, we chose Mungi as they could connect us much more quickly, and were very happy with the service - until they folded and cut us off.

On Wednesday evening we promptly made an application with AussieBB - electing for the 100/40 service. We live a literal stones through from our closest node so we get good speeds, and Aussie were offering us a discounted service ($20 off) for the first six months as previous Mungi customers.

Shortly after applying - 10-15 minutes - we began receiving welcome texts and emails and other advice about our pending service connection. Fortunately, with FTTN connections (and potentially other types of NBN service...) migration from one provider to another is quick and painless. Our last email (by about 7:30pm) explained we should await an SMS and email confirming the cutover of our service. We heard nothing further that evening and so each had an earlier night.

AussieBB uses a different method of authentication relative to any other broadband provider I have ever used, in that there are NO account details - no username or password - to be added into the router. Authentication happens based on the physical line itself. This makes router/modem reconfiguration super simple - just delete the old credentials for Mungi and adjust the WAN authentication settings to Dynamic or Automatic IP.

By 5am the next day, I received an invoice. I logged on to the AussieBB dashboard and could see an active service. We hadn’t received the confirmation email or text, but according to AussieBB reps on this super-helpful Whirlpool thread, if we had received an invoice our service was active. I jumped into my ASUS router and changed the config as above and 2 minutes later we were up and running. Once again there were smiles restored across the household…

All in all, I’m incredibly impressed so far with AussieBB. I’m especially impressed with their responsiveness to a no doubt enormous influx of customers, all desperately flailing with a promptly disconnected service. I should also reiterate that ALL work from go to whoa was completed in less than 10 hours overnight and entirely outside of normal business hours. You don’t get that often from anyone.

Speed-wise, we’re also thrilled. For our 100/40 connection we get excellent speeds. Not only is the service fast, but it feels snappier (lower latency) and more responsive than before, too. I just received another email from Aussie explaining they’ve done some line tests showing the service is actually capable of 113Mbps, but I think we’re content with this: :)

Screen Shot 2018-11-23 at 9.41.41 am.png

So. Do I recommend, Aussie Broadband? Hell, yeah! If you’re looking for excellent customer service, speed, no contract lock-in (assuming BYO modem) and all from an Australian company, look no further. HIGHLY recommended.

PS. Oh… and if you’re interested in a $50 discount follow this link - we’ll both get a credit. Cheers!

Velocity and Capacity considerations for Sprint Planning

Velocity and Capacity are both critical metrics to consider in Sprint Planning.  As a reminder...

  • Velocity is a running average of the amount of user story points a team manages to achieve in its sprints - a historical view of what has happened

  • Capacity is a way of forecasting the team's availability (in the future) to work on stories in the upcoming sprint(s). Capacity is measured in time.

Capacity is affected by activities which can be represented as overhead - fixed and variable.

  • Fixed overhead represents the routine activities that the team members must be involved in sprint to sprint - such as Sprint Planning, Daily Standups, Backlog Refinement, Showcases/Sprint Reviews and Retrospectives and preparation for those activities. This can be considered as 'Scrum overhead'.  All of those activities take time and for a typical team using Scrum that adds up to around 20-25% of each team member's time each week

  • Variable overhead describes other occasions - this might be team offsites, town hall meetings, holidays, workshops and other non-Scrum/non-user story related work which affect the teams availability to get stuff done

So...consider this example:

Let's say a team has 4 team members that do the actual story work each sprint.  The team works to a 2 week sprint cadence which represents 10 working days. A working day (for sake of easier calculations) is 8 hours long.  Let's also assume too, that the team has an average velocity of 64 story points per 2-week sprint.

So, the team's capacity (incorporating Fixed overhead) can be determined as follows:

4 (team members) x 10 (days) x 6 (hours ie. 8 hours less 25% in fixed overhead) = 240 hours of time

This is the team's Normal capacity - which describes the maximum time the team has available to work on delivering User Stories.

Now, for an upcoming sprint you then deduct any Variable overhead that you're aware of.  Eg. Steve is going to be on leave for one day (6 hours), and the whole team has a half day workshop (4 hours x 4 team members = 16 hours) for a total of 22 hours of Variable overhead.

The team's adjusted capacity for the next sprint is 240 hours (normal capacity) - 22 hours (variable overhead) = 218 hours adjusted capacity.

Now, armed with this information you can calculate expected velocity for the upcoming sprint.  You do so with the following simple formula:

Adjusted Capacity/Normal Capacity * Average story point velocity = Expected story point velocity

e.g 218/240 * 64 = 58.13 points

During Sprint Planning you'd then look to bring into your sprint backlog about 58 points of work for the upcoming sprint.


T-shaped people and broken combs

We talk a lot about Agile teams being cross-functional or multi-disciplinary, but in Agile we need to be careful that we encourage one type of team, and not the other, and that we understand the difference between the two terms.

So...what IS the difference?

In my opinion, A multi-disciplinary team (MDT) is a team made up of a group of people who hold different disciplines. People in multi-disciplinary teams tend to by I-shaped.  That is, they have a very deep expertise in a specific area, but much less breadth across other skill areas.


What Agile teams do best with is T-shaped people. T shaped people also have specialties - a strong depth of skill in a given area - but they also have skills (breadth) spread across other areas of the team's knowledge work, too.  Just like the uppercase 'T' - depth and breadth of knowledge.

In Agile teams, and especially in Scrum, cross-functional teams are critical to success. Cross-functional teams have all of the skills needed to get the work done, with plenty of skills overlapping to reduce the dependency on the skills and expertise of any one team member.  Work, and consequently the 'success' of the team, in Scrum, is the collective responsibility of all of the team members.  In a Scrum team all team members must collaborate and pull together to get the team over the line - so most team members should be able to muck in and assist with most of the tasks the team has before them.

The long term goal of Agile teams is actually to achieve something higher still.  Beyond T-shaped people there's discussion about the need for 'broken combs'...

Imagine the teeth of a broken comb with some teeth missing completely and others which are much shorter.  The comb's teeth represent skills/functions.

Pieces of broken combs have some breadth, but they also have some depth, to differing degrees, across a number of skill or functional areas. Imagine each person on the team being represented by a small piece of the comb...with a few full length 'teeth' and a few that they are developing.  Collect and assemble these different pieces together and you have enough overlap in skills to make a truly cross-functional team.

Agile teams therefore need T-shaped people or 'broken combs' to be truly cross-functional.  That is, each team member needs to be a 'generalising specialist' having skills across a variety of skill areas so that they can jump in, get the job done and collectively succeed in the Sprint goal.