Blog

Why does AOTB have its own submission system?

256px-Mimas_Cassini-2020-02-19-15-13.jpg

Anyone who has submitted to Agile on the Beach in the last few years will have used our submission system: Mimas. Like so many other conference we, or rather I, created our own system.

“Why does AOTB have its own submission system?”

Flippant but true answer: because nobody else (yet) has decided to share out system. I’m more than happy to host other conferences

Perhaps the actual question should be:

“Why create your own system when there are others out there?”

Yes, good question. Well, two (plus one) reasons really.

One: About five years ago when I got fed up of the Heath-Robinson combination of Excel sheets, Google sheets, HTML and a little Python that I was using nothing fitted. If I recall correctly Papercall was just started. While many commercial conference management systems had a synopsis module most of these didn’t do public call for papers and they cost money. I thought about using CyberChair/EasyChair but these are quite off-putting and needed hosting.

Things have changed a bit now so I might not make the same decision today.

Two: I was really very keen to give submitters feedback on their submissions and this was missing from most systems. This is an agile conference and agile is all about feedback so we should give feedback shouldn’t we?

Hillside’s Pasture can do this but is quite a niche system and I’m not sure it could handle the load we get. Similarly the Agile Alliance have a system for their conferences which gives feedback but having submitted I wasn’t impressed.

So that was then. What about today?

Having our own system has allowed us to do things we wanted: like a public review with over 50 reviewers this year. Or changing the voting system.

Of course that comes at a cost: my time to change the system, my stress in keeping the system up (a lot lately). O, there are some charges for the Google Cloud but these are trivial, a less than $1 a year and most of them are down to one report I run repeatedly during the review processes.

Those might be reasons for keeping Mimas but really my overhead should encourage me to kill it. Of course, I’ve grown to love my code and while I admit is stinks in places (the look of the UI) I’m proud of it.

But, the over whelming reason right now for not moving to Papercall (or similar) is: Speakers.

There are more speakers and potential speakers than conferences. Possibly the money to be made from a conference submission system is not from the conference organisers but from the speakers who want to submit to conferences. A bit like advertising the service could be provide for free to conference organizers if submitters paid a subscription.

And I have met speakers who tell me the go to Pepercall (or whatever) and submit to conference X. Then look down the list of other conferences they fancy and make the same submission multiple times. That is valuable to potential speakers.

But, that ease of submission is a problem for organizers. Particularly organizers who want to give feedback.

Easy submission for speakers means more work for reviewers.

As a conference organizer I don’t want every Tom, Dick and Harry submitting to my conference. AOTB already has about 300 submissions a year, and as I’ve noted before some of these smell as if the submitter really doesn’t know much about us and hasn’t thought through the submission.

The interests of speakers and organizers are not aligned.

One way of solving this problem would be for conferences to share reviews. So if a speaker submits, say, to AOTB and Agile Cambridge and Agile Alliance then each conference can see what others thought of the submission. I could imagine that working.

I can also see obstacles. First of all: data privacy.

More troublesome I wonder if that would actually make it more difficult for new speakers to break in. The same old hands, with the same good reviews, would come to dominate the conference circuit and new ideas wouldn’t get in.

So there you go. AOTB has its own submissions system and I’ll tell you more about that next time.

Notes on Agile on the Beach submissions

More notes on Agile on the Beach – this is going to go on all week, sorry but there is a lot to get on the record. Maybe only conference-geeks and those thinking of submitting to AOTB will find useful but I’d like to get it on the record and this is my blog 🙂

First off the Agile on the Beach is pretty much the same every year. Unfortunately it has grown over the years as we try and share more information with those submitting. I expect most conferences have the same problem.

Problem #1 the call for submissions is too big, problem #2 people don’t seem to read it. Actually, it is not just that people don’t read it but some people who submit don’t seem to know much about the conference.

The wrong track, Gromit

For example: lots of submissions are put against the wrong track. Many people seem to just submit to whatever track the system defaults to (and this year it looks like Agile Business was the default.)

While we can, and do, move sessions between tracks we don’t do this methodically. With nearly 300 submissions it would be too time consuming to review every session and decide which track it should be in.

Plus, some people deliberately want their submission in a particular track. Last year we had a talk on technical debt submitted to the business track. Before I moved it I happened to ask the submitter why he had gone there not software. His reply: “We deliberately did this because we want to raise the issue with managers.”

Some reviewers will mark sessions down because they are in the wrong track. That is a little unfair but understandable.

