Allan Kelly's Blog, page 15

Practical tips or mindset change?

How many books on your bookshelves have a number in the title? Specifically a list of X things. Such books sell, blog posts of a similar ilk get read.

“50 specific ways to improve your programs”

“97 things every dog walker should know”

“10 practical things every Scrum Master should know”

“51 tips to improve your requirements”

Small, specific nuggets of information, best presented as a list and advertised as such. No grand unifying thesis, just “75 things”. The closest I have ever come to this was “Little Book of Requirements and User Stories” which was my best seller and would have sold more if I had called it “16 tips to improve your User Stories.”

However, most of my books aren’t like that. Most of my books contain a big idea – at least one big idea. The whole book sets out to explain that. Business Patterns does say “38 Business strategy patterns” but really the books big idea was “Apply pattern thinking to business strategy”. In retrospect it would have sold better if I had called the book “38 Business strategy patterns” and put the pattern thinking stuff as an appendix.

Regular readers might notice that my blogs follow a similar pattern: mostly long thoughtful pieces which try to build an argument, few practical posts thrown in once in a while. Despite knowing I should write more short practical pieces (to boost readership) I keep failing.

Why?

Two reasons.

Sometimes those “short practical tips” seem so trivial, or so obvious, that I just assume everyone does it that way and everyone sees what I see. They are so small and so “obvious” I don’t see them.

But more because I see value in those long pieces. I see them as “philosophy” pieces, they are about how to see the world, how to comprehend what is going on, sense-making. Quite often I will wrestle with balancing forces, how one force pushed you one way while another pushes you another. The right course of action is about balancing those forces and what is “right” may be different at different times. (Thats a pattern thing.)

It might be better if I called those “Mindset” pieces. They are about preparing the mind to see the world in a particular way. Conditioning you for agile, perhaps.

To me those Mindset pieces are more important because they shape the way you respond. In the complex world in which we live few decisions and few courses of action can actually be boiled down to a simple “If this Then do That”. Instead, the thousands of small decisions you make each day are informed by your mindset (philosophy) of how the world works and what will happen if you make decision X instead of decision Y.

Especially for those working in management, it is your mental view of the world that shapes your decisions and relationships. I’m sure somewhere out there is a “50 practical tips for better management decisions” book but in truth there are so many variables, unknowns and ambiguities that you can’t boil the world down like that.

Thats why, while everyone is short of time and wants “10 practical tips” to fix a problem right now it is more important to spend time really challenging your own thinking. Change can only really become permanent when people change their actions and decisions without thinking each time, when people can make decision #563 today congruently to everything else not because they read it in book but because that is the way their mind works.

Our constant search for “quick answers” can mislead us, we might get a quick answer but we aren’t necessarily building our long term capability.

In Succeeding with OKRs in Agile, I tried hard to write a hands-on-practical tips book. I failed but in failing I did better than I would have done without trying. I very deliberately kept the opening chapters short and quickly moved into “practical tips” (mainly about writing OKRs). Almost all the mindset philosophy was pushed later in the book. So far sales suggest I got it right.

So, even as I strive this year to write more “10 practical tips” blog posts I expect I’ll have more philosophy as I put the world to rights!

Subscribe and download Continuous Digital for free

The post Practical tips or mindset change? appeared first on Allan Kelly.

Team Retrospective cards are back, and better than before

Team Retrospective cards are back on sale

Agile Stationary have given retrospective cards a new home and are handling all the sales and logistics. That means everything should be slicker and export to anywhere in the world should be hassle free.

Agile Stationary gave the cards another print run and in the process enlarged the cards slightly. So while they can still fit in your pocket they are a bit easier to handle.

To mark the occasion Agile Stationary are offering a 20% discount to blog readers, use the code TEAMRETRO20.

Subscribe to my blog newsletter and download

Continuous Digital for free

The post Team Retrospective cards are back, and better than before appeared first on Allan Kelly.

Can you keep Agile and OKRs seperate?

“I’ve been told to keep agile and OKRs separate”

The first time I head this I was surprised, “missed opportunity” I thought but then, as I thought about it more, the more I realised that it was impossible.

