Coordinating teams like synchronised flying?

Allan Kelly from Allan Kelly Associates

I don’t really know what piloting a plane is like. I’m not a pilot. I have only ever been in the cockpit at museums (sitting in an SR-71 Blackbird was amazing). But, whenever I hear of software teams who need to work together – perhaps because they deliver different parts of the same product or perhaps because one supplies the other, or just because they all work for the same company – I always imagine its like synchronised flying.

In my mind I look at software teams and see the Red Arrows or Blue Angels. Now you could argue that software teams are nothing like an acrobatic team because those teams perform the same routines over and over again, and because those teams plan their routines in advance and practice, practice, practice.

But equally, while the routine may be planned in depth each plane has to be piloted by someone. That individual may be following a script but they are making hundreds of decisions a minute. Each plane is its own machine with its own variations, each plane encounters turbulence differently, each pilot has a different view through their window. And if any one pilot miscalculates…

As for the practice, one has to ask: why don’t software teams practice? – In many other disciplines practice, and rehearsal, is a fundamental part of doing the work. Thats why I’ve long aimed to make my own training workshops a form of rehearsal.

Software teams don’t perform the same routines again and again but in fact, software teams synchronise in common reoccurring ways: through APIs, at release times, at deadlines, at planning sessions. What the teams do in between differs but coordination happens in reoccurring forms.

While acrobatic teams may be an extreme example of co-ordination the same pilots don’t spend their entire lives flying stunts. Fighter pilots need to synchronise with other fighter pilots in battle situations.

OK, I’m breaking my own rule here – using a metaphor from a domain I know little of – but, at the same time I watch these displays and this image is what pops into my head.

Anyone got a better metaphor?

Or anyone know about flying and care to shoot down my metaphor?

Image: Klu Open Dagen 2019 from Wikimedia, CCL by TM.

Subscribe to my blog newsletter and download Project Myopia for Free

The post Coordinating teams like synchronised flying? appeared first on Allan Kelly Associates.

Next short online workshops

Allan Kelly from Allan Kelly Associates

Edinburgh Agile are now taking bookings for my next set of short online workshops. Agile Estimation & Forecasting has been added to the established User Stories Masterclass.

Upcoming dates are:

The code 15USERSTORY9YP should get you 15% off on the Edinburgh Agile website and there are some early bird offers too.

These are all half-day workshops which run online with Zoom. As well as the online class attendees receive one of my books to accompany the course, the workshop slides, a recording of the workshop and have the option of doing an online exam to receive a certificate.

These workshops are also available for private delivery with your teams. We ran our first client specific course last month and have another two booked before Christmas.

We are also working on a User Stories Masterclass 2 which should be available in the new year.

The post Next short online workshops appeared first on Allan Kelly Associates.

User Stories Masterclass: October & November

Allan Kelly from Allan Kelly Associates

Better User Stories
As a Product Owner I want to write better stories

A success story from the dark days of lock-down: my online User Stories Masterclass. The Masterclass is running again in October and November. The October run is the half-day version on the 26th, while November is four 90 minutes sessions, one a week for four weeks, November 9, 16, 23, 30th

Both these versions have run before and I have multiple reviews via Google. The mid change this time is I’m working with Edinburgh Agile who are handling ticket sales and who have added a certificate and exam.

There is an early bird discount and 10USERSTORY9YP will get you an extra 10% off.

The post User Stories Masterclass: October & November appeared first on Allan Kelly Associates.

User Stories Masterclass: October & November

Allan Kelly from Allan Kelly Associates

Better User Stories
As a Product Owner I want to write better stories

A success story from the dark days of lock-down: my online User Stories Masterclass. The Masterclass is running again in October and November. The October run is the half-day version on the 26th, while November is four 90 minutes sessions, one a week for four weeks, November 9, 16, 23, 30th

Both these versions have run before and I have multiple reviews via Google. The mid change this time is I’m working with Edinburgh Agile who are handling ticket sales and who have added a certificate and exam.

There is an early bird discount and 10USERSTORY9YP will get you an extra 10% off.

The post User Stories Masterclass: October & November appeared first on Allan Kelly Associates.

User Story or Epic?

Allan Kelly from Allan Kelly Associates