Where is Falmouth again?

One problem that seems to growing is people not knowing where the conference is. To be clear: Agile on the Beach is in Falmouth UK – lookup Falmouth on Google maps.

Falmouth is five hours by train from London. Seven hours from Manchester. Nine from Newcastle Upon Tyne.

You can fly into Newquay airport from several UK airports but you are still nearly an hour by taxi from Falmouth.

Both last year and this year we’ve accepted people who then, when they look at how long it takes to get to Falmouth pull out.

What is your conference about?

But that is not the worst.

Every year we get a few submissions, mostly from the USA , which are totally inappropriate, something like “Calisthenics for a younger look.” OK, I guess calisthenics helps make your body agile but did they stop reading at the conference name?

Mostly with some hint that the person who filled in the form is not the speaker. I suspect the semi-famous person has a PA who just submits to everything they can find.

We don’t pay

Similarly we get a clutch of submissions – again mostly from the USA – where in the synopsis the speaker say: “My feed is $1,500 plus travel expenses.”

AOTB only pays speakers a travel allowance, and we say that in the call for submissions.

OK, we do actually pay keynotes. But we choose the keynotes, usually in advance of the call for submissions. Don’t call us, we’ll call you.

During the year we get a few people – again largely Americans – who e-mail us to say: “I can keynote you conference blah blah blah…. my fee is blah blah.”

I can’t blame them, they are only trying to make a living. One day someone who we find interesting might even contact us!

(Ummm… maybe I should do it myself rather than waiting to be asked to keynote…)

I am …

A new one this year: round 1 was blind, no bibliography details. The hope was this would help new speakers and increase our diversity.

Some speakers chose to self-identification: they gave their names in the synopsis “I this talk Adam Jones will be talking about…” or even a mini-bio in the synopsis: “Sally Smith will draw on her long experience working as Agile Coach with companies such as blah blah blah”

True we didn’t tell people not to do this. Blind reviewing was an experiment so we didn’t really have any rules. But, some reviewers took a dislike to this – I can see comments which say “Would vote higher but speaker gave their name”

Please please please answer me when I call

Finally, AOTB has a two stage acceptance process.

If you get accepted you get a mail from me saying:

“Congratulations… here is the boring admin details, now confirm you can speak by clicking on this link….”

We know that a) some people can’t get to Falmouth, b) schedule change between submitting in December and acceptance in February, c) people forget they submitted, d) something in the admin details isn’t to their liking, d) some other reason.

Result: some people who submit can’t make it. That is why we ask for confirmation.

If you are accepted I need your reply. And the quicker I get it the better.

If I don’t get a reply after a few days I chase: repeat e-mails, Twitter, LinkedIn, SMS and if I need to I will pick up the phone and call you.

This year one speaker was impossible to contact, no phone number, no Twitter, no LinkedIn. My e-mail may have been going to spam. With a heavy heart I switched them from accept to decline.

Apart from this taking up my time it also delays the work of the rest of the committee, the website, the publicity, ticket sales and everything else. Until we have the programme in place a lot is on hold.

Your submission is important to us, please hold

Plus, we don’t say: “Sorry, your submission was not accepted” until we have our programme in place. When we loose a speaker we make an immediate substitution. It doesn’t seem right to tell a lot of people (about 240) that they are not speaking at AOTB and then a few days later say to one or two “O sorry, can we have you after all?”

We only send the sorries once we have all our speakers confirmed. So, if someone doesn’t reply, and we can’t get hold of them, we have no choice but to wait and try again. Which means everyone else has to wait which is not fair either.

Overall our system works. It is not perfect but I don’t think any system is perfect.

Agile on the Beach – update on review process

294 submissions
54 volunteer reviewers
2,400 votes
2 rounds of review
40 accepted submissions

Over the weekend I did the hardest thing I do all year: I sent the “sorry your submission to Agile on the Beach has not been chosen.” The declines.

I have explained how we review sessions for AOTB before but things have changed a bit so I owe it to submitters an explanation. So here goes…

This year, as usual, we had nearly 300 submissions to speak at Agile on the Beach. There are only 40 speaking slots – the exact number varies a little because we make minor changes to the schedule.

We have two review rounds. In round one reviewers score submissions from 1 to 5 – with 5 being the best. From this we create a shortlist for each track. Rule of thumb is the shortlist is twice the number of available slots (5 slots for Thursday tracks, 4 for Friday and 9 for two day tracks, so 10, 8 and 18.)