Start with the OKRs: OKRs are about deciding what to put your time and energy into. OKRs are about the big priorities for your organization and team. The more I’ve spent time with OKRs, the more I’ve come to see them as the management method rather than a management method among many. Let me caveat that lest it sound arrogate: management within an organization.

The management approach

There are many management approaches out there: strict time-and-motion were workers time is schedule to the minute by experts; complete devolution giving employees free rein and managers (if they exist at all) only exist to coach. And there is everything in between, including project management which attempts to define the start and stop dates in advance. At this level OKRs are one management approach among many and organizations are free to choose which they follow.

Even combining traditional HR performance review processes with OKRs can lead to ruin. Once compensation is conected to OKRs people become incentivised to stay safe by setting OKRs which bring rewards, i.e. not ambitions ones that might be missed.

Running any other management method in tandem with OKRs risks jeopardising both. So if you choose OKR then follow it all the way, call it “Extreme OKRs” if you like.

Just try imaging agile as something separate to your OKRs: you set OKRs and then you run iterations. What are you delivering in the iteration? Surely iterations are delivering progress against OKRs?

I suppose you could have a backlog of work to do (Track A) and some OKRs to work on as well (Track B). Track A and B might lead to different places or represent different work to do. Leave aside potential conflict for a minute, think about how you divide your time.

More WIP, fewer results

Agile teaches that work in progress should be minimised, but now in this example there are two sanctioned work streams. Maybe we could ring-fence work: Agile in the morning, OKRs in the afternoon. I find it hard to see that working well.

Maybe A could be the main stream and B other a “best efforts” / “spare time” stream. But, if both A and B are important then why leave prioritisation be left to the worker? It smells a bit of leadership abdicating responsibility for prioritisation.

It is a fantasy to think that workers can focus on delivering the backlog and in their “spare time” deliver the OKRs. If your workers have copious amounts of spare time then something else is seriously wrong. It is easy to overload workers, and thereby create problems further down the line. People will burn out, goals will be missed or goals are met but with such poor quality that problems emerge later.

I can see how you can run OKRs without agile.

And I’ve long seen Agile working without OKRs.

But if you have both Agile and OKRs in the same company I just don’t see how Agile and OKRs can be separated. Conversely I can see how they can work well together – yes, I wrote a book on that.

If you are going to have OKRs and Agile in the same company then you need to consider them as one thing, not as two separate endeavours.

Photo by Jackson Simmer on Unsplash

Subscribe to my blog newsletter and download Continuous Digital for free

The post Can you keep Agile and OKRs seperate? appeared first on Allan Kelly.

Signing off 2021 and Not rolling over

“The decision about what to abandon is by far the most important and most neglected. … No organization which purposefully and systematically abandons the unproductive and obsolete ever wants for opportunities.”

Peter Drucker, Age of Discontinuity

I’m writing this on the last day of 2021 and for once I am confident in predicting that next year will be better than the one that is ending. Like most people I have a few routines I follow around this year and one of these relates specifically to this blog.

I often get asked: how do you get ideas for your blog?

The truth is I have too many ideas for this blog, right now I have 18 ideas for blog posts that are part written. That might be as little as a title, or a completely written post I haven’t editted yet – plus there is one entry I wrote and decided it was for me alone. When I have an idea for a post I just add an entry into my blog list, normally that would be a title and few bullet points. Sometimes it is just a title, occasionally I just type the whole thing as a stream.

These entries will not be rolled over for 2022. In fact, I just deleted 7 after writing that last paragaph. The remaining 11 will be folded up and put to one side in the MacJournal software I use for blogging. I have already created a 2022 folder for next year.

It is a bit like buying a daily newspaper, once the day is gone there is rarely any point to going back to read the bits you missed. Tomorrow is a new day with a new newspaper, new priorities and new things to read.

In order the have new ideas one must make space for new ideas, and that means throwing away ideas which have not be able to win the competition for attention to date. This idea is embedded in my thinking when I recommend teams using OKRs throw away their backlog. It is why I like Jeff Bezos’ “Everyday is Day-1” thinking.

