Wednesday, October 14

No Talk, No Topic and No Notice - How to Host a Meeting at the Last Minute

attended the Agile Product Owners and Business Analysts Meetup Group last night.

The presenter cancelled at the last minute. Since I was the only co-organiser present, I stepped in to run the session.

Since I did not have a presentation prepared I took a leaf out of the Unconference playbook and sourced the topic material from the audience.

I wheeled out the whiteboard and we brainstormed topics that the attendees wanted to talk about. Then we dot voted on the captured topics and two of them received most of the votes.

Everything is High Priority
Distributed Agile

Everything is High Priority

This seems to be a universal experience. Almost everyone has dealt with bosses, stakeholders, or customers who refuse to prioritise.

Most of the solutions shared by attendees focused on avoiding the idea of priorities altogether. Some of the strategies included:

Using Ranking – Forcing a strict order without allowing ties in priority.
Using Defaults – Proposing your own priority order and proceeding with it unless you receive feedback.
Using Business Value – Prioritising based on estimated business impact.
Using Business Value divided by Estimated Time – To identify “low-hanging fruit.”
Using Risk – Prioritising items that carry the most uncertainty or unknowns.
Controlling the size of the backlog – Keeping the ranked list small and manageable.

Distributed Agile

Many attendees had experience working in distributed teams.

The most common challenge was dealing with time zones—especially when working hours didn’t overlap or had only minimal overlap.

There was general agreement that a digital Kanban board (or similar tool) was essential for tracking work.

Attendees also felt that occasional face-to-face contact was important.

Sharing the burden of after-hours meetings fairly was another key point, to ensure no sub-team felt like second-class members.

It was also noted that all sub-teams must clearly understand both the Agile process and the reasons behind it. Otherwise, there’s a risk of Agile being seen as just another management trend, especially if it’s imposed top-down without proper context or explanation.

Alternatives to the Standard Presentation
Melbourne User Groups
Common Complaints heard at the Scrum User Group Meeting
Online Resources

Tuesday, October 13

Zen, Improv Theatre and Responding to Change

teve Mitchell conducted a very interesting and useful session at Agile Coaching Circles last night.

I experienced Steve's workshops before at LAST Conference 2013. Along with the session on visual communication his session was the most memorable workshop at that conference. I have certainly obtained a lot of mileage out of those workshops over the years. I have used them on software teams to increase mindfulness and creativity, at my toastmasters club as an ice breaker and on my children as a fun bonding activity.

Steve's workshops are an interesting blend of Improv Theatre, Mindfulness Training, Divergent Thinking Training and Buddhist Philosophy. With one exception the exercises Steve taught were different from the ones I learnt before.

He started off with a spatial awareness meditation to help get us in the mood and shake off the cares of the day.

When I have used Steve's exercises on client's before I haven't incorporated his Eastern Philosophy, however after the session last night I am starting to think that was a missed opportunity. The Buddhist religion has surprising synergy with Change Management as its core principle is the need to be open to change, that all suffering is caused by resistance to change, by attachment to the Status Quo and our own Imagined Future. I probably won't mention to my clients that elements of what I am teaching come from Buddhist Philosophy. Steve certainly didn't mention Buddhism during the session, I was only aware of the origin of some of the ideas from other sources. Mindfulness, of course, comes directly from Buddhism, even though listening to Western Psychologists and Business Gurus, you would think they invented it.

It was a refreshing change to attend a workshop that was so active. This active participation is one of the reasons I find Steve's exercises so valuable. Instead of passively receiving the wisdom of the presenter the attendees are constantly engaged participants in their own learning. Even small workgroup sessions are not this active.

Instead of teaching us how to convince others how to accept change, Steve taught us to be more open to change, by both, teaching us by example, and teaching us that change begins with us.

Monday, October 12

Common Complaints heard at the Scrum User Group Meeting

t September's Scrum User Group meeting, we split into six workgroups of about six people each. Our goal: discuss issues outside our immediate sphere of control — the kinds of problems that don’t usually make it into a retrospective because they’re considered “out of scope.”

That said, I’ve seen most of these issues pop up in my own team retrospectives over the years.

Identifying the Problems

The first half of the session was devoted to surfacing pain points. Each group wrote their issues on cards, which were then displayed for everyone to read.

Here’s what struck me: the problems were remarkably similar. In fact, when it came time to choose a card to work on in a second group, I couldn’t even tell which one came from my original team. I picked one at random and joined a new group to brainstorm solutions.

The top issues we explored were:

1. Constantly Changing Requirements

Most people wanted to freeze requirements or at least funnel and manage communications more tightly.

Interestingly, the Aconex Project Manager in the room strongly opposed freezing the backlog mid-sprint. I tend to agree — I wouldn’t freeze the backlog entirely, but if sprint items changed radically, I’d consider restarting the sprint. Teams need some stability to deliver well.