The first change for 2020: round 1 was done blind. That is anonymously, speaker bibliography details were not shown to reviewers.

Now on the one hand this is fairer: it gives more chance to new speakers, it stops the same old names dominating the conference and hopefully promotes diversity.

On the other hand: reviewers have often seen speakers previously and know who is good and who is not so good. It also has a commercial hit because a programme with more known names is likely to be more attractive to ticket buyers. So 2020 was an experiment.

I think blind reviewing worked. Although it does mean a few regulars did not make it and I feel bad about that, they are my friends. I also think we were right to look at speaker bios in round 2.

While we set no rules about speaker self-identification (i.e. some speakers used the synopsis to give their name or even mini-bios) a few reviewers didn’t appreciate this and in their comments noted they scored such submissions lower.

Back to shortlisting… when shortlisting we look at the mean score in reviews and the median. Usually the first few, highest scoring, sessions are easy to pick. It is the border line ones which are hard to decide.

In round two reviewers are asked to rank the shortlist. There can be only one number 1. The lowest score depends on how long the shortlist is, this varies by track. (So oddly, round 2 reverses scoring, 1 is top.)

In both rounds reviewers are encouraged – but not compelled – to write an explanation of their score. This is used by us as reviewers when deciding border line submissions and provided to the submitter as feedback.

In the past this process has needed reviewers to review 70 or more submissions. A few reviewers look at everything, all 300. I stopped doing this myself about two years back. Our submission system (Mimas) tries to ensure that submissions get an equal number of reviews.

Because reviewers were reviewing so many sessions feedback declined, I suspect attention to submissions decline too but I don’t know for sure.

The other big change for 2020: we recruited more reviewers. Actually, we invited everyone who had already bought a ticket, and everyone who attended in 2019 to review for round 1. 54 people volunteers and were allocated sessions to review. About a dozen people didn’t do their reviews but we still had plenty of scores.

This created more work for me than expected. While Mimas was updated to cope with this is wasn’t completely smooth. Whats more some reviewers left it to the last minute to review which created problems and meant I had to chase people.

Round 2 reviewing was more limited. Only about 12 reviewers picked including some AOTB committee members.

Over the years, and especially since I wrote Mimas, AOTB selection has become more score dependent. This has its good and bad sides but it does mean we get it done faster.

Once round 2 is done we look at the average (mean and median again) ranks and count of from the top to fill the track. Then we apply some judgement: people who submit in two tracks normally only speak in one. We would like a male/female balance but we don’t have any hard and fast rules plus, we don’t know if we are being fair on other diversity criteria. Are dyslexics fairly represented? Ethnic minorities? and so on.

We also have a financial consideration. AOTB pays a travel allowance dependent on how the speaker travels. This year when we completed selection and looked at the costs we were in budget. That doesn’t always happen, some years we have to cut back on long-haul speakers. Some years we argue and get more money.

Finally, we send acceptances. We ask everyone who is accepted to confirm they will attend and speak. Hopefully everyone says Yes and says so quickly. However we often loose people for one reason or another. Hence there are quick substitutions – that is why we hold off sending declined. Once we have the lineup settled we send the declines.

Every year we decline some amazing sessions that we would really like to host. We only have so much space. Every sessions we accept means another we can’t accept. We have enough good material for two conferences but only have one.

Whether you have been declined or accepted for 2020, whether you are thinking of submitting in 2021 or just trying to find out how conferences operate I hope that helps.

You might also want to look at:

Finally, you can see and try Mimas our conference review system – this is now OpenSource on GitHIb. I’ll blog more about this soon.
(Now reviewing is over I have a bunch of updates to do so the system may be up and down randomly this week.)


Like this post? – Like to receive these posts by e-mail?

Xanpan

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Framing the question frames the answers – my crown jewels

iStock-149794120s-2020-02-5-12-18.jpg

Today I’m giving away my crown jewels. Once you have read this post I can’t run my favourite exercise with you. There is a bit of experiential learning I can’t give you. So if you’ve rather have the experience stop reading and go and book yourself on my May workshop.

I’m describing an exercise that models what happens in “the real world(tm).” Plenty of the people who have done the exercise recognise it was a real life problem. The insights are many, and some a little disturbing.

Dozens of teams and the answers are always the same. I live in dread that someone will guess and ruin the exercise but it never happens. Now I’m telling the world that might change.

On screen I put a story something like:

As a widget maker I want an online store to sell my widgets so that I can make money

I separate the room into teams. Each team represents a technology supplier – an agency, an outsourcer, whatever. I want each team to competitively bid on a piece of work. Each team gets to think about the problem and estimate the work. At the end I want each team to be ready to name their price, how long it will take and how many people they need. They may add any more details they like, e.g. staging, design, technology, etc. (and most do).

The teams on the right get a story which says:

As an international widget maker I want to sell direct to customers so that I can cut out distributors. I anticipate $10million turnover within 3 years and have budgeted $1.2m for this project.

15 minutes later the teams on the right read out their bids. They always want a million give or take. They want months, if not years. They want teams of half a dozen or more engineers, testers, UXD, analysts and project managers. They may propose an ongoing maintenance contract too.

Very disconcerting for these teams is that while they are answering and taking questions the other teams, those on the left, often burst out laughing – literally – when they hear these proposals.

What neither side knows is that they have different stories. The teams on the left get a story saying:

As an artisan widget maker I want to sell my widgets to customers so that I can give up my day job. When I make $100,000 a year in sales I can live my dream. My accountant tells me a WordPress website will cost $5,000.

These teams want a week or two, an engineer or two and perhaps $10,000 tops. In some cases they say “We can do it this afternoon, we’ll set up Etsy.” Even if they don’t want to use Esty or eBay they probably propose an OpenSource solution.

So what do you think?

True, it is a semi-artificial set-up but I would argue that these situations happen all the time in “the real world” work environment. However they are usually well disguised and hard to see. Maybe now you will spot them.

That aside there are many potential lessons this exercise illustrates, almost everyone is worth a discussion in its own right. To keep things brief I’ll just highlight some of them:

  • Anchoring (cognitive bias): individuals are anchored to those numbers, bigger number lead them to frame their answers as bigger numbers.
  • Assumptions: people jump to assumptions, people automatically fill in the blanks when they lack information and the information they fill in flows from the numbers mentioned. Few questions get asked.
  • Different solutions: the key lesson for me, confronted with similar problems, people (especially engineers) are capable of formulating very different solutions. Those solutions have different time and cost implications.
  • Problem bounding: presenting the same problem with different bounding constraints results in massively different solutions.
  • Effort estimates, and therefore cost estimates, flow from value: whether through anchoring assumptions or solution designs the estimates (time and money) flow from the value available NOT the other way around.
  • Prior experience often goes out the window. In one run a low-end teams told me: “We did this last week. A digital consultant showed us how to install WordPress and Magento for online retail in the morning and in the afternoon we did it ourselves.” While this team came up with a low cost proposal their colleagues who were given the $1m story forgot everything they learned last week.
  • People don’t ask questions: I answer questions while teams are creating their answers but people rarely challenge what is asked for. Maybe its because I’m usually in some position of authority as a consultant or workshop trainer and my word should be followed.

Occasionally a team with the million dollar story say “We could do this with eBay/WordPress/Shopify.” I keep a poker face and let them be. Inevitably left alone for long enough they talk themselves into a much more complex and expensive bid.

In fact, the longer I give teams the higher the estimates go. I heard a team in Australia say three times “Those estimates look low, lets double them.” And they did. (Again, planning has diminishing returns.)

So far nobody has offered two solutions: you could offer up a Shopify solution and a custom build solution but nobody has.

While we are going through the exercise the minimal viable product idea often gets mentioned – usually by the teams on the right. So recently I introduced a third story. This read the same as the international widget maker but has an extra paragraph underneath:

MacAllan consulting has advised the company to take an iterative and agile approach to this work using a minimally viable product model.

How do you think teams respond?

Think for a minute… your answer is?

It makes no difference.

Or rather, so far I’ve not had any of the million dollar teams propose anything close to the $5,000 solution. In one case a team with the MVP story actually came in more expensive – and longer – than the million dollar team without the MVP clause.

My learning here: talking MVP makes no difference. If you want an MVP you have to impose constraints. (Hence try an MVT.)

People continue to fill in the blanks after the charade is exposed. I’ve heard software architects argue forcefully they these are different problems because of the money involved and therefore require different architecture. They clearly feel cheated and want to justify the proposal they have made. I suspect they feel I’ve made them look silly and want to undo that impression, I’m sorry if I’ve made anyone feel silly.

I wonder how often that happens in the work place? How many of us would back down in real life? I’d like to think I would but I would probably first try and justify my position.