Don’t get weighed down by yesterday’s good ideas, if they are really good ideas they will appear again. If not then removing them will make space for better ideas. Plus, by practicing new ideas you will get better at new ideas.

More importantly: throwing away those ideas and work-in-progress forces one to think about what is really important, what really will make difference and move you forward. Dispensing with the day-to-day trivial allows one to think big.

In truth, while I just irrevocably deleted seven potential blog entries the other 11 will not be lost for ever. They will just be hidden. If I am stuck in a few months time I know where they are – but for that matter, I could equally fish in the unused entries from 2020, 2019, 2018… And in complete honesty, there are two early drafts already in the 2022 folder that I’m keen to write.

So while I say, and I advise you to: “Throw away the backlog” I have no objection to someone keeping (some of) those good ideas in a bottom draw as long as a) nobody pretends they might be done one day, b) they do not distract from your focus on the important things.

Finally, if I am to think big for the next year what would I like this blog to carry? – in other words, what might you expect?

Top of the list is to focus on OKRs: I’ve been blown away by the interest since I published “Succeeding with OKRs in Agile” and I know a lot of people are wrestling with OKRs with agile.

I’d also like to focus myself on “small practical bits”. I know I have a tendency to be “philosophical” – in part that is because I believe that our “philosophy” informs our daily actions and decisions, and the pattern of those decisions, far more, and for far longer, than any given list of “10 things you should …” But I also know, readers – and book buyers! – like “small practical bits” so commercially I should do more of those.

Subscribe to my blog newsletter and download Continuous Digital for free

The post Signing off 2021 and Not rolling over appeared first on Allan Kelly.

Top agile books which aren’t about agile or software

Christmas is almost here and the end of the year is nye. That means it is time for newspapers and journals to start publishing “Top books of the year” lists and “Christmas recommendations.” So, prompted by a recent thread on LinkedIn I thought I’d offer up my own book list: top books for agile folk from outside of agile (and software).

That is: books which are not explicitly about agile (or software development) but which contain a valuable message, and possibly techniques for those wanting to expand their knowledge of, well, agile.

Most of the books I’m about to list address philosophical, or mindset, underpinnings of agile: how to think in an agile way, rather than “how to do agile.” That might disappoint but think about it, how could a book from outside agile tell you how to do agile?

Well, actually, there are three which do.

First The Goal: written in the style of a novel this book explores the theory of constraints and elementary queuing theory, without mentioning either by name. Since it is written as a novel – with characters and back story! – this is an easy read. But please, don’t judge it as a novel, judge it for the message inside.

Next up is The 7 Habits of Highly Effective People: I blogged a few months ago how these habits could also underpin a team working style. Whether you read this for yourself or with an eye on your team this book does contain actionable advice – and some ideas on how to think. It can be a bit of a cringe in places and I’m not sure I agree with all the ideas but it is still a worthwhile read.

Finally in this section is a book at the opposite end of readability: Factory Physics.

Make no mistake this is a text book so it sets out to teach and can be hard going in places – there are plenty of equations. But, if it is a solid grounding in queuing theory, variability, lead times and the like you want then this is the book to go to. In fact, it might be the only book.

That is it for hands on books which will tell you how to do things on Monday morning. The books which are ones I consider “philosophy” – how to think. Thats my way of putting it, a more popular way of putting it is: Mindset. These are books which have shaped my thinking, my mindset, and as such underpin my approach to all things agile – and more!

First here is The Fifth Discipline. This may be the founding text in the field of organizaional learning, ultimately all agile learning and applying that learning. The “learning view” underpinned my own first book and that still fundamentally shapes my approach to working with individuals, teams and companies.

My next choice continues the organizational learning theme and is the source of perhaps the most famous quote from the that field:

“We understand that the only competitive advantage the company of the future will have is its managers’ ability to learn faster than then their competitors.”

The Living Company presents an alternative view of companies and organizations: rather than being rational profit maximising entities this book encourages you to see companies as living organisms. As such the organizations true goal is to live and continue living. Trade, and even profit, is simply a means to an end. And like all successful living things companies must learn and adapt, those that don’t will die.