GoldenRules-2020-08-26-19-57.jpeg

I have two golden rules for user stories:

  1. The story should deliver business value: it should be meaningful to some customer, user, stakeholder. In some way the story should make their lives better.
  2. The story should be small enough to be delivered soon: some people say “within 2 days” but I’d generous, after all I used to be a C++ programmer, I’m happy as long as the story can be delivered within 2-weeks, i.e. the standard size of a sprint.

Now these two rules are in conflict, the need for value – and preferably more value! – pushes stories to be bigger while the second rule demands they are small. That is just the way things are, there is no magic solution, that is the tension we must manage.

Those two rules also help us differentiate between stories and epics – and tasks if you are using them:

  • Epics honour rule #1, epics are very valuable but they are not small, by definition they are large this epics are unlikely to be delivered soon
  • Tasks honour rule #2, they are small, very small, say a day of work. But they do not deliver value to stakeholders – or if they do it is not a big deal

EpicsStoriesTasks-2020-08-26-19-57.jpeg

Tasks are the things you do to build stories. And stories are the things you do to deliver epics. If you find you can complete a story without doing one of the planned tasks then great, and similarly not all stories need to be completed for an epic to be considered done.

In an ideal world you would not need tasks, every story would be small enough to stand alone. Nor would you need epics because stories would justify themselves. We can work towards that world but until then most teams of my experience use two of these three levels – stories and tasks or epics and stories. A few even use all three levels.

Using more than three is an administration problem. There is always a fourth level above these, the project or product that is the reason they exist in the first place. But really, three levels is more than enough to model just about anything: really small, small, and damn big.

And every story is a potential epic until proven guilty.

More about epics, stories and tasks in Little Book of Requirements and User Stories and in my User Stories Masterclass next month (use Blog15 for 15% discount).


September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


The post User Story or Epic? appeared first on Allan Kelly Associates.

User Story or Epic?

Allan Kelly from Allan Kelly Associates

GoldenRules-2020-08-26-19-57.jpeg

I have two golden rules for user stories:

  1. The story should deliver business value: it should be meaningful to some customer, user, stakeholder. In some way the story should make their lives better.
  2. The story should be small enough to be delivered soon: some people say “within 2 days” but I’d generous, after all I used to be a C++ programmer, I’m happy as long as the story can be delivered within 2-weeks, i.e. the standard size of a sprint.

Now these two rules are in conflict, the need for value – and preferably more value! – pushes stories to be bigger while the second rule demands they are small. That is just the way things are, there is no magic solution, that is the tension we must manage.

Those two rules also help us differentiate between stories and epics – and tasks if you are using them:

  • Epics honour rule #1, epics are very valuable but they are not small, by definition they are large this epics are unlikely to be delivered soon
  • Tasks honour rule #2, they are small, very small, say a day of work. But they do not deliver value to stakeholders – or if they do it is not a big deal

EpicsStoriesTasks-2020-08-26-19-57.jpeg

Tasks are the things you do to build stories. And stories are the things you do to deliver epics. If you find you can complete a story without doing one of the planned tasks then great, and similarly not all stories need to be completed for an epic to be considered done.

In an ideal world you would not need tasks, every story would be small enough to stand alone. Nor would you need epics because stories would justify themselves. We can work towards that world but until then most teams of my experience use two of these three levels – stories and tasks or epics and stories. A few even use all three levels.

Using more than three is an administration problem. There is always a fourth level above these, the project or product that is the reason they exist in the first place. But really, three levels is more than enough to model just about anything: really small, small, and damn big.

And every story is a potential epic until proven guilty.

More about epics, stories and tasks in Little Book of Requirements and User Stories and in my User Stories Masterclass next month (use Blog15 for 15% discount).


September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


The post User Story or Epic? appeared first on Allan Kelly Associates.

Agile Guide podcast with Wood Zuill and Tom Cagley

Allan Kelly from Allan Kelly Associates