The architects have a point, in many ways the stories are functionally the same but the differences lie in the non-functional requirements: load, throughput, security and so on. But all of that is inferred by people from the price tag without question.

It makes me sad that teams ask so few questions. People easily see themselves as a tailor not as a consultant (my Tailor or Image consultant post.)

Then there are the questions about the bidding process and companies bidding on the work.

Imagine you are the buyer: one supplier bids really low, the others were much higher but inline with your expectations. Would you trust the low bid? Have they blow their credibility?

And as a bidder: if you know the client plans to spend $1,000,000 why bid lower? The engineers cost estimates and designs aren’t relevant. Ideally you bid just below the competition. You are the lowest price with all the credibility and maximum revenue.

For that matter, should you be bidding on this at all?

If you work for a small e-commerce provider in rural Cornwall you may never know about, let alone, bid on a million dollar piece of work from an American multi-national. And if you did, would anyone take you seriously?

Suppose you got your big break: you walk in and offer a quick, low cost solution based on something like Shopify. Would they take you seriously? Would they want to listen?

Do corporations increase their own costs simply by being?

Conversely, if you work for a big consultancy and bid on million dollar deals every week will you be interested in bidding on a $5,000 piece of work? Of course not!

But that also means that if a corporation approaches you for a million dollar online shop, even if you could deliver it in a week’s time running on a third party platform do you have any incentive?

I don’t have answers to these questions. Indeed, there aren’t any right answers. All answers are valid, just some answers are “better” in some places than others.

Ultimately the lesson I take away from this is: we craft solutions within constraints.

More specifically: Engineers engineer within constraints, that is what engineers do.

That reinforces my belief that one needs to really understand benefit (value) and how that changes with time. From there we can work back to a solution.

If you would like to see this exercise for real then book yourself my Requirements, Backlogs and User Stories workshop. If you are in London Learning Connexions are running this again in May.


Like this post? – Like to receive these posts by e-mail?

Xanpan

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Dear customer, the truth about IT

Dear Customer, the truth about IT projects” was originally published in The Agile Journal way back in 2012. Unfortunately the essay has stood the test of time and is still regularly re-discovered online.

A couple of weeks ago I recorded an audio version of Dear Customer which I have now posted online. You can find links to the original publication and of a PDF of the essay at the same site.

O, and the essay forms the prologue to my Xanpan book, but newsletter subscribers probably know that because they downloaded a free copy of Xanpan when they subscribed!

Object oriented hierarchy? – a postscript

1143px-CPT-Structured_Chart_Example.svg-2020-01-31-12-05.png

My last post on hierarchy generated a fair bit of interest – both online and offline. Once it is pointed out people recognise there is a positive side to hierarchy, it is not so much “hierarchy bad, no hierarchy good” as it is “how much hierarchy?” and the culture around that hierarchy.

But there is something else I have to say, something that has been bugging me for years. Look at the picture above, it is a structure chart, this one from Wikipedia (public domain). I suspect few people below the age of 40 have seen one, this is the way I was taught to design software at University. A structure chart is like a flowchart but horizontal, not vertical.

Look familiar?

A structure chart looks a lot like a hierarchy chart. Compare the picture above with the (fantasy) organization chart on my previous post.

Structure charts are used when doing structured programming, a technique used in procedural programming. So Pascal, Modula-2, Algol, even C. In this world (experienced) programmers spend a lot of time thinking (and worrying) about layering. They aim for layered systems, these are drawn as dependency diagrams which – can you guess? – look a lot like hierarchies too.

While all of these techniques still have relevance, in our modern world things have changed. Primarily, procedural programming has given way to object-oriented programming. In OOP the object is the thing: the object is an idea, code and data reside in the object. We build our systems with self contained objects (well ideally).

Sound familiar?

I like to talk about Amoeba teams, similar ideas emerge under names such as Feature teams, or stand-alone, or even Spotify Squad. The repeated idea is that teams have a purpose and contain the people and skills they need to pursue that purpose.

In the 1970s and 80s we had procedural programming, structure charts and hierarchies. The organizational form of hierarchy matched our programming model. In the 1990s we switched to object-oriented programming and now our organizations are playing catch up in switching to “object oriented teams” (if I can coin a new expression, which naturally abbreviates to OOT).

Conway’s Law strikes again!