Living Company is not alone in presenting an alternative narrative of how companies work. My penultimate book presents an alternative view of that most sacred of management practices: strategy.

The Rise and Fall of Strategic Planning is a major work that not only charts the historical rise of strategic planning and the subsequent fall it also present an alternative view of what strategy is and how companies come by strategies: strategy is a consistent pattern of behaviour, strategy is part plan but is also emergent and changes in respect to what happens. Strategy claims to be forward looking but is equally retrospective, strategy offers a story to link past events together.

Along the way Rise and Fall accidentally explains where the waterfall comes from (Robert McNamara), how planning is controlling and why even with almost unlimited resources (GE and Gosplan) the best attempts at planning have failed. If you harbour any ambition to implement Scrum at the corporate level make sure you read this book.

All the books above are over 10 years old and had I written this list 10 years ago it would probably be the same. But two years ago I read Grow the Pie, this advances the discussion of why companies exist and how to be a successful company – the secret is to have purpose and benefit society. Written before the pandemic it is now more relevant than ever. Again it isn’t an easy read but it pays back in thoroughness of argument and reasoning. And if for no other reason, read Grow the Pie to really understand what constitutes value.

Subscribe to my blog newsletter and download Continuous Digital for free

The post Top agile books which aren’t about agile or software appeared first on Allan Kelly.

BA role in agile discovery

Adrian Reed of BlackMetric ran a webinar panel discussion last night with myself, Angela Wick, Angie Doyle and Howard Podeswa and myself last night about the Business Analyst role in Agile discovery. The discussion was great fun and Adrian has now made the recording available on YouTube.

This is not the first time I’ve appeared in one of Adrian’s webinars, at a minimum I recommend keeping your eye on his upcoming subjects as he regularly has great guests.

Subscribe to my blog newsletter and download Continuous Digital for free

The post BA role in agile discovery appeared first on Allan Kelly.

OKRs and Agile

“How to combine OKRs and Agile” is a short piece by my published on the GTM Hub blog. GTM Hub is the provider of OKR software.

As it happens another OKR software provider Just 3 Things has been running a series on OKRs which I and over 20 others contributed too. This series takes a question and answer form. The latest instalment is Questions you should ask before starting your OKR journey, previous posts include:

• OKR predictions for the next 5 years

• Common OKR mistakes

• Advice for OKR champtions

• Benefits of OKRs for companies and employees

• Cultural and structural similarities at companies that create great OKRs

And of course, if you like these subjects you will enjoy “Succeeding with OKRs in Agile.“

The post OKRs and Agile appeared first on Allan Kelly.

A company is not a tree: an alternative map

It seems that everyone dislikes hierarchy in organizations. Even the people at the top of the hierarchy seem to want to get away from the idea. But… the moment we start talking about organizations everyone starts talking about who’s at the top, the CEO, and who reports to who. Try to draw it out and you end up with some sort of inverted tree.

Part of the problem is that we all want, indeed need, structure. Saying “there is a bunch of people” isn’t enough. We need some way of understanding who is who and where they all fit in. Perhaps we cling to hierarchy because we lack a better model to conceptualise our organizations and who they fit together.

Programmers and business designers aren’t the only ones who want to think of things in a neat tree like hierarchies. I was recently introduced to Christopher Alexander’s essay “A city is not a tree” in which he rails against the same idea. Living in London and I while I could imagine constructing a hierarchy on some criteria I immediately know it would be wrong. It would not capture the true nature of London. Neither Oxford Street or Threadneedle Street are at the top, they would be contenders but in different way. Each part place places multiple roles. There isn’t one centre, there are many centres.

Maps help use make sense of places like London but even here we use different maps with different conventions depending on what we want to do: the Tube map is very different to a visitors map which is different to a map of boroughs, we use different maps for different things. And maps shape our thinking and action – consider the Google map of central London with selective information trying to be useful but also trying to s ell things.

We need maps of our organizations to understand them but in drawing the map we shape our thinking. If we want to move away from hierarchical thinking we need another way of mapping our organizations.