My own approach is to increase stakeholder communication — not limit it — but make those conversations more concrete. That means design mockups, paper prototypes, mocked-up screens with fake data, and partially functional prototypes to align expectations early.

2. Changing Direction and Losing Focus

There’s always a tension between staying focused and staying adaptable. Personally, I’d rather lose a bit of sunk cost than deliver something nobody will use.

If stakeholders can’t provide a clear, consistent vision, I’m not afraid to roll back into the discovery phase. The biggest trap is starting to code too soon. In early inception, I prefer whiteboards, flip charts, and pen-and-paper sketches — even resisting the temptation to jump into Illustrator or Photoshop. Hand-drawn designs make it easier to build consensus without locking into premature details.

While Scrum advises against interfering with the sprint backlog mid-sprint, in practice, backlog items often evolve. The card that moves from “To Do” to “Done” may represent a slightly different task by the end of the sprint than it did at the start.

3. Interruptions

One solution that is often proposed is placing a gatekeeper between the development team and the stakeholders. Statistics and studies are often cited that show the high cost of context switching and the frequency of interruptions in the modern workplace. However the gatekeeper usually becomes a bottleneck. Communication suffers and is distorted as gatekeeper re-interprets and re-phases the information according to her understanding and experience which is often different from both the development team's and the stakeholder's. Most teams suffer problems because of lack of communication and a gatekeeper's job is to reduce communication.

My solution would be to setup cadences of set times to to co-ordinate or ask for assistance and have the team come up with their own protocols on how and when to interrupt. Often it is we, that interrupt ourselves. So turning off toast and only checking email and messages at set intervals can help.

Often the cost of changes and interruptions fall unevenly on the team overloading your knowledge keepers, your specialists. Shifting your highest performers to coaching and training the other members of the team will mean loss of inefficiency, productivity and poorer quality in the short to medium term. Yet failing to do so, can lead to them being overloaded, becoming bottlenecks, and risking knowledge loss when they leave.

Other Issues We Discussed

Unsurprisingly the Convenor / Moderator / Event Organiser Craig Brown picked up on the similarities in topics workgroups focused on, as well. There was a discussion at the end where the themes of the night were elaborated and possible solutions shared.

More Information

Articles

Monday, October 5

Pencil and Paper Battleships – The Burns Family Edition

t was school holidays, and I wanted to spend some quality time with my daughters. I remembered how much fun I used to have playing Pencil and Paper Battleships with my brothers when we were kids. So, I went online to find a version of the game we used to play—but none of what I found matched my memories.

So I recreated the game from scratch, based on how we played it all those years ago. I put together a few game sheets, and to my delight, they were a big hit with my daughters.

To this day, I’m not sure whether my brothers and I invented these rules ourselves or adapted them from somewhere else. If any kind reader recognizes this version or knows where it might have originated, I’d love to hear from you.

Burns Family Rules for Battleship

Each player uses a game sheet with a grid labeled “Your Ships” and a corresponding “Opponent’s Ships” grid.

Unit Placement

Players begin by placing the following battle units on their “Your Ships” grid:

Units can be rotated or flipped in any direction.
Units must not be placed diagonally.
There must be at least a one-square gap between all units—orthogonally and diagonally.

There are three types of units, each with placement rules:

These ships must be placed in ocean squares on the grid.

These air units can be placed on any squares on the grid.

These ground units must be placed on land squares on the grid.

Refer to the unit tally boxes on each particular map to see how many of each to place. Tick them off as you go.

Taking Turns

Once all units are placed, players take turns firing shots to locate and destroy the opponent’s units.

Standard Attack:

Announce a grid location (e.g., “B4”).
Your opponent replies with:
- “Miss” – if there’s nothing there.
- “Hit” – if part of a unit is located at that square.
Mark your “Opponent’s Ships” grid with:
- A slash ( / ) for a miss.
- A cross ( X ) for a hit.
When all squares of a unit are hit, your opponent must announce the unit’s name (e.g., “Cruiser destroyed”). Cross it off in the tally box.

Mega Bomb (Special Move):

Announce a target square.
The bomb hits that square plus all eight adjacent squares (the surrounding 3x3 area).
Your opponent announces:
- Any hits, along with their locations.
- Names of any destroyed units.
Record the use of a mega bomb by marking an ‘M’ in the tally box.

Winning the Game:

The first player to destroy all of their opponent’s units wins. names of any ‘Ships’ destroyed. Cross out an ‘M’ tally box each time you use a bomb.

Update :

I keep getting feedback that people want quicker games so I added some more small maps and re-did the letter code sizes.

Jagged Coast SS

The maps go from small small to extra large

Jagged Coast XL

Update 2 :

I added a interactive game down the bottom so people could try out the different maps.

Game Sheets

Demo of Maps

Geoff's Battleship

Seek Mode

Choose a Map:

Hunt Mode:

Enemy Waters

Click On Square To Fire

Single Shot Mode

Tally Boxes

Shots: 0

Sunk: 0 / 8

Software Team Sociology