OOP changes how you design software, it also changes how organizations structure themselves. While OOP changes the way programmes are structured and reduces the way programs are layered (and dependencies managed) it doesn’t do away with a structure. There is still a framework in place. Similarly, OOTs don’t exist in isolation, they need to exist in a framework – a hierarchy of sorts.

(And of course modern UI models and micro-services means main() isn’t always the top of the program any more!)

Conway’s Law implies that a hierarchical organization will adopt procedural programming, which was true in the 60s and 70s. New companies, start-ups, born in the OOP age natural structure as OOTs. Existing companies first see tension because the two models rub against one another.

Then reverse Conway’s Law (Yawnoc as it is sometimes called) would suggest companies move towards OOT – which of course we see with all the big companies adopting “Spotify.”

Which raises the question:

If stand-alone/self-contained teams, and reduced hierarchy, are the organizational structure which parallels object-oriented design and programming… what is the organizational form that parallels functional programming? How do you structure your teams when you are working in Lisp, Haskell or F# ?

What about concurrent (parallel) languages like Occam?
What organizational structure parallels message passing systems?
Or Data flow architecture? And quantum computing?


Like this post? – Like to receive these posts by e-mail?

Xanpan

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

In defence of hierarchy

Heirarchy-2020-01-21-13-16.jpg

Hierarchy, it is one of those topics which provokes a reaction.

There are many in the agile community who believe hierarchy is a bad thing. Teams – and whole organizations are better off without hierarchy. It is simply(!) a case of finding better ways of organizing which don’t involve hierarchy.

Then there are those who acknowledge that hierarchy has been with us for millennia and find it hard to imagine how anyone could organise without it.

As a general rule the supporters of agile come down against hierarchy. I’ve been known to rail against hierarchy myself but at the same time I’ve long had my doubts that it is possible to remove hierarchy altogether. Rather I aim for less hierarchy and greater independence rather than the abolition of all hierarchy. I tend to keep this view to myself because a) it is subtle and b) I suspect I’ll loose a lot of agile street cred if people know.

So when I heard about a book called Hierarchy by John Child I immediately bought a copy. This is no easy read – Child is a Professor and so the style is academic rather than pop-psychology business blockbuster. So far I’m about half way through but the book raises many interested point that I’m still thinking through.

In particular Child highlights a number of benefits of hierarchy which deserve attention and I think are too often overlooked. Right now I want to capture my thoughts so far before I get into the arguments against hierarchy. So…

The benefits of hierarchy to an organization:

  • Hierarchy has benefits were there is regulation
  • Hierarchy helps large enterprises bring structure to their activities
  • Hierarchy tend to develop in all societies whether they are intended or not, therefore imposing a hierarchy gives an organization a chance both to impose the order they want – and choose the leaders – and rather than accepting the hierarchy and leaders that emerge.
  • Hierarchy allows for succession planning
  • Reduce illegal behaviour: maybe not a big issue in your twenty-first century office but this can be an issue. It can also be a particular issue when people rise to the top of a hierarchy and find the organizational controls they had before are gone: they have nobody to report to. Could this explain some of the sexual and business mis-conduct that has been in the media in recent times?

Benefits to the individual:

  • Hierarchy creates psychological safety, individuals know where they fit in and what is expected of them. They know who they need to pay attention to.
  • Hierarchy reduces cognitive load and fear, in part because of the psychological safety it creates.
  • Hierarchy provides a career model: people know what advancement in the organization looks like and those who want advancement can map out a course to achieve that.

Benefits to a team:

  • Hierarchy creates clear areas of responsibility which enables team members and creates focus within the team.
  • Hierarchy provides team members with a structures and helps them accept their position. On the whole people are accepting of hierarchy and accept the position. (Perhaps because they also know how they can advance their position.)
  • Hierarchy allows a mix of strong and weak personalities to work together. While hierarchy can be used by powerful formal leads to suppress weaker staff hierarchy cuts both ways. Team decision making can be improved when hierarchy facilities equitable discussion between strong personalities.
  • Formal hierarchy, with formal leaders, actually puts a responsibility on the leaders to ensure balance and allow weaker personalities to have their say. (While this can be abused when it is abused it should be clear to all concerned that the leader is not upholding their part of the bargain.)
  • In a recognised hierarchy the senior people have a responsibility to moderate and listen to all. Where there is no hierarchy few may feel that responsibility and a single strong voice may dominate the weak.
  • Where there is no hierarchy and multiple strong personalities the result can be conflict and disagreement. Without the hierarchy it can be hard to resolve such problems.
  • Hierarchy provides for decision makers, perhaps one, perhaps more. Having recognised decision makers can make for rapid decisions: people know who to go to and that person knows they have responsibility. Conversely, where decisions are made by consensus decision making can be slow or absent entirely.