So let me suggest a different way of thinking about an organization, a way I find useful, a way I briefly mention in my “Reawakening Agile with OKRs” presentation: concentric circles – think of it as our solar system with plants (teams) orbiting the sun (leadership.)

Rather than think of your supreme leader at the top of an organization with everyone else below them – an idea that just shouts “inferior” – think of the supreme leader as the centre of the organization. After all, everyone in the company has a relationship with that person even if relationship with them in the same way that every asteroid in the solar system has a relationship with the sun.

The sun, the leader, exerts a force on everything, everyone, else. Some people are close to the centre and close to the leader – they feel a lot of the leaders force. Others are far away, some are so remote the leader struggles to exert any influence.

And while I say “leader” it might be better to think about the leadership team. Close in there isn’t just one leader, even here leadership is split between a CEO, CFO, and even the board. Nobody has total authority, everyone needs to work with others.

You might also add on the communication paths, some teams communicate with other teams a lot, and some teams hardly at all.

Like the solar system there are alternative centres. Earth has but one Moon, that is influenced by the sun but Earth is a far bigger influence. Jupiter has dozens of moons and exerts a lot more influence on its moons than the sun does. Thats not unlike the way some teams and leaders operate.

These satellites influence each other too – maybe not something astronomers see much but some teams follow similar orbits to others and can influence them. Imagine Mars came close enough to Earth at times to influence the seas the way the moon did – even if they only occurred occasionally it would be meaningful. In a company some teams influence others, one team uses the work of another, or they serve the same customers, or the can disrupt the other.

If we are to navigate our organizations without repeatedly referring to tops and bottoms, ups and down, superiors and inferiors, then we need to start changing the models we use to guide us.

This view might also answer another question I raised a few years ago. In Programmers Rorschach Test I noted that organizational charts look exactly like the structure charts I was taught at University. These were an alternative to flow-charts for structured programming in Pascal like languages.

Think about that: organizational design looks exactly like structured programming: Conway’s Law again.

So what does Object Oriented programming look like? Perhaps the solar system provides an answer: lots of independent objects following their own paths but exerting forces on others.

Add asteroids, comets and dwarf planets to planets and moons and you have plenty of ideas to model with.

Subscribe to my blog newsletter and download Continuous Digital for free

The post A company is not a tree: an alternative map appeared first on Allan Kelly.

What are the first steps in setting OKRs?

“What do you see as the first steps in setting OKRs?”

After delivering my “Reawakening Agile with OKRs” presentation to an internal company group the other day and got this question as a follow up afterwards. As I thought it would be worth sharing my reply with more readers, which is also an opportunity to expand my thinking.

First we need to make some assumptions and decide policies.

I’m going to assume that the team know what OKRs are, why they are being introduced and what is expected of them in setting OKRs. So, if this assumption does not hold true then before you set the OKRs establish some shared understanding on these points. Perhaps get an introduction to OKRs for the team. (I’ve started work on another video tutorial series, an introduction to OKRs and agile.) Next get some guidance from those suggesting the team use OKRs on what they expect.

I’m sorry to say I hear of plenty of cases were these things don’t happen. Teams are told: “thou shalt use OKRs.”

It would also help if those suggesting OKRs have spelt out what they see as success (100% of OKRs complete? 70%? Or, as I prefer: benefit delivered.) But you know what? If you don’t know this you can clarify it later, nice to know in advance but in a pinch, not essential.

Next I suggest Think Team – I’m skeptical about individual OKRs so don’t set OKRs on anything smaller than a team level. While it might help if the “next level up” set OKRs first if the team start first then the team clearly own the OKRs. So, while there are advantages to knowing the priorities higher up there are also advantages to taking the initiative.

If you want to set some kind of individual objectives then my advice is: wait while you learn. Get some experience at the team level with OKRs before thinking about individual goals. Or perhaps, for the first two quarters make everyone’s individual goal “learn how to work with OKRs by working with OKRs.”

It will also help if you have some idea of how your OKRs are going to line up against any backlog you have. Are the OKRs reverse engineered from the backlog? Or do the OKRs have priority over the backlog? Or, as I suggest, use OKRs as a story generating machine instead of having a backlog?