I’m on a mission to popularise the term Agile Guide. A few weeks ago Wood Zuill (farther of Mob Programming and force behind #NoEstimates) and I recorded a podcast with Tom Cagley – another in his SpamCast series – on the Agile Guide role.

You can download the Agile Guide podcast from libsyn or you can download it from Apple, Sitcher, Google or Spotify.

The post Agile Guide podcast with Wood Zuill and Tom Cagley appeared first on Allan Kelly Associates.

All books bundle summer discoiunt

Allan Kelly from Allan Kelly Associates

PastedGraphic-2020-08-26-18-48.png
Now seems the time to add Agile & OKRs to my all books bundle on LeanPub. This bundle allows you to buy all six of my LeanPub books in one go at a discount – $27 instead of $68. While the addition doesn’t apply retrospectively anyone buying the bundle from now on will get Agile OKRs in addition to the other six books.

And for the week the bundle is discounted to $19.99 using the code Summer33 on the LeanPub site.

(Unfortunately I can’t include The Art of Agile Product Ownership, Business Patterns or Changing Software Development in this bundle because the copyright is now owned by the publishers.)


Subscribe to my blog newsletter and download Project Myopia for Free

The post All books bundle summer discoiunt appeared first on Allan Kelly Associates.

Agile: Prix fixe or a la carte?

Allan Kelly from Allan Kelly Associates

small-andersen-jensen-Hk2eu3OODdg-unsplash-2020-08-11-14-40.jpg

Advert: September micro-workshops – spaced limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value delivered

Early bird discounts & free tickets for unemployed/furloughed

Book with code Blog15 for 15% discount or get more details


“They don’t do Scrum so much as ScrumBut”

“We don’t do Scrum by the book, we changed it”

“We follow SAFe, except we’ve tailored it”

“We do a mix of agile methods”

“They call it agile but it isn’t really”

You’ve heard all these comments right? But have you noticed the tone of voice? The context in which they are said?

In my experience people say these things in a guilty way, what they mean to say is:

“They don’t do Scrum so much as Scrum but we don’t do it the way we should”

“We don’t do Scrum by the book, we changed it, we dropped the Scrum Master, we flex our sprints, …”

“We follow SAFe, except we’ve tailored it by dropping the agile coaches, the technical aspects and …”

“We do a mix of agile methods, we don’t do anything properly and its half baked”

“They call it agile but I don’t think they really understand what agile is”

Practitioners aren’t helped by advisors – coaches, trainers, consultants, what-not – who go around criticising teams for not following “Brand X Method” properly. But forget about them.

I want to rid you of your guilt. Nobody should feel guilty for not doing Scrum by the book, or SAFe the right way, or perfect Kanban.

Nobody, absolutely no person or organization I have ever met or heard of, does any method by the book.

After all “agile is a journey” and you might just be at a different point on the journey right now. To me agile is learning and there is more learning to be done – should we criticise people because the haven’t learned something?

All these methods offer a price fix menu: you pay a fixed price and you get a set menu.

In reality all agile methods should be seen as an à la carte menu: pick what you like, mix and match.

In fact, don’t just pick from the Scrum menu or the SAFe menu, pick across the menus: Scrum, XP, Kanban, SAFe, LeSS, DaD, whatever!

And do not feel guilty about it.

Do it.

My agile method, Xanpan explicitly says: mix and match. Xanpan lays out a model but it also says change things, find what works for you, steal from others.

The only thing you can get wrong in agile is doing things the same as you did 3 months ago. Keep experimenting, keep truing new ways, new ideas. If you improve then great, if not, roll-back and try something else.

In other words, keep learning.

Picture: Thanks to Andersen Jensen for the above photo on Unsplash.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Agile: Prix fixe or a la carte? appeared first on Allan Kelly Associates.

Agile & OKRs – the end is in sight

Allan Kelly from Allan Kelly Associates

The end is insight for my new book “Little Book of Agile and OKRs”. There are only a few more (short) chapters I want to write and I have put the wheels in motion to get a professional cover.

After that there is a lot of editing – including a professional copy edit – and perhaps a change of title, plus an audio version.

Anyone buying “Little Book of Agile and OKRs” will receive updates for free as they are published on LeanPub.

And if you are prepared to trade a little of your time I’m give you Little Book of Agile & OKRs for free. I’m looking for reviewers, right now I’d like feedback on my content, in a few months I’ll be looking for reviews on Amazon.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Agile & OKRs – the end is in sight appeared first on Allan Kelly Associates.