Recently I observed a team which made most decisions by consensus. But as one strong personality rarely agreed with the others any decision they didn’t agree with became a battle field. Most team members kept quiet and nothing changed. Sometimes another strong personality would try and force the decision through but this was usually unsuccessful. Only when several other team members were prepared to take sides. As a result consensus became a recipe for not changing.

Of these arguments the ones I find most interesting are those which concern the emergence of social hierarchy. I’ve certainly seen this – even in organizations with a formal hierarchy. Emergent leadership and hierarchy can be a good thing. They can also be a bad thing.

I can immediately think of several teams I’ve worked with were one of the developers – sometimes a relatively junior one at that – emerge as leaders and the team adopted a hierarchy oriented towards that leader. On one occasion that leader was me and I like to think I brought an order and structure which was beneficial. But I’ve seen other occasions were the leader who emerged was at odds with others in the organization with the result of tension.

I expect the idea of emergent hierarchy is immediately recognisable to those schooled in emergent design and behaviour. The question becomes: should organizations accept this? Or should they try to guide it?

In the extreme should an organization fight an emergent hierarchy which conflicts with the aims and goals of the organization? And is it worth the effort?

So far I have more questions than answers. I haven’t suddenly become an advocate for hierarchy but I now recognised this is not a one sided discussion. I plan to write another blog when I get to the end of the book and have had a chance to think through the for and against arguments.

In the meantime I’d love to hear your thoughts and comments, just add them below.


Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Plan less, do more

PlanningDiminishingReturns-2020-01-13-10-39.png

“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”

Happy new year! – There is always a special responsibility that comes with the first blog post of a new year. Fortunately Tom Cagley of SpamCast fame asked me a fantasy question:

If there is one piece of advice you would give to CxO executives what would it be?

There is plenty of advice I’d like to give them, but one piece of advice?

One piece of advice which is generic and cuts across industry upon industry. One piece of advice for all those companies I know nothing about.

Tough. When I eventually came up with my answer I knew I’d have to explain it.

I had to think long and hard. I knew immediately that it would be something on the continuous digital theme. (One piece of advice for budding authors: don’t write long books, I knew this already then I mistakenly wrote Continuous Digital, that should have been four books.)

Eventually I came up with this:

“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”

I believe this is universally true. Plan anything for long enough and you will eventually plan your way out of doing anything. When I run my Extended XP Game I regularly see teams plan their way out of good approaches to work.

Some planning adds a lot of value. But the rate of learning slows and continues to slow. At some point you aren’t learning more at all, and sometime after that your learning is counter productive. As economists say: there are diminishing returns on the investment.

A little planning adds a lot of value. But each extra minute of planning adds less value than the previous minute. Plan a little, do a little.

In our modern technology driven world two factors make this especially true.

One: learning by doing is faster with modern technology

Technology has advanced: Moore’s Law means I have over 100 times as much power in my MacBook Air as I did in the 6502 BBC Micro I learned to program on in the 1980s. That in turn had more power than the IBM Mainframes of the late 1960s.

That means our tools are more powerful: the Python I programme in today isn’t the most powerful language but it is a damn site more powerful than 6502 assembler and BBC Basic. Add open source libraries and that Python is immensely more powerful than writing in 1960s COBOL.

As a result things that tool months or years to create take hours and days. A week of planning for a OS/360 COBOL program that will take 6 months to write makes sense. A week of planning for a Python program I’ll have running in the cloud by the end of next week doesn’t.

And when I say planning I mean all aspect of planning: research, requirements, schedules, architecture designs and the rest.

Sure a bit of planning makes complete sense. I would be stupid not to make a coffee and think about what I was about to do. But planning is all about learning, is about experiencing the future a little bit. The power of our tools today means that future is a lot closer, and the most rapid way to learn about it is to create it.

Once I reach that future it makes sense to stop, review and plan again. The quickest way to learn is to alternate thinking (that is “planning”) and action (learning by doing.) Do something, see what works, then take time to reflect and learn.

Doing is learning too. The question at any given point is: what is the fastest way to learn? In the beginning that is planning, very soon doing becomes faster.

Two: cost of delay changes everything