Similarly, if you team needs to “keep the lights on” and do “business as usual” stuff in addition to OKRs you need to know in advance. That will soak up capacity. So how do you reflect that in your OKRs? – in Succeeding with OKRs in Agile I suggest a OKR-Zero for this type of stuff.

Now to set OKRs I suggest at least two meetings – and preferably not too many more. The first meeting is a drafting meeting. You might think of it as a big brainstorm. Get ideas out on the table, talk about priorities. Aim to get a rough draft of some candidate OKRs.

Before that first drafting meeting someone – Team Leader, Manager, Scrum Master, Agile Coach, whoever – needs to confirm what the timeline is. Are the OKRs to run over 13 weeks? – or is it Christmas so this a 15 week quarter? Or maybe you only have 10 weeks this time. The deadlines are important. Don’t plan OKRs without knowing when the first and last days of the cycle are.

It helps if team members have given a little pre-thought to what they would like to see in the OKRs. Now I don’t want a lot of pre-work. And I especially don’t want lots of planning because that a) detracts from they current cycle and b) potentially limits ambition when setting the OKRs. Still a little forethought – think of it like writing your Christmas list.

This suggestion is particularly important to the Product Owner. Since team team are aiming to delivery benefits to others (customers, users, stakeholder, whoever) it is natural that the Product Owner takes a lead in drafting meetings. Whatever title you give this person this is the person who is charged with listening to customer requests, understanding non-customer users, liaising with stakeholders and understanding the business/product strategy and knowing what would be beneficial to who. So it makes sense for this person to have plenty of ideas on what to do.

In the run up to OKR setting is Product Owners need to bring all their homework together and decide what outcomes they would like. The Product Owner needs to present this thinking to the team in OKRs setting and work with the other team members to craft OKRs which reflect those asks. Most importantly of all, they have to understand the implications when some items don’t make the cut.

Thus the Product Owner will walk into the OKR planning meeting with the longest Christmas wish-list of any team member. But they will not get everything on that list, far from it.

Once you have your draft OKRs take a break. At least an overnight break, or maybe a few days.

Do any more homework that is needed (e.g. check requests with customers, show draft to partner teams and managers for feedback, check availability or timelines of people or equipment that might expect to need, etc.)

The second meeting is there to firm up the draft. Ideally after some reflection and some homework everything in the draft looks good, all you need to do is tighten it up and declare it final.

But there is every chance your draft contained six desirable objectives and it needs some reflection and some homework before you can reduce it to three. It may also be that that homework turns up a problem, a priority that had not been appreciated or a block that wasn’t foreseen. In which case you need to revisit the draft.

Setting OKRs inevitably means making choice about what will be done and what will not be done. I’ve heard of teams who have “do not do” lists in parallel with OKRs. This is because OKRs implement strategy and if the strategy is lacking or unclear then OKRs will make that clear, and hopefully seed a conversation.

Enough for now. I hope you found that interesting. If anyone out there has any more questions about OKRs please let me know and I’ll see if I can answer them here.

Subscribe and download Continuous Digital for free

Child at steps in image Jukan Tateisi in Unsplash.

The post What are the first steps in setting OKRs? appeared first on Allan Kelly.

Why I worry about the future of conference speakers

I speak at a lot of conferences and meet-ups, too many. I shouldn’t complain I’ve got books to sell! I’ve also been involved in organizing many conferences – ACCU, EuroPLoP and Agile on the Beach for the last 10 years. There are some trends emerging which worry me and I want to record. So not my usual blog post but I hope this will interest a few people.

Now so many presentations are done remotely I can speak to groups all over the world, last week I spoke to an internal company group in Florida and a couple of months ago to a meet-up in Sydney. I say Florida and Sydney but the attendees were from all over the world, Florida was just the home of the company and Sydney were the group physically met before you-know-what happened.

Increasingly “big name” speakers – maybe me, certainly people bigger than me, people with serious book sales and name recognition in the tech/agile community – are turning up at local meetings and small conferences which are now online. That is good because these groups get to hear directly from people with big ideas.

