Everything is High Priority and Distributed Agile

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

The facilitator cancelled at the last minute. Since I was the only Co-Organiser at the meeting I stepped up and ran the session.

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.

1. Everything is High Priority 
2. Distributed Agile

Everything is High Priority 

It seems to be a universal experience. Almost everyone has come across bosses, stakeholders or customers who refuse to prioritise.

Most of the solutions generated by the attendees involved avoiding the concept of priorities altogether.

• Using Ranking (Not allowing items to have the same priority. Just using a ordered list.)
• Using Defaults (Telling them your best guess priority and telling them that unless you hear back from them you are going with that)
• Using Business Value.
• Using Business Value divided by Estimated Time of development.
• Using Risk (what are the elements that have the most unknowns)
• Controlling the size of the backlog / ranked list.

Distributed Agile

A large percentage of attendees had experience with distributed teams.

The issue that seemed to cause the most trouble was timezones and either non-overlapping business hours or where the overlap was small.

There was also agreement that some sort of digital Kanban Board or some other form of item tracking was vital.

Some face to face contact was also considered vital.

Sharing the pain of off-hour meetings and not letting one sub-team feel like second class team members was also mentioned.

Making sure that all sub-teams had a clear understanding of the process and a clear understanding of the reasons behind the process could be an issue. Credibility of the company could be an issue as there was a danger of Agile being seen as a business fad if it was enforced top down.