Once you appreciate cost of delay you see the world differently (If you don’t know cost of delay look at my Time-Value profiles (Look at my article in Agile Connection or read Don Reinertsen’s Principles of Product Development Flow.)

Now remember: planning time is time, planning delays launch. Keep planning, analysing, talking to potential customers, drawing imaginary project plans or perfecting your architecture (before you start building) all delays the time you will get a product into the market.

That delay is bad because it increases risk: until your product is in the market you are at risk of creating a product nobody wants, or at least nobody will pay for.

That delay means your product will earn less money – thats cost of delay. Potential customers may have found other solutions, competitors may have got there first, or technology advances may render your product obsolete.

Lets be straight: I’m not saying No Planning. A little planning can be really really useful and valuable. So please plan!

What I am saying is: plan a little, do a little. Repeat.

Then stop, reflect, evaluate, and plan a little more before you do a bit. Alternate planning and doing. I’m not original in saying that, the Shewhart cycle (i.e. the Deming cycle or PDCA), says the same and so do half a dozen other approaches.

The problem is: many executives have been taught to plan plan plan. Nobody ever gets in trouble for planning too much and most failures can be traced back to a failure to plan more if you try hard enough. Ultimately, if you plan enough you will never have any failures because you will never do anything.

Which brings me to the last part of that executive advice: “redesign governance to kill early and often.”

Organizational governance is overwhelmingly based on the assumption that we know what we are doing. Only things that are very well understood will be allowed to start. That incentivises people to plan plan plan. And when something does get started there is a bias against closing it down (inertia and commitment escalation).

That needs to change. Since we can’t know in advance we need to be able to react once work is in flight.

Organizations need to be prepared to start work where the outcome is vague. Governance then needs to kill initiatives which aren’t showing promise. Put it another way: the early stage gates need less rigorous and the later ones more rigourous. If governance isn’t killing initiatives often then either governance isn’t working or you aren’t taking enough risk.


Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Requirements, User Stories & Backlog

TwoBooks-2019-12-30-10-20.jpg

At the end of January I’m running my 1-day Requirements, User Stories and Backlogs workshop in London with Learning Connexions. I get great feedback from people who attend the course, perhaps because it is mostly exercised based.

If your interested check out the Learning Connexions page – its just one day and won’t break the bank! Hope to see you there.

Flipping job descriptions

iStock-179113204-2019-12-13-17-15.jpg

When was the last time you read your job description? Or, if it is a separate document, your “roles and responsibilities” description?

My guess it was about the time you applied for your current position. Of course, someone decided to change your description you might have read the new document but even then, did you?

I now I’m atypical because I haven’t had a job description for a long time but I honestly can’t recall ever reading them after I got the job. And I’m not even sure I read them much before then. Once you get beyond the title most of it is boiler plate and I quickly loose interest.

My guess is most people remember little more then the job title.

Like so many documents, it goes in one eye and out the other. The longer it is, the less you are likely to remember.

So it won’t surprise you when I say: I don’t think roles and responsibilities documents have much use. And it might not surprise you when I say roles are pretty pointless too.

To my mind your personal sense of identity, your own idea of who you are and what you do, plays a much bigger role in the actions you take in work and the responsibilities you accept – and those you ignore.

If, for example, your business card says: “Business Analyst”. It is not because someone defined your work as a “Business Analyst” it is because you see yourself as a business analysts and your sought out a business analyst job. What you less to do with what it says in some document, it has more to do with how you define yourself and therefore your role.

If you consider yourself to be a programmer, a software engineer, software developer or whatever, then you may shun business cards altogether. That again is part of your sense of identity. Identity is a far bigger driver of what you do than any document.

Try this: imagine you go to a meetup for people like you – be you a business analyst, a programmer, a tester or whatever. The room is full of people who share your job title – and similar role and responsibility documents. You see an inspiring speaker who advocates people like you – with your job title – undertake a new activity called XYZ. You see how it can benefit your work.

When you go to work the next day do you: look for opportunities to apply XYZ, or do you find your roles and responsibilities document and check whether XYZ falls within your remit?

For some years I’ve been wanting to try and experiment – but I need a really forward looking, daring, company to work with me on this. I want to flip recruitment.

The company advertises a job by title with few, if any, details. They ask people to apply not with a CV (resume) but with the job description they would write for such a job. The candidate sets out the role and responsibilities as they see it. The company then interviews those people who write the description that bests matches their own thinking and the candidates get to explain how they would live up to that description.

Crazy erh?


Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”