But, the fact that the big names (and here I probably include myself) are speaking to such groups means others aren’t. In particular local people, new voices, people just starting on the speaking circuit or people who will probably only ever speak to a few events organised by people they know.

My worry is that as more events move online we are perpetuating the winner-take-all culture and making it harder for new people to get started.

Arguably that is offset by fact that more conferences are reviewing submissions anonymously. However I’m not sure anonymous review is a good thing. As a reviewer I normally have two pieces of information: the talk description and the bio of the submitter. I’m looking for an interesting talk and an interesting speaker. Without the bio I only have the talk description to go on. If I select a big name I know I’m selecting a name, when I’m reviewing someone I don’t know I think of them differently.

Consequently reviews are going to favour those who can write stronger, better, descriptions. It may be naturally talented writers, or those who have had the chance to hone the description over previous submissions and presentations. Again favouring the established speakers.

Adding to that is the fact that some speakers work for companies who will help them prepare talks and descriptions. This is more likely in consultancies – or those successful enough to pay for professional help. One comment I heard from conference attendees regularly is that they prefer to hear from non-consultants, those doing actual work, rather than consultants who may have a service to sell. (There are more consultants on the speaking circuit than non-consultants because they have more time and greater motivation to be seen speaking.)

So while well intentioned anonymous review may end up having the opposite effect of that intended.

Next I’m worried about the increased use of online submission systems which create a common pool of speakers – I’ve thought about this long and hard because I looked into this when developing Mimas years ago.

At first this looks great for speakers because they can easily submit too many different conferences. It is good for conferences too because it simplifies submission and increases the pool of speakers. But again this can back-fire.

I once shared a taxi with a speaker whose next conference was in South Africa. He had never heard of the conference but an online system prompted him to submit and guess what, he was accepted! Great but…

As a conference organizer I’ve had to manage over 300 submissions for less than 40 speaking slots. To do the submitters justice requires a lot of review work. A 1:8 ratio is extreme, most conferences it is closer to 1:3 or 1:4. How many conferences can do that?

The last year I ran Agile on the Beach reviews I had over 50 reviewers. That itself makes more work. How many conferences can handle that? Some conferences don’t even have that many attendees.

I used two review rounds, again more work.

And, to be honest, if I have 30 submissions to review, the one I review first will get more thought than the one I review last. Again those who can craft a good description are more likely to get through.

So, common, pooled, online submission systems will increase the number of speakers. Less work for speakers makes more work for organisers. Either conferences will need to invest more in reviewing work or they will end up taking the people they recognise when the cloak of anonymity is raised.

And how are new speakers to improve if they don’t get selected?

Very very few conferences give feedback on submissions to those who submit and are not selected. And as the number of submissions rises the work needed to give feedback also rises. (Particularly since raw comments from reviewers often contradict.)

(Perhaps the thing I am most proud of about Agile on the Beach is that I gave feedback to everyone who submitted. That came at a cost to the conference, and even more, at a cost to me. Ultimately I had to write Mimas to do what I wanted to do and that took a lot more work than I was ever prepared to admit to myself.)

Another side-effect of common submission systems is that conferences organisers have easy access to alternative speakers. There has always been a bottomless pit of people wanting to speak but now they are easy to find. This further reduces the speakers power to ask for travel costs, let alone actual payment. Few speakers get paid for speaking at conferences or meet-ups, with luck the organiser can pay travel costs. This already means those who are successful and can afford the time, and travel costs, are at an advantage. (And again favours consultants for whom speaking is marketing. Consultancies may actively encourage their people to speak, while work-a-day companies are frequently less than keen on employees taking time away from work.)

All-in-all I think well intentioned moves (online talks, anonymous review and pooled submmision platforms) are actually making it harder for new voices to get heard. As so often happens in technology the winners win more and a greater divide opens up.

I don’t know what the answers are. Maybe my concerns are misplaced. But I worry.

Subscribe to my blog newsletter and download Continuous Digital for free – normal price $9.99/£9.95/€9.95

The post Why I worry about the future of conference speakers appeared first on Allan Kelly.