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

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

Book cover: Succeeding with OKRs in 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.

Manager at the centre of the solar system

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.

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.

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.

How I prioritise planning over plans

You might think that I’m a really organized person. After all, I spend a good chunk of my life helping other people be more organized about their work – and not just organized, prioritised, effective, and all those other good things. That might be true, people who know me well say I’m really well organized. But I always feel I’m faking it. I’m really disorganized.

As I spend a lot of time working by myself, for myself, and interleaving clients I need to organize my days. Over the years I’ve tried man different ways of organizing myself. Todo lists in my notebook are the main mechanism. Notebook and todo-list works well for the medium range but for the actual work of today its not so effective. I have, and sometimes use, a whiteboard: write out a list of things todo today and tick them as I do them. I’ve use post-it notes: write out all the things I need to do on one post-it each, prioritise them down the side of my desk and tick them as I do them.

In general I find that a system works for a while, maybe even a few of weeks but it decays. Perhaps its too routine, perhaps I’m over familiar. After a while I need a change. So after a period in the doldrums I bring back an old system or invent a new one.

During the last year of house-arrest I’ve found organizing myself really hard. A few months ago I came up with a new system: good old index cards. Extra big ones. On the left are the mundane or household things I need to do. On the right the important business stuff todo.

The keys to making any one of my systems work are:

1. The power of the (big red) tick. Being able to tick things off and mark them as done. Perhaps thats why electronic systems never work for me.

2. Prioritisation: Recognising that some things are more important and need to be done sooner or require more time. Accept some things fall off the bottom and don’t get done.

3. Limiting WIP, work in progress. It is easy to put too many things down, not do them, and write them down again tomorrow.

4. Sticking to the list and not getting distracted.

5. Rewrite the list every day

Now the last three there: prioritisation, limiting WIP and not getting distracted require personal discipline. I have to force myself to work within my system. Sometimes that is hard but if I don’t do it the system breaks down. And actually, that is usually why the system periodically requires reinventing.

For example: many of my cards list “EM, SL and LN” – short for E-Mail, Slack and LinkedIn. Messages arrive for me on all three and there are conversations I sometimes want to join in. But, very little on any of them is so important that is needs to be looked at at 9am. Everything on Slack and LinkedIn can wait, and almost everything on e-mail can wait. So a quick e-mail triage at 9am and pushing the rest until later in the day allows focus on important stuff. Unfortunately, because EM, SL and LN all generate dopamine it it very difficult to prevent myself from being distracted by them.

Rewriting the list everyday helps focus because I’m saying “this is what I will do.” For years I found that every time my notebook todo list ran out of space and I rewrote it I was much more productive that day – plus it was a cathartic experience. Arguably rewriting my list everyday is a waste of time because some items carry over and some items repeat. But the actual process of doing it, the planning rather than the plan, creates focus and motivation.

As you might have guess by now, a lot of this carrie directly over to my clients and their teams: prioritise the work, limit wip, let work fall off, stick to the system and the difficulties of discipline. Of course, what I’m describing is a system that emphasises planning over plans.

Another issue I regularly run up against is the “second priority” problem. Once all the pressing, really important and urgent stuff is done where do I put my attention? When I have three or four lower priority things to do it can be hard to choose which one to do and to stick with it. It can help to time-box the work, write “45” next to the work item and when I start work on it set a timer to stop after 45 minutes. I may not have done everything but I will have made progress and will at least have broken the second priority logjam.

Sometimes it’s hard to address an issue because it not clear what needs doing. When todo items are transactional “call X”, “write Y” it is easy to close them off. But sometimes hard to know what “Website” actually involves, I’m the one who decided I should work on my website, I’m the one doing the work, but what exactly should I be doing? And even if I know I should be, say: “updating keywords” what keywords? where? Even thought I can see something needs attention I don’t know what.

So, am I organized? or disorganized?

Well, I think this goes back to my dyslexia. Dyslexics are frequently disorganised because many (including me) suffer with poor short term memory. Left to myself I can be very disorganized.

But, dyslexics over compensate. A reoccurring pattern with dyslexics is that we have to create our own learning strategies and solutions to our own problems. Sometimes we over compensate and something we are bad at naturally becomes something we are very good at.

That I think is why other people think I’m really well organized and I think I’m badly organized.

And it is those ways of thinking and approaching organization – and work to do – which carries over to my professional work. Call it neurodiversity if you like.


Subscribe to my blog newsletter and download Continuous Digital for free

The post How I prioritise planning over plans appeared first on Allan Kelly, Software Strategy.

How I prioritise planning over plans

You might think that I’m a really organized person. After all, I spend a good chunk of my life helping other people be more organized about their work – and not just organized, prioritised, effective, and all those other good things. That might be true, people who know me well say I’m really well organized. But I always feel I’m faking it. I’m really disorganized.

As I spend a lot of time working by myself, for myself, and interleaving clients I need to organize my days. Over the years I’ve tried man different ways of organizing myself. Todo lists in my notebook are the main mechanism. Notebook and todo-list works well for the medium range but for the actual work of today its not so effective. I have, and sometimes use, a whiteboard: write out a list of things todo today and tick them as I do them. I’ve use post-it notes: write out all the things I need to do on one post-it each, prioritise them down the side of my desk and tick them as I do them.

In general I find that a system works for a while, maybe even a few of weeks but it decays. Perhaps its too routine, perhaps I’m over familiar. After a while I need a change. So after a period in the doldrums I bring back an old system or invent a new one.

During the last year of house-arrest I’ve found organizing myself really hard. A few months ago I came up with a new system: good old index cards. Extra big ones. On the left are the mundane or household things I need to do. On the right the important business stuff todo.

The keys to making any one of my systems work are:

1. The power of the (big red) tick. Being able to tick things off and mark them as done. Perhaps thats why electronic systems never work for me.

2. Prioritisation: Recognising that some things are more important and need to be done sooner or require more time. Accept some things fall off the bottom and don’t get done.

3. Limiting WIP, work in progress. It is easy to put too many things down, not do them, and write them down again tomorrow.

4. Sticking to the list and not getting distracted.

5. Rewrite the list every day

Now the last three there: prioritisation, limiting WIP and not getting distracted require personal discipline. I have to force myself to work within my system. Sometimes that is hard but if I don’t do it the system breaks down. And actually, that is usually why the system periodically requires reinventing.

For example: many of my cards list “EM, SL and LN” – short for E-Mail, Slack and LinkedIn. Messages arrive for me on all three and there are conversations I sometimes want to join in. But, very little on any of them is so important that is needs to be looked at at 9am. Everything on Slack and LinkedIn can wait, and almost everything on e-mail can wait. So a quick e-mail triage at 9am and pushing the rest until later in the day allows focus on important stuff. Unfortunately, because EM, SL and LN all generate dopamine it it very difficult to prevent myself from being distracted by them.

Rewriting the list everyday helps focus because I’m saying “this is what I will do.” For years I found that every time my notebook todo list ran out of space and I rewrote it I was much more productive that day – plus it was a cathartic experience. Arguably rewriting my list everyday is a waste of time because some items carry over and some items repeat. But the actual process of doing it, the planning rather than the plan, creates focus and motivation.

As you might have guess by now, a lot of this carrie directly over to my clients and their teams: prioritise the work, limit wip, let work fall off, stick to the system and the difficulties of discipline. Of course, what I’m describing is a system that emphasises planning over plans.

Another issue I regularly run up against is the “second priority” problem. Once all the pressing, really important and urgent stuff is done where do I put my attention? When I have three or four lower priority things to do it can be hard to choose which one to do and to stick with it. It can help to time-box the work, write “45” next to the work item and when I start work on it set a timer to stop after 45 minutes. I may not have done everything but I will have made progress and will at least have broken the second priority logjam.

Sometimes it’s hard to address an issue because it not clear what needs doing. When todo items are transactional “call X”, “write Y” it is easy to close them off. But sometimes hard to know what “Website” actually involves, I’m the one who decided I should work on my website, I’m the one doing the work, but what exactly should I be doing? And even if I know I should be, say: “updating keywords” what keywords? where? Even thought I can see something needs attention I don’t know what.

So, am I organized? or disorganized?

Well, I think this goes back to my dyslexia. Dyslexics are frequently disorganised because many (including me) suffer with poor short term memory. Left to myself I can be very disorganized.

But, dyslexics over compensate. A reoccurring pattern with dyslexics is that we have to create our own learning strategies and solutions to our own problems. Sometimes we over compensate and something we are bad at naturally becomes something we are very good at.

That I think is why other people think I’m really well organized and I think I’m badly organized.

And it is those ways of thinking and approaching organization – and work to do – which carries over to my professional work. Call it neurodiversity if you like.


Subscribe to my blog newsletter and download Continuous Digital for free

The post How I prioritise planning over plans appeared first on Allan Kelly.

Online User Stories tutorials now complete

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

I’m pleased to announce I’ve released the last of my online User Stories tutorials (part 5: Workflow and Lifecycle) and with that the whole series is complete. You can now buy the entire User Stories set of 5 tutorials as one package at a 40% discount to buying the tutorials individually.

The package includes over six hours of video commentary, exercises, quizzes, downloads and both ebook and audio book versions of Little Book of Requirements and User Stories.

Blog readers can get a further 25% off the price with the code: “blogoct21” until the end of this month, October 2021.

In addition, the first 3 people to use that code will receive a free print copy of The Art of Agile Product Ownership.

The 5 tutorials are:

These tutorials turned ouit to be a lot more work than I expected (where have i heard that before?). The core material is based on the Requirements, Backlogs and User Stories workshop that I have been running for a few years and last year converted to a series of online webinars. In the process the material has become a lot more focused.

Please, let me know what you think, in the comments section below or in the feedback forms at the end of each tutorial in the series.

The post Online User Stories tutorials now complete appeared first on Allan Kelly, Software Strategy.

Online User Stories tutorials now complete

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

I’m pleased to announce I’ve released the last of my online User Stories tutorials (part 5: Workflow and Lifecycle) and with that the whole series is complete. You can now buy the entire User Stories set of 5 tutorials as one package at a 40% discount to buying the tutorials individually.

The package includes over six hours of video commentary, exercises, quizzes, downloads and both ebook and audio book versions of Little Book of Requirements and User Stories.

Blog readers can get a further 25% off the price with the code: “blogoct21” until the end of this month, October 2021.

In addition, the first 3 people to use that code will receive a free print copy of The Art of Agile Product Ownership.

The 5 tutorials are:

These tutorials turned ouit to be a lot more work than I expected (where have i heard that before?). The core material is based on the Requirements, Backlogs and User Stories workshop that I have been running for a few years and last year converted to a series of online webinars. In the process the material has become a lot more focused.

Please, let me know what you think, in the comments section below or in the feedback forms at the end of each tutorial in the series.

The post Online User Stories tutorials now complete appeared first on Allan Kelly.

7 habits of highly effective software development?

“Most of us think we don’t have enough time to exercise. What a distorted paradigm! We don’t have not to.” Stephen R. Covey

Try reading that quote again and substituting the word “refactor” for “exercise.” Or try substitute the words “test first”, or “technical excellence” for “exercise.”

It was Craig Girvan of Head Forwards at Agile on the Beach this month who pointed out to me that one of the most famous management books of all time actually contains an edict to pursue technical excellence and refactoring.

Read this snippet form The 7 Habits of Highly Effective People and as you do so think about software development, and specifically the technical quality of the code being cut:

“We are instruments of our own performance, and to be effective, we need to recognize the importance of taking time to sharpen the saw”

Whether you think of the skills of the engineers building the system, the system itself, the technology which powers the system or the process that build the code into an executable there is a resonance.

On of the things Covey emphasis in the book is that the be effective one needs not just productive capacity (“PC”, the capability to produce something) but to maintain that ability and enhance that capacity. Hence his advice to: sharpen the saw. That means using some of your PC to create more PC in future, grow the pie if you like. This is a theme he returns too many times in the book.

And that is exactly the thinking we need to put behind our software development teams: it is not just about producing something for today, it is about increasing our capability for tomorrow. Of course there is a balance, one needs to both produce today and enhance for tomorrow, find the sweat spot is hard.

In the race to deliver value today we sometimes loose that. We forget that enhancing our capability creates value because it helps us create more value tomorrow – that capability is itself valuable. In part the problem is because investing in capability enhancements has a longer payback period, the return on those investments will not be seen immediately while directing our efforts to today will deliver returns real soon.

The old “jam today or more jam tomorrow” problem. It is a balance, and getting that balance right is incredibly difficult.

But it is exactly that philosophy that lead Microsoft and Amazon to reinvest all their profits for many years. Rather than pay shareholders dividends they prefer to invest in themselves so their future capacity is greater. And because of that promise their share rise in value and shareholders benefit more than if they had paid dividends.

It’s nearly 20 years since I read 7 Habits but after Craig’s observation I fished out my copy. What struck me was how the 7 Habits themselves could be seen as a software development method in their own right:

  1. Be proactive: teams are experts in delivering useful digital products, they should be finding what is needed and working to deliver it. Simply doing what you are told is not enough. The days of sitting around waiting for a requirements document or specification are over.
  2. Begin with the end in mind: what could be more outcome focused than that? It’s not about the myriad of stories and features you will develop, its the ultimate goals that is important
  3. Put first things first: some will see this as a mandate to design the thing up front, I don’t, I see this as an instruction to start delivering value and testing hypothesis immediately. For Covey it is simply about prioritisation, “organize and execute around priorities” – simply decide what are the priorities today and get on with them.
  4. Think Win/Win: too often in development we frame decisions in confrontational terms, “Users v. developers”, “The business v. coders”, “Programmers v. testers”. One side “wins” at the others expense. We need to stop that, and we need to stop seeing the divisions. (Similar to David Cote’s argument in Winning now, Winning later.)
  5. Seek to understand first, then be understood: what a brilliant way of saying “Listen to customers” and then frame technical discussions in terms the audience will understand.
  6. Synergize: this overlaps with #4 in my mind. Covey says it is about recognising that the whole is greater than the sum of its parts. What better description of a software system could you want? All those little parts, functions, classes, modules, all working together to produce a useful whole. Yet this is one of the most difficult problems in software engineering, approaching it from either the parts or the whole creates problems. Instead we need to build something small that works, some parts that work together, and then grow it, organically.
  7. Sharpen the saw: work to have more capability tomorrow than you have today, which is where we came in

So maybe 7 Habits is a development method in disguise, or maybe its a way of thinking that should inform our approach. In fact, as I said, I read the book nearly 20 years ago, I suspect much of this has seeped into my general thinking and, without me knowing it, informed my approach.

The book may have become a cliche itself but I would still recommend reading 7 Habits.

Saw images from Luke Milburn on Wikicommons, Creative Commons License.


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

The post 7 habits of highly effective software development? appeared first on Allan Kelly, Software Strategy.

7 habits of highly effective software development?

“Most of us think we don’t have enough time to exercise. What a distorted paradigm! We don’t have not to.” Stephen R. Covey

Try reading that quote again and substituting the word “refactor” for “exercise.” Or try substitute the words “test first”, or “technical excellence” for “exercise.”

It was Craig Girvan of Head Forwards at Agile on the Beach this month who pointed out to me that one of the most famous management books of all time actually contains an edict to pursue technical excellence and refactoring.

Read this snippet form The 7 Habits of Highly Effective People and as you do so think about software development, and specifically the technical quality of the code being cut:

“We are instruments of our own performance, and to be effective, we need to recognize the importance of taking time to sharpen the saw”

Whether you think of the skills of the engineers building the system, the system itself, the technology which powers the system or the process that build the code into an executable there is a resonance.

On of the things Covey emphasis in the book is that the be effective one needs not just productive capacity (“PC”, the capability to produce something) but to maintain that ability and enhance that capacity. Hence his advice to: sharpen the saw. That means using some of your PC to create more PC in future, grow the pie if you like. This is a theme he returns too many times in the book.

And that is exactly the thinking we need to put behind our software development teams: it is not just about producing something for today, it is about increasing our capability for tomorrow. Of course there is a balance, one needs to both produce today and enhance for tomorrow, find the sweat spot is hard.

In the race to deliver value today we sometimes loose that. We forget that enhancing our capability creates value because it helps us create more value tomorrow – that capability is itself valuable. In part the problem is because investing in capability enhancements has a longer payback period, the return on those investments will not be seen immediately while directing our efforts to today will deliver returns real soon.

The old “jam today or more jam tomorrow” problem. It is a balance, and getting that balance right is incredibly difficult.

But it is exactly that philosophy that lead Microsoft and Amazon to reinvest all their profits for many years. Rather than pay shareholders dividends they prefer to invest in themselves so their future capacity is greater. And because of that promise their share rise in value and shareholders benefit more than if they had paid dividends.

It’s nearly 20 years since I read 7 Habits but after Craig’s observation I fished out my copy. What struck me was how the 7 Habits themselves could be seen as a software development method in their own right:

  1. Be proactive: teams are experts in delivering useful digital products, they should be finding what is needed and working to deliver it. Simply doing what you are told is not enough. The days of sitting around waiting for a requirements document or specification are over.
  2. Begin with the end in mind: what could be more outcome focused than that? It’s not about the myriad of stories and features you will develop, its the ultimate goals that is important
  3. Put first things first: some will see this as a mandate to design the thing up front, I don’t, I see this as an instruction to start delivering value and testing hypothesis immediately. For Covey it is simply about prioritisation, “organize and execute around priorities” – simply decide what are the priorities today and get on with them.
  4. Think Win/Win: too often in development we frame decisions in confrontational terms, “Users v. developers”, “The business v. coders”, “Programmers v. testers”. One side “wins” at the others expense. We need to stop that, and we need to stop seeing the divisions. (Similar to David Cote’s argument in Winning now, Winning later.)
  5. Seek to understand first, then be understood: what a brilliant way of saying “Listen to customers” and then frame technical discussions in terms the audience will understand.
  6. Synergize: this overlaps with #4 in my mind. Covey says it is about recognising that the whole is greater than the sum of its parts. What better description of a software system could you want? All those little parts, functions, classes, modules, all working together to produce a useful whole. Yet this is one of the most difficult problems in software engineering, approaching it from either the parts or the whole creates problems. Instead we need to build something small that works, some parts that work together, and then grow it, organically.
  7. Sharpen the saw: work to have more capability tomorrow than you have today, which is where we came in

So maybe 7 Habits is a development method in disguise, or maybe its a way of thinking that should inform our approach. In fact, as I said, I read the book nearly 20 years ago, I suspect much of this has seeped into my general thinking and, without me knowing it, informed my approach.

The book may have become a cliche itself but I would still recommend reading 7 Habits.

Saw images from Luke Milburn on Wikicommons, Creative Commons License.


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

The post 7 habits of highly effective software development? appeared first on Allan Kelly.

Splitting & slicing user stories

I’m please to announce the fourth part of my User Stories tutorial is now available.

User Stories by example, part 4: Splitting stories

In this tutorial I look at 10 days to split a story and illustrate each with examples and exercises.

I have one more part of this tutorial series to deliver, Workflow and Lifecycle, hopefully I’ll have that out in the next month.

Until then please try the tutorial and let me know what you think.

The post Splitting & slicing user stories appeared first on Allan Kelly Associates.

Splitting & slicing user stories

I’m please to announce the fourth part of my User Stories tutorial is now available.

User Stories by example, part 4: Splitting stories

In this tutorial I look at 10 days to split a story and illustrate each with examples and exercises.

I have one more part of this tutorial series to deliver, Workflow and Lifecycle, hopefully I’ll have that out in the next month.

Until then please try the tutorial and let me know what you think.

The post Splitting & slicing user stories appeared first on Allan Kelly.

The Sprint Goal?

Hi Allan, what do you think of this as a Spring Goal?
  • Prototype store locator
  • Deploy product selector to live
  • Fix accessibility defects identified by client
  • Complete visual design of search feature
  • Security fixes & updates
  • Team improvement: refactor VX tables, page template processor”

I answer:

“This looks more like a sprint backlog than a sprint goal.”

This e-mail exchange sums up the problem with the sprint goal, or rather, the sprint goal as it so often ends up being used.

The sprint goal has always been part of Scrum even if it has often been forgotten. The idea behind it was to say: “What is the outcome this team needs to make happen this sprint?” The goal was meant to be a non-trivial thing, a meaningful step forward, an outcome, perhaps a challenge, certainly a rallying point.

However the sprint goal fell into disuse. When I used to run teams I never used it – partly because my teams have never used strict Scrum but also because most of the teams I worked with had multiple things happening. The teams were expected to make progress across a broad front. Conversely the sprint goal focuses the team on a single thing.

My experience was far from unique. And, if I’m being honest, in the days when I gave agile training regularly I never talked about it much. Again, most of the teams I encountered were expected to “deliver stuff” it was more a case of “burning down the backlog.”

When I did see the sprint goal used it was normally used in reverse. Rather than teams setting a goal and asking “What do we need to do to make this happen?” teams would decide on a collection of stories from the backlog and then ask “What is the goal we can write that describes this collection of items?” In such cases the goal might as well be “Do stuff” or perhaps “Do the collection of stories we think we can do.”

The goal was meaningless so why bother?

Yet I detect a change in the air. In the last few years I’ve heard the sprint goal talked about more and I’ve observed teams setting a goal more often. Plus, as I wrote in Succeeding with OKRs in Agile, a sprint goal sits well with OKRs – it also provides a way to cut through the tyranny of the backlog.

Unfortunately I have to report the teams I see setting sprint goals are still setting goals about “Do these stories from the backlog.”

Why is this?

Perhaps it is because the sprint goal is misunderstood or perhaps it is because people are aiming to tick off as many Scrum practices as they can, maybe they feel they must use the goal because Scrum lists it.

I’m sure both of these reasons are at play but I think the main reason is because of backlog fetish and the expectation that teams “do the backlog.” Teams – and especially product owners – don’t have the skills or aren’t being given the authority to make decisions about what to do based on fresh information arriving from customers, analytics and analysis.

That is: most teams are still expected to burn-down the backlog.

Well, it is one way of working, I understand the logic, and burning-down a backlog with Scrum is probably still better than ticking off use cases from a requirements document in a waterfall; but it still leaves so much opportunity unrealised. Things could be so much better if teams really worked to sprint goals and OKRs rather than labouring under the tyranny of the backlog.

So if you want some practical advice: if you are setting sprint goals in reverse just give up, accept that you “do backlog items” and save yourself the time of inventing a goal.

And if you are not setting a sprint goal: have a serious talk about it as a team, examine what having a sprint goal would mean and how you might work differently. Then experiment with using a sprint goal for a few sprints.

This advice goes doubly if you are a Product Owner, seriously using sprint goals is going to relieve you of a lot of backlog administration but means you will need to think hard about goals and what will really improve your product.


Subscribe to my blog newsletter and download Continuous Digital for free

(normal price $9.99/£9.95/€9.95)

The post The Sprint Goal? appeared first on Allan Kelly Associates.

The Sprint Goal?

Hi Allan, what do you think of this as a Spring Goal?
  • Prototype store locator
  • Deploy product selector to live
  • Fix accessibility defects identified by client
  • Complete visual design of search feature
  • Security fixes & updates
  • Team improvement: refactor VX tables, page template processor”

I answer:

“This looks more like a sprint backlog than a sprint goal.”

This e-mail exchange sums up the problem with the sprint goal, or rather, the sprint goal as it so often ends up being used.

The sprint goal has always been part of Scrum even if it has often been forgotten. The idea behind it was to say: “What is the outcome this team needs to make happen this sprint?” The goal was meant to be a non-trivial thing, a meaningful step forward, an outcome, perhaps a challenge, certainly a rallying point.

However the sprint goal fell into disuse. When I used to run teams I never used it – partly because my teams have never used strict Scrum but also because most of the teams I worked with had multiple things happening. The teams were expected to make progress across a broad front. Conversely the sprint goal focuses the team on a single thing.

My experience was far from unique. And, if I’m being honest, in the days when I gave agile training regularly I never talked about it much. Again, most of the teams I encountered were expected to “deliver stuff” it was more a case of “burning down the backlog.”

When I did see the sprint goal used it was normally used in reverse. Rather than teams setting a goal and asking “What do we need to do to make this happen?” teams would decide on a collection of stories from the backlog and then ask “What is the goal we can write that describes this collection of items?” In such cases the goal might as well be “Do stuff” or perhaps “Do the collection of stories we think we can do.”

The goal was meaningless so why bother?

Yet I detect a change in the air. In the last few years I’ve heard the sprint goal talked about more and I’ve observed teams setting a goal more often. Plus, as I wrote in Succeeding with OKRs in Agile, a sprint goal sits well with OKRs – it also provides a way to cut through the tyranny of the backlog.

Unfortunately I have to report the teams I see setting sprint goals are still setting goals about “Do these stories from the backlog.”

Why is this?

Perhaps it is because the sprint goal is misunderstood or perhaps it is because people are aiming to tick off as many Scrum practices as they can, maybe they feel they must use the goal because Scrum lists it.

I’m sure both of these reasons are at play but I think the main reason is because of backlog fetish and the expectation that teams “do the backlog.” Teams – and especially product owners – don’t have the skills or aren’t being given the authority to make decisions about what to do based on fresh information arriving from customers, analytics and analysis.

That is: most teams are still expected to burn-down the backlog.

Well, it is one way of working, I understand the logic, and burning-down a backlog with Scrum is probably still better than ticking off use cases from a requirements document in a waterfall; but it still leaves so much opportunity unrealised. Things could be so much better if teams really worked to sprint goals and OKRs rather than labouring under the tyranny of the backlog.

So if you want some practical advice: if you are setting sprint goals in reverse just give up, accept that you “do backlog items” and save yourself the time of inventing a goal.

And if you are not setting a sprint goal: have a serious talk about it as a team, examine what having a sprint goal would mean and how you might work differently. Then experiment with using a sprint goal for a few sprints.

This advice goes doubly if you are a Product Owner, seriously using sprint goals is going to relieve you of a lot of backlog administration but means you will need to think hard about goals and what will really improve your product.


Subscribe to my blog newsletter and download Continuous Digital for free

(normal price $9.99/£9.95/€9.95)

The post The Sprint Goal? appeared first on Allan Kelly.

Unplanned work after the sprint starts?

“Should unplanned work be allowed after the sprint starts?”

One of those questions which comes up again and again. And it came up last week when I visited a clients offices – yes I actually visited a client! The answer to this question is, as often happens: It depends. So let me give you my thinking.

First, many teams have a rule that work must be scheduled in the sprint planning meeting, after which this is fixed. Teams have a right to make this rule so if this is a team rule – what Kanban folk call a policy – then work is not allowed in.

This rule is based on a strict interpretation of Scrum. The thinking – particularly in early implemenations of Scrum – was that changing priorities was a big problem for teams and therefore fixing the work to be done for a few weeks made sense. In the event of that things did change the team would declare an “abnormal termination of sprint” and move to start a new sprint with new priorities.

Now for some teams this makes complete sense. Barring work from entering the sprint after planning makes complete sense. Equally it makes sense for team members to only do work scheduled in the sprint and refuse all other work. So, it depends… when a team is troubled by new work appearing, priorities changing, and when a team are expected to deliver something new – when their overarching priority is not support but building something new – then this approach makes complete sense.

But, don’t follow this rule just because you think Scrum says so. I just had a quick look at the latest Scrum Guide doesn’t actually mention abnormal termination of sprint. It does say “No changes are made that would endanger the Sprint Goal” which then leads us into a conversation about the sprint goal but let’s hold that for now.

Now ring fencing the team and the sprint like this solves one set of problems but it creates another set. If the team are aiming to be reactive why would they not pick up work?

And as teams increasingly become DevOps or SecDevOps, or BizDev, or whatever, things get more complicated. It would be irresponsible to hold a “no work enters the sprint” if the live server was down or a security hole had been found. But at the same time, being hyper-reactive has a downside because the team would be constant distracted.

Ultimately it is the Product Owner who should have the final say on whether work is unplanned work is accepted or not but when you have a customer on the phone someone else may be forced into a decision.

I apply two tests: is the unplanned work really urgent? – or could it wait a few days and be considered in the next sprint. (Or even queued in the backlog for longer.)

Second, is the unplanned work valuable? – namely, is it more valuable than the work the team are doing and would be displaced by this work. Ideally it would valuable enough to justify the disruption it causes by late entry too.

Hence I like to talk about urgent but valuable unplanned work. Just because something appears after sprint planning doesn’t mean it is not valuable. If the work is urgent, and if it is valuable enough, then it deserves to enter the sprint and get done.

However I like to build in two feedback loops. First, as the work arises, does the person raising the work understand the disruption this will cause? Are they prepared to accept that some other work may not get done?

I like to make this real: pull up your board and show the requester the consequences. Let them prioritise the work against the current planned work. This can make the unplanned work go away.

Second, mark the late-breaking work so you can track it through the system – on a physical board I would use a yellow card. At the end of the sprint review how many yellow cards you have and talk about whether the right decision was made.

Over time, as you build up your data – and stock of done yellow cards – you can reason about the cards and decide your long term action. For example,

You might want to make an allowance in sprint planning for unplanned work: suppose your team averages 3 yellow cards a sprint, then, when you are planning the sprint allow space for them.

If you have many yellow cards regularly you might even want to move to a Kanban model or split the team.

Review the requests, what are the common themes? – is there a module which is particularly troublesome, would some remedial work help reduce the unplanned work.

Or is there someone in particular who raises unplanned work? Should the team leaders talk to this person and see if they could change their behaviour, perhaps they could make their requests a few days earlier.

Maybe you want to ring-fence a team member to deal with unplanned work while the rest of the team pushes on with the main work.

As I said at the top of this post, the unplanned work question comes up a lot. I discussed it in Xanpan so if you want more examples go there. And if you have any other suggestions please comment on this post.


Subscribe to my blog newsletter and download Continuous Digital for free

The post Unplanned work after the sprint starts? appeared first on Allan Kelly Associates.

Unplanned work after the sprint starts?

“Should unplanned work be allowed after the sprint starts?”

One of those questions which comes up again and again. And it came up last week when I visited a clients offices – yes I actually visited a client! The answer to this question is, as often happens: It depends. So let me give you my thinking.

First, many teams have a rule that work must be scheduled in the sprint planning meeting, after which this is fixed. Teams have a right to make this rule so if this is a team rule – what Kanban folk call a policy – then work is not allowed in.

This rule is based on a strict interpretation of Scrum. The thinking – particularly in early implemenations of Scrum – was that changing priorities was a big problem for teams and therefore fixing the work to be done for a few weeks made sense. In the event of that things did change the team would declare an “abnormal termination of sprint” and move to start a new sprint with new priorities.

Now for some teams this makes complete sense. Barring work from entering the sprint after planning makes complete sense. Equally it makes sense for team members to only do work scheduled in the sprint and refuse all other work. So, it depends… when a team is troubled by new work appearing, priorities changing, and when a team are expected to deliver something new – when their overarching priority is not support but building something new – then this approach makes complete sense.

But, don’t follow this rule just because you think Scrum says so. I just had a quick look at the latest Scrum Guide doesn’t actually mention abnormal termination of sprint. It does say “No changes are made that would endanger the Sprint Goal” which then leads us into a conversation about the sprint goal but let’s hold that for now.

Now ring fencing the team and the sprint like this solves one set of problems but it creates another set. If the team are aiming to be reactive why would they not pick up work?

And as teams increasingly become DevOps or SecDevOps, or BizDev, or whatever, things get more complicated. It would be irresponsible to hold a “no work enters the sprint” if the live server was down or a security hole had been found. But at the same time, being hyper-reactive has a downside because the team would be constant distracted.

Ultimately it is the Product Owner who should have the final say on whether work is unplanned work is accepted or not but when you have a customer on the phone someone else may be forced into a decision.

I apply two tests: is the unplanned work really urgent? – or could it wait a few days and be considered in the next sprint. (Or even queued in the backlog for longer.)

Second, is the unplanned work valuable? – namely, is it more valuable than the work the team are doing and would be displaced by this work. Ideally it would valuable enough to justify the disruption it causes by late entry too.

Hence I like to talk about urgent but valuable unplanned work. Just because something appears after sprint planning doesn’t mean it is not valuable. If the work is urgent, and if it is valuable enough, then it deserves to enter the sprint and get done.

However I like to build in two feedback loops. First, as the work arises, does the person raising the work understand the disruption this will cause? Are they prepared to accept that some other work may not get done?

I like to make this real: pull up your board and show the requester the consequences. Let them prioritise the work against the current planned work. This can make the unplanned work go away.

Second, mark the late-breaking work so you can track it through the system – on a physical board I would use a yellow card. At the end of the sprint review how many yellow cards you have and talk about whether the right decision was made.

Over time, as you build up your data – and stock of done yellow cards – you can reason about the cards and decide your long term action. For example,

You might want to make an allowance in sprint planning for unplanned work: suppose your team averages 3 yellow cards a sprint, then, when you are planning the sprint allow space for them.

If you have many yellow cards regularly you might even want to move to a Kanban model or split the team.

Review the requests, what are the common themes? – is there a module which is particularly troublesome, would some remedial work help reduce the unplanned work.

Or is there someone in particular who raises unplanned work? Should the team leaders talk to this person and see if they could change their behaviour, perhaps they could make their requests a few days earlier.

Maybe you want to ring-fence a team member to deal with unplanned work while the rest of the team pushes on with the main work.

As I said at the top of this post, the unplanned work question comes up a lot. I discussed it in Xanpan so if you want more examples go there. And if you have any other suggestions please comment on this post.


Subscribe to my blog newsletter and download Continuous Digital for free

The post Unplanned work after the sprint starts? appeared first on Allan Kelly.

Analyse your Jira data? (for free)

Send me your data!

Think of this as a free offer, let me look at your data and I’ll tel you if I find anything interesting.

When I work with clients I often download the Jira data and crunch the data in Excel to see if I can find any patterns or any information in the mass of tickets and dates. I know there are tools out there which will do this but I’m never quite sure what these tools are telling me so I like to do it myself. Also its a bit of a “fishing trip” – I don’t know what I might find. Having done this a few time I’ve developed a bit of a pattern myself – nothing i can describe yet but who knows.

So, if you would like me to crunch your data please send it over. I say Jira but I’m happy to work with data from any other systems – I’ll learn something new

You will need to export all the issues as a CSV or Excel file. And I suggest you anonymise the data, just delete the columns with names and even delete the card description. The more you can send me the better, but the columns that interest me most have to do with dates (created and closed), ticket types (story, bug, task/sub-task, etc.), status and, if they are recorded, estimates and actual times.

I won’t share the data with anyone else – I’ll even delete it when I am finished if you wish. I would like to document some of my findings in a blog post but I can give you first sight if you like.

Apart from find patterns and perhaps learning something what interests me is what I might be able to tell about a team I know nothing about. It is an experiment. I’m allan AT allankelly.net – or use the contact page.

The post Analyse your Jira data? (for free) appeared first on Allan Kelly Associates.

Analyse your Jira data? (for free)

Send me your data!

Think of this as a free offer, let me look at your data and I’ll tel you if I find anything interesting.

When I work with clients I often download the Jira data and crunch the data in Excel to see if I can find any patterns or any information in the mass of tickets and dates. I know there are tools out there which will do this but I’m never quite sure what these tools are telling me so I like to do it myself. Also its a bit of a “fishing trip” – I don’t know what I might find. Having done this a few time I’ve developed a bit of a pattern myself – nothing i can describe yet but who knows.

So, if you would like me to crunch your data please send it over. I say Jira but I’m happy to work with data from any other systems – I’ll learn something new

You will need to export all the issues as a CSV or Excel file. And I suggest you anonymise the data, just delete the columns with names and even delete the card description. The more you can send me the better, but the columns that interest me most have to do with dates (created and closed), ticket types (story, bug, task/sub-task, etc.), status and, if they are recorded, estimates and actual times.

I won’t share the data with anyone else – I’ll even delete it when I am finished if you wish. I would like to document some of my findings in a blog post but I can give you first sight if you like.

Apart from find patterns and perhaps learning something what interests me is what I might be able to tell about a team I know nothing about. It is an experiment. I’m allan AT allankelly.net – or use the contact page.

The post Analyse your Jira data? (for free) appeared first on Allan Kelly.

Why on-ramps and off-ramps are more important than highways

It begins with a simple request: “we need to know when it will be done.” Or, when there is an agile-savvy manager, “our velocity needs to be higher.” But the more I look the more it appears the dev team aren’t really that bad, in fact they might actually be good. And, if you doubled team productivity overnight it wouldn’t make a big difference. The problem is elsewhere.

Sure the dev team could be better in many ways but simply coding faster isn’t going to solve the problem. The on-ramp and the off-ramp are in need of improvement: the work intake and the work delivery mechanism – entry ramp (getting stuff in processed) and exit ramp (getting it out the door) are often more imporant.

As they say: its déjà vu all over again. I see this again and again. In my mind’s eye turning requests into working software is a freeway, a motorway, an autobahn – a controlled-access highway to use a technical term. Each piece of work is a car.

Most of our attention goes on the cars/work speeding down the lanes, that is where we assume time is spent. That is where most of the team are working, that is where we direct people to look for problems. If all goes well the work/car moves rapidly from one place to another. Sure things go wrong on that journey, in coding, sometimes other pieces of work get in the way, sometimes something goes wrong and there is a pile up with work/cars queuing behind. And sometimes the best way of improving the overall flow is to limit work in progress or reduce speed limits.

But, the actual speeding down the highway part is but one of three essential elements. Frequently this is not where time is lost, and even though work can be unpredictable it is not the most unpredictable part of the work.

It is fairly common for work to spend most of its life waiting to enter the system – the on-ramp, how cars get on the highway and how work enters the development processes.

And there is the off-ramp – how does work leave the system and reach the customer? – after cars only join the highway when they are coming from one place and want to get to another.

Most people working in the system see their job as driving cars and ensuring that a particular payload is delivered to the destination. Who looks at the overall system? Who manages the highway? Who optimises the flow? This is where I see my work. It is not enough to ensure a piece of work is delivered, it is not enough to ensure the cars are going fast, one has to see the whole system. Usually the on-ramp and off-ramp require far more work than the actual highway itself.

In other words: it is not about ensuring any one car arrives once. It is about ensuring the system for delivering cars works effectively. While the highway journey gets the attention the on-ramp and off-ramp are often far more important.

Consider the off-ramp: it is very common to find that development teams are working pretty well, but when work is “done coding” it queues to get through testing, queues to get into a release and queues to be released. In fact, it is almost normal in teams that work spends longer “getting out the door” than it spends being done.

The continuous delivery movement has done a lot to improve this and the best teams have streamlined and automated this part but problems remain. I’ll just mention two.

One: I just said “the best teams.” The best teams are few and far between. Yes they get lots of attention but most teams are a long way from this. It is not uncommon to find that teams consider some continuous delivery processes madness. I floated the idea of branchless development to a team this year and they took it as a sign that I didn’t understand their work. The idea that you might not use source control branches appeared like a naive beginners mistake.

Two: where do you put testing? If testing is considered a special activity that must happen as part of a release process then it occurs on the off-ramp. That off-ramp has limited capacity and any problems have big knock on effects – it is very risky.

However, testing can be considered part of the main highway experience. Developers can work to a high standard an incorporate practices like TDD and BDD which lesson the need for testing. Formal testing – probably by professional testers- can be positioned before the off-ramp if you design the highway/workflow correctly.

Now consider the on-ramp: the intake process, the requirements process, the work-before coding, work that is normally done by Product Owners/Product Managers or Business Analysts. This can cause even bigger hold-ups than the off-ramp.

I’ve written before about the fear many organizations have of actually coding. As a result work is held in perpetual review, estimation and planning before it is allowed anywhere near a coder.

Another cause of delay is the product backlog: in many places this is a bottomless pit of work to do. Every few weeks the Product Owner shifts through the backlog selecting a few pieces of work to get done. Most work doesn’t get done and falls to the bottom. It is unlikely to be done but gets in the way and distorts metrics. As a result most work spends most of its life cycle waiting to be done, waiting to get onto the highway.

There is a natural (and good) tendency to focus on the work in hand, to think “if I can only get this piece of work done…” Like Orwell’s Boxer pledging “I will work harder” to any problem. (There are plenty of none team members prepared to stand on the sidelines saying “If only they did work harder.”)

It is not enough for any one person to work harder. It is a system: the an on-ramp, a highway and and off-ramp all need to work together. Only looking at the whole do these things become clear. Improving this flow requires a different set of skills to those of writing code and testing – of course there is overlap in skills and of course people can learn; but again, if one simply pledges to “work harder” and write better code the improvement will be marginal.

Seeing the highway – the work flow – is something I would expect a development manager to do, and if not a development manager than the person I call and Agile Guide and most of the rest of the industry calls an Agile Coach.


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

The post Why on-ramps and off-ramps are more important than highways appeared first on Allan Kelly Associates.

Have Google made a $billion skateboard mistake?

How do you design a car? – It is one of the most famous diagrams in the agile world drawn by Henrik Kniberg.

I’m guessing many readers know this already: one approach (top of the diagram) is to iteratively design and build all the pieces, put them together and you have a car. This is one interpretation of iterative but until you put the pieces together there is no feedback and no value.

After all, who wants half a car? We know what we want from a car, right? Who needs feedback? Who wants a car with three wheels? – Why waste time experimenting?

The alternative, advocated by minimally viable product people everywhere is to redefine the problem; we don’t want a car so much as transportation, we could start with a very simple – and quick to deliver – transportation system (the skateboard). Because it is delivered sooner we get feedback sooner. We see how people use it, and evolve it over a series of iterations into a motorised car.

Since I know this, you know this and it is on the back of every agile cereal packet one can rest assured that Larry Page, Tim Cook and Jeff Bezos know this, right?

Well no, not according to the Financial Times recently. The FT carried a piece about the development of autonomous cars – “Robotaxis: have Google and Amazon backed the wrong technology?” – paywalled. Since we already have the sort taxi someone drives the development effort goes into advancement.

For the last few years Google/Waymo, Apple and others have sunk billions of dollar – yes billions – into developing self-driving cars. And of course, we all know what we want from a car, even a self-driving car so this is an engineering problem.

These cars now work but there are a number of challenges before the achieve world dominance. Most of the challenges now are less to do with the technology and more to do with the market: customer acceptance, insurance, pricing, etc. Still, billions more are needed before any return can be achieved. In other words: Google etc. took the first approach, build the pieces.

What is less well know, and what the FT writes about, is that another group of companies has take the other approach. Component suppliers like Bosch and Magna, and tech companies like Mobileye (Intel) have been developing desecrate technologies that can be incorporated into existing cars which evolve towards self-driving dream. Not only is this cheaper but it is easier to market and clear regulatory hurdles because humans are assisted in driving not replaced. (Tesla is also in this camp as they add more and more capabilities to their auto-pilot features and have been getting feedback from real customers for years.)

Now it seems evolutionary approach may win-out against the big clean sheet of paper. The race is not over yet but the evolutionary suppliers are making money while the new designer are still burning cash. The evolutionary suppliers are integrating their tech into cars and getting regulatory approach while the new designers have to navigate many regulators.

Engineers often object to the evolutionary model because: “we need to see the big picture”, “you need an architecture”, “you can’t evolve a skateboard into a car”. And indeed, one of the Google engineers, quoted in the FT saying:

“Conventional wisdom would say that we’ll just take driver assistance systems and we’ll kind of push them and … over time, they’ll turn into self-driving cars … well that’s like saying that if I work really hard at jumping, one day I’ll be able to fly.”

Chris Urmson, 2015

When you consider the problem purely in engineering terms this rings true, but while one needs to respect engineering it is not the only frame of reference. One need to consider the commercial and marketing aspects, as well as customer acceptance and other factors. To give any single line of thought a privileged position is to expose yourself to risks from the others.

At the end of the day, as I have argued repeatedly: engineering is about creating solutions within a context, within constraints. To any given problem there are many potential solutions – many ways to slice the onion. The “best” solution is the solution which best fits those constraints.

The evolutionary approach allows you get feedback sooner which allows you to uncover those constrains sooner, that allows for course corrections and it also means less time and money has been spent on solutions which don’t meet the constraints.


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

The post Have Google made a $billion skateboard mistake? appeared first on Allan Kelly Associates.

Documentation, another case of rapidly diminishing returns

No body writes documentation in startups.

Writing documents is a luxury only established companies can afford. One might ask: are companies successful because they write documents or do they write documents because they are successful? But I’d be hard pushed to find anyone to argue the latter.

Back in 1996 I worked on the ill-fated UK rail privatisation. I was part of the team writing a new computer system to create a new rail timetable – one that would allow competition in train services. In the average week I spent half my time coding and half my time documenting.

For every program there was a program specification – what the program had to do. And a functional specification – saying what the program did. I had to update both. And these had to align with the system architecture, which was a multi-volume beast I wasn’t allowed to touch.

Additionally I had to create a unit test plan for each program or set of changes. Unit tests were manual and the test plan was made up of two Word documents. One was a big table and the other had one test per page. As I conducted the test I had to update the plan with success or fail – and fail of course mean rework so we alwys made sure it worked before hand.

When my program was ready to check-in I had to fill in a source code control form so my team leader knew which files to check in. If I added a new code file to the system I needed to complete an additional form to explain what the file was. On one occasion I got fed up of a 2,000 line C++ file and refactored it as 4 smaller files. Being C++ his meant 4 pairs of .h and .cpp files, so 8 new files each with a form. My team leader was quite clear: I was never to do this again, it made too much work for her.

Did it help? – I find it hard to imagine it did. In fact I started my own hidden documentation, the “Rough Guide to …” which told me (and other devs) things we actually needed to know.

There are two types of companies: those that don’t write documents – and where many many people are asking for documentation. Documentation is seen as a solution to (almost) any problem. And yet people don’t write documents, then they feel guilty about not writing them.

The second type of company is overrun with documentation. There seem to be armies of people writing documentation: architects and business analysts seem particularly keen to write documents. These are often prose, they are about as readable as your average Shakespeare play is to a 15 year old and read about as often. Project managers are also prone to documentation but they don’t write prose; instead, project plans and progress presentations are documents in another medium.

In the first type of company nobody reads documents because there are none. In the second type of company its debatable how many of those documents are read. Many of them are so utterly boring that it is hard to stay awake reading them. As I’m often heard to say:

The bigger a document is, the less likely it is to be read.

And if it is read, the bigger a document is the less the reader will remember.

In one eye-and-out-the-other.

It’s probably just as well because documentation rapidly becomes out of date unless copious amounts of time are invested in keeping it up to date. Actually, it is good that documentation is seldom read because reading it is almost as expensive as writing it and, in theory at least, it should be read far more often.

True, “documentation” covers a very wide range of things. From project plans to release notes, from user guides to architecture diagrams. Some has more readers more than others – user guides compared to functional specifications. But then, who has read their iPhone manual? Does such a document even exist? Arguably the best products don’t need documentation.

In both types of companies I hear complaints about the lack of communication – actually, I don’t think I’ve ever visited a client were people didn’t complain about the lack of communication. But only in the first type of company do people think that documentation will cure the problem.

In such companies documentation is seen as the solution to almost every problem. Programmers complain they haven’t been given written requirements and specifications, they complain the user designers aren’t giving them documents of is expected, and most of all they complain the developers who came before them did not document what they did. Equally testers demand the same requirements and specification but also want programmers to provide written descriptions of what the program does. Project managers want written reports of what was done and so on.

Nobody ever got fired for asking for more documentation, but I’m not so sure about writing it.

While I have sympathy that these people want information I don’t believe documentation will solve the problems – perhaps because I’ve never seen a development effort with “Goldilocks documentation” – not too much and not too little. One thing I do know is that if everyone wrote the documentation they thought was needed, and what others wanted from them, then little would get done.

What I fear is a descent into documentation as everyone sets about communicating through documentation and not talking.

Because documentation takes time and money to create, it takes time and money to read, it takes time and money to update and keep current. And all the time and money spent on documentation is time and money not being spent on developing products and testing products in the market.

Worst still documentation becomes a hinderance to change. On multiple occasions I have met companies that do not want to change their products or processes because the cost of updating the documentation is too great.

I’ve nothing against documentation itself, I simply lament the time and money that could be better spent elsewhere, I regret the missed opportunities for real communication and belief that something has been communicated; and I fear the limitations that documentation brings once in place.

To answer my own question above. I don’t believe companies that write documents are successful, documentation does not determine success – if it did many many projects would have succeeded instead of failing. That documentation is so often lacking but products are successful actually goes to prove that is not essential.

Nor do I really believe companies write documents because they are successful. They write documents because they are successful enough to be able to afford to write documents but those same documents inhibit future success.

Before I close, I can almost hear people rushing to their keyboards to tell me of occasions were a system document saved their life,

“If Sam hadn’t left behind a document that told me the function was connected to the reactor core…”

While I’m sure such cases exists I’m not convinced the they justify the vast amounts of cost of writing a document against doing something else. If Sam hadn’t written that document what might Sam have done with the time instead? Possibly something even more valuable.

As with planning documentation exhibits rapidly diminishing returns on investment.

Photo by Glenn Carstens-Peters on Unsplash


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

The post Documentation, another case of rapidly diminishing returns appeared first on Allan Kelly Associates.

User Stories by Example part 3 (Refactoring)

The latest instalment of my online User Stories tutorial is now available online, User Stories by Example: Refactoring.

It takes as its starting point some existing stories and reworks them to convey their message more clearly. In the process I discuss:

The use of time-boxed spikes.

The naming of team members in user stories, e.g. “As a developer I want …” – and why this isn’t a good idea.

Rewriting user stories and breaking them down into more smaller stories. (More on this in the next tutorial.)

Why more smaller stories is better than a fewer larger stories.

How acceptance criteria can be used to split stories into smaller pieces.

and a brief look at dealing with dependencies.

Videos are intersperced with exercises and quizzes. My guess is this tutorial will take two to three hours to complete – which can be all in one go or split over days or weeks to suit yourself. As with the earlier tutorials I work through real life user stories to illustrate and draw lessons.

This is the third tutorial, it joins User Stories by Example part 1 Starting with Stories and part 2 Acceptance Criteria. The next module will look at splitting stories in more detail.

The tutorial this carries the introductory price of $49. In time this price will probably rise and I’ll introduce a combined option to buy all the courses in one go.

Please e-mail me with your comments and suggestions.

The post User Stories by Example part 3 (Refactoring) appeared first on Allan Kelly Associates.

Succeeding with OKRs in Agile, Podcast with Agile Uprising

Agile Uprising has just published a new podcast they recorded with my a few weeks ago about, well OKRs and my book Succeeding with OKRs in Agile.

Succeeding with OKRs in Agile podcast is available for download now – for free


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

The post Succeeding with OKRs in Agile, Podcast with Agile Uprising appeared first on Allan Kelly Associates.

Software is not a lump or work to do (and the laws which prove it)

Workers digging hole

Building software is not like digging a hole in the ground: your target changes as you dig, the people and machines you use change the outcome as much as any original idea, and you never really know when to stop digging.

Years ago I was hired by Reuters to build an interface connector between the Liffe trading exchange and their data systems. Another developer started a few weeks after me. In the end we produced about half a dozen modules that worked together to make the connection. But we only produced that many because we were over staffed. In reality the one module I wrote handled 90% of the work required, the other modules were largely superfluous. And certainly the extra time which would have been required to make my module do 100% of the work was less than the time I spent to make sure it worked with the other.

Regular readers have probably already recognised Kelly’s Second Law of software: Inside every large development effort there is a small one struggling to get out

This itself is an example of Parkinson’s Law: work expands so as to fill the time available for its completion.

Actually you might restate my second law as Parkinson’s Law in reverse: constraining the capacity to do work reduces the amount of work to do. If you think about it this is a result of Conway’s Law: system designs copy the communication channels in the organization which creates the system.

Economists see a related phenomenon as the Lump of Work fallacy: people assume there is a fixed lump of work to do. If there are more people to do the work (say from immigration) then there will be unemployment – or possibly wages will be forced down and same work is distributed between more people. However it doesn’t national economies work like that, more people demand more food, houses, healthcare, schools and so on. What is true in the small is not true in the large. The net effect can be positive for countries but exactly how and by how much is hotly debated.

Software development has its own lump of work fallacy. There isn’t a fixed amount of work to do. Rather than saying “How many people will it take and how long will it take?” It is better to say “If we have five people working on this for three months what progress can we make?”

Writing software is not like digging a hole in the ground: the work to do is neither really known in advance nor is it fixed. Adding people actually increases the amount of work to do – Brooks’s Law.

At the start nobody really knows what it required, they may get lucky but more often that not once the thing is put in front of clients and (potential) customers the ask changes. I’ve heard this called Humphrey’s Law (after Watts Humphrey) although that name is not in common usage and there is another Humphrey’s Law from the world of psychology – which is connected with time estimation discussions for different reasons.

When you put Parkinson’s Law together with this “don’t know until I see it” law you get Hofstadter’s law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Assume for the moment that one can know what is wanted in advance there is another problem: there are multiple ways to achieve the same result. There is no one true way in software development, there are always multiple ways to achieve the same end result.

Even if one was to fix the big questions – the OS, the delivery platform, the programming language and the database and so on – then you can still create very different implementations for the same thing. Or as I usually put it “there are many ways to dice the onion” – my Crown Jewels post describes how I can get wildly different time and money estimates for what is basically the same piece of work.

Of course the big consequence of these is estimation – how can anyone estimate in these circumstances? Let me go further and suggest that the process of estimating the work to do is more likely than not to increase the amount of work to do. Not only does estimation take time to do itself, but there when estimating there is a tendency to “play safe” and favour larger estimates even when these estimates are themselves underestimates (see Vierordt’s law.)

Sometimes it feels like quantum physics: when one parameter is measured another changes, we can know the speed but not the direction, or the direction but not the speed.

I’m not sure I have a complete answer but I have some of the pieces.

Start new work with a Minimally Viable Team: task the team to start immediately and in parallel work to understand what is needed and create potential solutions.

Keep teams stable: This contains a lot of variables and provides some past performance data to include in calculations. It will at times be necessary for the teams to call in more help – pull more skills and resources as needed.

By working with existing and minimally viable teams the problems are partially constrained: the technologies available are mostly the technologies the team knows already, the number of people available to work on the work is the number of people on the team. In time you may change both these parameters but initially they are constraints to work within.

Use active portfolio management and governance to kill work which is under performing or escalating beyond expectations.

The next time someone says “Building software should be like building a house” please remind them you aren’t building a house. What software engineers do is massively more variable and complex than building another example of the same thing.

Back at Reuters, the bright side was that the over engineered system we built wasn’t just used for Liffe, it was used to connect 2 or 3 other exchanges too so maybe over staffing was worth it. Except I don’t believe it really made economic sense, it would have been better to get the one exchange working and only add the minimum to the system when the second and third exchanges came along – diseconomies of scale again.


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

The post Software is not a lump or work to do (and the laws which prove it) appeared first on Allan Kelly Associates.

New online tutorial: User Stories

This blog and my email updates have been quiet lately because I’ve been working on some online tutorial (in addition to working with clients!).

These tutorials differ from my earlier work in that they are autonomous, self-paced, async – I’m not there! – truly online.

Just my voice, my slides, my exercises and my wisdom.

At the moment there are two tutorial, “User Stories by Example” part 1 – an introduction and part 2 which looks specifically at acceptance criteria. Both use actual user stories I’ve collected over the years and both are derived from the online interactive workshops I ran during lockdown last year. Those workshops were themselves based on a physical workshop I’ve been running for several years, which in turn is based on my Little Book of Requirements and User Stories book.

I have plans for more tutorials covering user story refactoring stories (i.e. improving existing stories), story lifecycle and workflow, splitting stories and appreciating value. First I’ll wait for more feedback on these first two.

I’ve set introductory pricing at $59 and $49 (USD) but I expect those prices to rise as I add more modules. Part includes both the e-book and audio book version of Little Book.

Blog readers can get another 20% off with the coupon code “blogdiscount” until the end of July.

I’d love to get your feedback on these course so if you try one please complete the survey at the end and e-mail me if you have other comments. And if these courses are not for you, well, please e-mail me anyway and tell me what you would like to see me produce next.

The post New online tutorial: User Stories appeared first on Allan Kelly Associates.

Cascading OKRs and White Space OKRs

A couple of weeks ago I blogged about the top-down or bottom-up question – “OKRs top-down? bottom-up? or ripples on a pond?”

The idea of top-down OKRs keeps cropping up: it needs a name. So please let me introduce Cascading OKRs, or C-OKRs for short.

I only just invented the term so I don’t use it in Succeeding with OKRs in Agile – although I do warn against the idea. The meme is in books and blogs I’ve read, in podcasts I’ve heard and it comes up again and again in Q&A sessions when I do presentations.

The Cascading OKRs idea goes like this: the people at the top of the organisation set OKRs. These are shared with people and teams “below” them. Those teams then write OKRs to support the delivery of the those above them. Their OKRs are in turn shared with “lower” individuals and teams who repeat the processes.

I’ve even heard it suggested that teams take the OKRs from above and use the key results as their objective(s). The key results they create around these objectives can then be used by “lower” teams as their objectives. Hence OKRs cascade down the organisation. (And we all know what Cascades look like don’t we?)

Undoubtedly this interpretation has its own logic – both in the top setting the master OKRs and the lower levels implementing them. It is after all functional decomposition. And I must believe from what I hear that some companies do it this way even if I have never seen it myself. One hopes that it works for these companies, I think it can be better.

C-OKRs are incompatible with the agile mindset because it deprives teams of autonomy. Each team must implement the objectives given to them regardless of what the team believes, regardless of what the team’s customers are asking for, irrespective of the research the product owner/manager has done.

In reducing, even eliminating, autonomy motivation is going to fall too, teams are no longer their own masters.

Nor will this way increase agility because each team must move in lockstep – or perhaps one step behind – the team above them. The cascading hierarchy injects delay.

Cascading OKRs may be easy to grasp, they may be easy to sell, they may follow the logic of hierarchy and management-by-objective but that also means they represent a lost opportunity to integrate OKRs and agile.

Having named Cascading OKRs I need to name the alternative: broadly the approach I advocate in Succeeding with OKRs.

I name this approach White Space OKRs, WS-OKRs.

Organisational leaders should set the vision, the big-hairy-audacious-goal, the ultimate objective, the massively transformative purpose. They should name the mission, they should set the culture and talk about the purpose of the organisation.

And they should leave copious amounts of white space – space for teams to fill.

Those visions should be light on how; they should be light on orders, instructions and mandates. That may seem odd but only by leaving these things out – by leaving white space – can individuals and teams, at all levels, decide how best they can support that mission, goal, purpose or whatever you call it. Planning is disabling.

Because teams decide how to support those goals – while supporting existing customers, legacy business and technology, plus other (potentially completing) demands – team retain autonomy, and autonomy creates motivation and flexibility.

There is one more assumption underlying this which deserves mentioning.

White Space OKRs assume that the teams already exist. With WS-OKRs leaders don’t need to create new teams to deliver their goals because those teams already exist. In other words, the organisation is operating a post-projects model, e.g. product teams, continuous digital, Spotify, or maybe SAFe. That raises an issue of gaps and I’ll return to this another day.


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


White space photo from Katie Doherty on Unsplash.

The post Cascading OKRs and White Space OKRs appeared first on Allan Kelly Associates.

Sorry about the OKRs

Quick word of appoogy to regular readers who may not be interested in OKRs: sorry for all the posts about OKRs.

Its probably a natural effect of pubishing a book on the subject and then doing a bunch of presentations, webinars, workshops and Q&A sessions. Give me a few weeks and this will pass. Normal service will be resumed, with thoughts on agile, technology and such – I just don’t know when!

The post Sorry about the OKRs appeared first on Allan Kelly Associates.

Our brains want more but less is more

Less is more – I say it so often but it is still a lesson I still have to relearn regularly. Go small. You could say that my most famous blog post is saying just the same thing in fancy language – Software has diseconomies of scale – not economies of scale.

So a couple of weeks ago I was fascinated to see an article in The Economist entitled “Why people forget that less is often more” (paywall) reporting on research published in Nature “People systematically overlook subtractive changes” (another paywall) – being Nature one knows this is serious science.

The researched showed that less is more applies mentally as well as physically. That is, people are far more likely to solve problems by adding elements than by subtracting them – even when subtraction is both viable and costs less (some of the experiments introduced the idea of cost.) The researches even go as far as to suggest this isn’t just a case of believing the additive (more) solution is better than the subtractive, it appears our brains are less likely to consider the a solution which subtracts elements to create a solution.

Last year when I was struggling to complete “Succeeding with OKRs in Agile” I found a solution in removing some chapters. Some were little more than notes, some were in draft and a couple were fully written (and edited). Removing those chapters made the book less, but it made my work load less too – which had an immediate benefit.

It also meant I could finish the book sooner. It meant the copy editing process was quicker and cheaper, and it meant that the book could be published on Amazon and start earning for sooner. But I also believe people like shorter books, I really believe that I’m selling more books because it has less than 200 pages than I would if it had over 200, let alone 300.

This has a bearing on the way companies organise themselves and their processes too. When I first started talking about #NoProjects (which became Project Myopia) I really saw this as a “just remove the project model” – keep doing all the other stuff but just drop projects. Part of me still believes that and while I recognise that some places need more structure I also believe that adding projects is simply overhead for many small companies.

I see it too in the “fear of coding” that many companies have – don’t let people code! Plan it, write it down, estimate it, find the cheapest supplier, argue about it – when simply doing it would be cheaper.

I see it too in the way “agile methods” have grown. Scrum, and XP, are barely viable development models. Compared to RUP they are miniscule. But they worked. Before agile we called them “lightweight”.

Now we have SAFe and other frameworks which bring big thinking back. Nobody would call SAFe lightweight – not with its 10 principles, four configurations and five versions. Perhaps we should have stuck with “lightweight development methods.”

I think it was Alistair Cockburn who once said “Traditional methods are tailored by removing elements, agile methods are tailored by adding.” If the research above is right it was only a matter of time before someone created an “agile method” as big as SAFe.

Finally, another example of less is more: I could write more in this blog but less is more.


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

The post Our brains want more but less is more appeared first on Allan Kelly Associates.

OKRs top-down? bottom-up? or ripples in a pond?

One of the great things about writing a book is that you get a greater understanding of the subject. So it was with “Succeeding with OKRs in Agile”. In particular writing the book forced me to think about how OKRs fitted with agile and hierarchal structures. I get the impression that many people are interested in using OKRs to align teams but not everyone has worked out all the nuances.

On the face of it OKRs are hierarchal: it seems “obvious” that someone, somewhere, is going to set a big goal, that goal will cascade down and every team will end up with their own mini version of the goal. As I said, this seems obvious, how else could it be? Especially in a large organization?

After all, is that how the not so distant ancestors of OKRs, Management-By-Objectives (MBOs), worked.

This also fits the engineer’s mind: the product team have a goal, and all the supporting teams – whether contributing components or services – make their goals subservient to the one goal. The classic inverted tree with each team doing what the node above asks.

But, top-down conflicts directly with reality and with agile. Teams don’t have one goal, they don’t answer to but one leader but to multiple leaders, multiple customers, multiple stakeholders and these don’t always agree. Agile folk have long railed against command-and-control from above while advocating self-managing or self-organising teams. Surely OKRs go against this philosophy?

So, if we are to use OKRs in an agile environment these positions need to be reconciled. In Succeeding with OKRs I described the process as more bottom-up than top-down. Thus, rather than a big boss saying what should happen and that being cascaded down the origanization to provide goals at every level, I describer the big boss setting out a vision, a goal, an objective but not describing details. Then they say to the teams: “Help, how can you help more us towards that goal?”

Now, only a few months after I wrote that my thinking has moved on. I don’t disagree with myself but I see the need for a more nuanced explanation and a revised model.

First off, I’m guilty of using the language of hierarchy: top-down and bottom-up. In so doing I’m supporting the view that hierarchies are the natural state of things and creating a, possibly false dichotomy: one thing or another. For years I’ve been thinking of organisations both as federal entities and as solar systems. While the leadership team may be central to decisions they are not all powerful . Teams have their own paths, leadership and leadership teams are the sun and teams/divisions orbit them. (If I recall correctly I picked this idea up in the Henry Mintzberg book Simply Managing.)

Bear in mind, as I say in everyone of my books: team are autonomous. We stive for independent teams with devolved authority. Each team exists to deliver a product or service and each team has multiple stakeholders – of whom the big boss is but one. Each team therefore has to decide how best to deliver benefit to (potentially competing) stakeholders. Sometimes that means co-ordinating with other teams and even other companies.

Put that together: teams are creating OKRs but they are not doing it in isolation, they are listening to the big bosses at the centre but also the teams they need to work with.

Recently I’ve started to think of these concentric circles less as planetary orbits and more as waves, or ripples to be precise. The big boss at the centre makes big ripples that carry out to the edges.

But leaders are not the only ripple makers. Teams, customers and other stakeholders also have an effect – like rain falling on water. Sometimes these waves some together and magnify each other, other times they cancel each other out, more often than-not they are out of sync and disrupt each other in ways too complex to predictable.

We think of leaders as single water droplets but inreality there are lots of drops making lots of ripples

OKRs are the messaging system that allows teams to signal what ripples they are creating and which they are reacting to. Teams are iterating – OKRs reset every 13 weeks – which means every quarter teams get a chance to react to other ripples and rest their own.

Thought of like this you also get a scaling model. Not so much a model of “how to do this to scale” but a mental model which describes how to think about scaling.


I have some upcoming presentations and webinars about OKRs if you would like to know more

Or, buy the book “Succeeding with OKRs in Agile”


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

The post OKRs top-down? bottom-up? or ripples in a pond? appeared first on Allan Kelly Associates.

Presentation & speaking engagements

Agile on the beach

The attention Succeeding with OKRs in Agile has got means I’ve had a lot of invites to speak about, well, Agile and OKRs. So I am at a number of meetup groups and conferences, and odd conversation, over the next few weeks, most of which are free to attend online.

An up to date list of public speaking engagements can always be found on my website. In addition to public speaking I regularly deliver private presentations too. So please get in touch and book a date your team or company.


Reawakening Agile with OKRs

When: 6 May, 5.30pm Sydney, 8.30am London

Online presentation

Organized by SAFe Sydney, free, booking required


Reawakening Agile with OKRs

When: 11 May 2021, online presentation

Organized by BCS Change Management group – booking required (free to attend)


Succeeding with OKRs

An online conversation with Adrian Reed, 20 May 2021.

Organiser and booking with BlackMetric


Reawakening Agile with OKRs

When: 27 May, online presentation

Organized by Cambridge Agile Exchange, free, booking required


Reawakening Agile with OKRs

When: 30 June 2021, online presentation

Organized by Future of Work in Scotland, booking required


Allan Kelly at Agile on the Beach
Allan Kelly at Agile on the Beach

Reawakening Agile with OKRs at Agile on the Beach conference

First live, in person, event since March 2020 – with beach party!

Sept 2, 2021, tickets on sale now

The post Presentation & speaking engagements appeared first on Allan Kelly Associates.

Developer becoming a product owner/product manager?

Product Owner choosing postits

A few weeks back I had an e-mail exchange with a blog reader about the product owner role which I think other readers might be interested in, it is a question that comes up regularly with clients. In this context the product owner is a product manager (regular readers know I consider product manager to be a subset of product owner).

Reader: This makes me think that the [product owner/manager] role is indeed super hard. Do you have a view on hiring versus training internally?

I’ve had great success with moving people from development into product owner/manager roles – I did it myself once upon a time. And I remember one developer who’s face lit up when I asked if he would like to move to a product role. A few years later – and several companies on – I got an e-mail from him to say how his career had flourished.

When to many the move looks obvious it is actually far harder than it looks and there are pitfalls.

The key thing is: the individual needs to leave their past life behind. Changing from developer to product owner/manager is changing your identity, it is hard.

The mistake that I see again and again is that the individuals – sometimes encouraged by those around them – continue to wear a developer hat. This means they don’t step into their new identity. They spread themselves thinly between two roles and their opinion divided. They seem themselves as capable of everything rather than specialist in one so don’t devote the time to both learn their new role and mentally change their perspective.

Imagine a hybrid developer/product manager comes back from lunch and has three or four hours spare – of course this never happens but just run with this thought experiment. Are they best: (a) pulling the highest priority item from the backlog and getting it done, or, (b) reviewing the latest customer interviews, site metrics, and perhaps picking up the phone and calling an existing customer?

Coding up a story clearly adds value, it reduces the backlog and enhances the product directly. Picking up the phone and analysing data may not have an immediate effect or enhance the product today, the payoff will come over weeks and months as better decisions are made and customers served better.

Product owners/managers need to empathise with customers and potential customers, they need to feel the pain of the business and see the opportunities in the market. Skilled coders feel the code, they hear it asking to be refactored; they dream about enhancing it in place; they worry about weaknesses, the places were coupling is too high and tests too few. In short, coders empathise with the code.

It is good that product people empathise with customers and coders with the code. But what happens when those things come into conflict? The code is crying out for a refactoring and customers demanding a feature? Ultimately it will be a judgement call – although both side may believe the answer is obvious.

If the code is represented by one person and the customer by another then they can have a discussion, balance priorities and options. If you ask on person to fill both roles then they need to have an argument with themselves, this is not good for their mental health or the final decision.

These problems are especially acute when the developer in question is either very experienced or very good – or both. They come to represent the product and champion it. But that makes the balancing act even more difficult. It also means that those understand when a No is a no because there is no business justification and when No is no because the code is a mess.

Hence I want the roles of developer and product specialist kept separate.

In a small company, say, less than 10 people, it can be hard to avoid this situation. And when the product is new technology or and API it is often difficult to disentangle “what the customer will pay for” from “what the technology can do” but those traps make it more important that a company addresses this when it grows.

So my advice is simple: the key thing is that the individual changing roles needs to put coding behind them – and step away from the keyboard. I know that seems hard but to fill the product owner/manager role properly one has to live it.

I usually recommend the person in question away for training. And I do mean away (lets hope we can travel again soon!). The person changing roles needs to immerse themselves in their new life. Sitting in a classroom with others helps make the psychological switch.

When I did it – with Pragmatic Marketing (now Pragmatic Institute) – the training was difficult to get in Europe so I went to the USA which added to the experience. Product manager culture is more developed in the USA than elsewhere – and even more developed on the West Coast simply because it has been there longer.

Going somewhere different and immersing yourself in a new culture and new ideas is a great way of breaking with your past and creating a new identity for yourself.


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

The post Developer becoming a product owner/product manager? appeared first on Allan Kelly Associates.

OKRs in Agile infrographic

I am indebted to Yoan Thirion for created this infographic to illustrate Succeeding with OKRs in Agile. He’s done a brilliant job on both the graphics and the summary – undoubtedly better graphics than I could have done and probably a better summary than I would too, sometimes one can be too close to a thing.


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

The post OKRs in Agile infrographic appeared first on Allan Kelly Associates.

What is it with Business Agility?

Top of my Slack channels is the Business Agility Institute, just below that is the old #NoProjects slack that sometimes comes to life. Recently someone on #NoProjects asked:

Q: What do you guys think about Business Agility?

My reply: Business Agility, bit like apple pie, how can one not be in favour?

Of course, what flavour of business agility is another question. Lots of people seem to use the words “business agility” but I’m not sure there is a consensus on exactly what it is. I am a member, and supporter, of the Business Agility Institute which was founded by Evan Leybourn who also published a NoProjects book.

Evan and I were in regular communication while we were writing our books, we both saw the flaws in the project model and both arrived at the conclusion that as the business world digitalises business is never done therefore technology is never done. In essence that is the genesis of Continous Digital. While I wrote a book on the subject Evan founded the Business Agility Institute.

Q: So whats your take or how you think business agility is different from no-projects? is people just rebranding stuff to BA now?

My reply: Business Agility is good, it makes sense to go “up” from software to the business. Now look at the things you might want from Business Agility:

▪ Quick to market

▪ Fast to deliver

▪ Responsive to customers

▪ Reactive to trends and changes

▪ Efficient/effective

▪ … add your own here…

Isn’t that what any business wants? Whether you call it Business Agility or not? – these are apple pie things, hard to argue against and if you read (almost) any management textbook in the last 30 years they say the same things.

These aren’t #NoProjects, that is a very specific critique of the project model. Some people may have believed that projects facilitated those things, however what #NoProjects says is: the model is flawed, if you want those things you need to find another way. For me that other way is Continous Digital, which is why my presentations talk of #NoProjects evolution: it is not enough to say “projects don’t work”, one needs to suggest an alternative.

So how is Business Agility different?

First off: even if the things Business Agility offers aren’t new the rise of Business Agility is a new opportunity to push an agenda which is good, sometimes things need to be “rebranded” as new to get attention. Should’t be but there you are.

Second, the methods have changed: two forces at work here, Digital and “Millennials”

Digital tools – driven by Moore’s Law and the falling price of CPU power – have changed the way business works, it means that the things executives often want to avoid, software development, is now the power house of your business.

Hence, “the business is the technology and the technology is the business.” Think Uber: how do you separate Uber’s technology from Uber the taxi company?

This is why I have take to saying “IT is dead, IT’s Digital”. Information technology in business is no longer a cost centre, it is no longer “just” and enabler for business services, Digital means it is the business, it is were innovation happens and it is a driver of revenue and profitability.

That also means “Agile Methods” (a la software engineering) come into focus because a) you need to create software and b) as digital tools permeate every aspect of business life agile becomes more applicable.

Agile methods are the processes that maximised the benefits of digital tools. Agile started with software engineers (and friends) because they had early access to digital tools (email, IM, VOIP, web, wiki, etc.) and are able to create “missing” tools

Millennials: those born about 2000 are said to want more meaning, purpose and autonomy in their work. Personally I’ve always wanted these things and I think everyone does. Whether I am right or not this is a trend which has been running for a while, millennials exhibit this most clearly. (Plus the pandemic adds to this)

This too fits with agile because agile methods recognise the people aspect, people in agile are not plug compatible (although we do encourage a more team based approach.). Agile considers motivation and recognise those doing the work as experts in their own right – are better at addressing that need.

Hence, and a point I’m making in my “Reawakening Agile with OKRs” presentation which I’m delivering this year, we need to think more about purpose driven development – PDD. Our software needs purpose so our people have purpose.

Ultimately, while business agility might not be anything new there is a greater need for it.


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

The post What is it with Business Agility? appeared first on Allan Kelly Associates.

OKRs in Agile Q&A part 2: The Backlog

Continuing from my last post and more questions arising from my Reawakening Agile with OKRs talk.

In my OKR book I advice teams to forget about the backlog and instead use the OKRs as a story generating machine. As I expected, this grabs people’s attention. For many this might be the most surprising piece of advice in the boo, and perhaps the most controversial.

So it is hardly surprising that there were several questions around this:

Q1: If the backlog isn€™t a reflection of what we need to do in order to move towards our vision what is it for?

Exactly. If the backlog does not reflect your vision then what is the point of a backlog?

First off, if the backlog is aligned with your vision, and things are working well then why change? Certainly don’t add OKRs unless they are addressing a problem, and when you add OKRs see if there is anything else you can remove. If OKRs are simply repackaging the backlog then why both? Why add to the tools and processes in use?

For a few fortunate teams that is indeed the case. However, for many teams the backlog also contains a multitude of work which is not part of the vision and requested fixes. The backlog long ago became a dumping ground for requests.

Yet removing work from the backlog becomes hard. Product Owners feels they lack the authority or confidence to actually say “No, we will not do that.” At the same time the teams performance is judged by “how much backlog” gets done. Success or failure come down to “is the backlog done?” Thus the backlog comes into conflict with the OKRs.

In the book I introduce Jeff Bezo’s “Day 1” approach where company works as if today is the first day and questions what they are doing. OKR setting needs to be a day-1 experience.

Q2: Backlog needs reviewing to align with OKRs, surely?

That is one approach, set the OKRs and then before or during every planning meeting comb through the backlog and find work which will move you towards the OKR. That will work if you have a few dozen items in the backlog but what if you have a thousand or more? What if the backlog has been passed down from a previous product owner or a requirements document? In both cases that work will be harder.

The bigger problem is: what if you think of something that is not in the backlog and will move you towards the OKRs?

Do you say No?
I expect not, I expect you will quickly write it, slip it into the backlog and say “look what I just found”

Now the backlog is a collection of ideas which might, or might not, help achieve the OKRs but which you might not do.

At which point, what is the point? Why not just brainstorm what you can do?

Q3: Isn’t OKR then a guidance to create Backlog? or prioritize it?

Create a backlog, yes, the OKR is guidance to create a backlog – its a story generating machine. So what is the point of having 500 stories which describe work not related to the current OKRs? Will not get done anytime soon? And likely will never be done? But which confuse the governance process and drawn everyones morale because “we still have 500 PBIs to do.”

Once you have your OKRs then there is little point in creating any more backlog then you will do in the next three months. You may generate 12 months of work but since OKRs are reset every three months the chances are three quarters of those stories will be thrown away.

So every quarter reset the backlog and start over. That is pretty much what I’m advocating.

Prioritizing the backlog, see Q2 above.

Q4: How have you approached the removal of backlogs? small experiment?
Q5: Have you done this in real life? How did you persuade people?

OK, you found me out, we didn’t actually throw the backlog away. There was some history in there which was useful and more importantly it would have drawn too much attention to the team. Instead we just ignored it.

This started as a small experiment between me – as Agile Coach – and the Product Owner: we just opted to ignore it.

We set the OKRs based on current priorities and strategy. Then in the planning meetings if we knew of a story in the backlog we pulled it up. But actually, this turned out to be more work than it was worth. Plus, by challenging the team we got better answers and more involvement.

It didn’t take long before the team noticed what was happening but I don’t think they minded much. Again they might say “O I know there is a story in there to do…” but more generally we just wrote new stories there and then: the OKRs were a story generating machine.

In the book I describe a further experiment I ran with another coach, as a result she came to the same conclusion: OKRs before backlog. While we shared this with other coaches – and indeed anyone who wanted to talk about it – we didn’t make a big fuss or publicise it. I’m doing that now.

Succeeding with OKRs in Agile

I see this approach as the logical conclusion of working with OKRs so I don’t think you need to make a fuss. You can just do it and I expect more teams to reach this conclusion. Except of course, those backlog-slaves who are labouring under corporate agile to burn-down the backlog!

Succeeding with OKRs in Agile is available in print or ebook format from Amazon now, an audio version will be out in the next few weeks. I will be repeating Reawakening Agile for Agile Newbury next month and discussing OKRs with Adrian Reed in May.


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

The post OKRs in Agile Q&A part 2: The Backlog appeared first on Allan Kelly Associates.

OKRs in Agile Q&A (part 1)

It shouldn’t surprise you to learn that I’m doing a lot of talks about Succeeding with OKRs in Agile at the moment. Last Tuesday spoke to Digital Transformation in London and Lean Agile Coaching London groups (a joint Meetup). At the end there were a lot of questions and I didn’t get to answer them all – in fact more have come in on mail and twitter since. I’ll try and answer them here, but there are so many questions I need to split this post in two.

If you missed the presentation the slides are online and there is a recording on YouTube. Alternatively I’ll be presenting again at Agile Newbury in April and the Craft Conference in May.

Q: You said “the companies which make the most profits don’t aim to maximise profits.” Do you have any references for that?

A: I’ve heard this argued several times, although its not a clear cut case because you can’t do an experiment and profit isn’t always the best measure of commercial success. You might look at share price, or earning per share or several other measures.

The most recent – and probably the best – evidence I’ve seen is from Alex Edmunds in his book Grow the Pie. Edmunds argues that profits are but one part of the value created by companies, those who focuses exclusively on profits neglect the other parts, society looses out, and profits are less than they could have been.

The good news is Edmunds presents lots of evidence, and counter evidence. The bad news is: that can make for a lot of reading – sometimes dry.

John Kay in Obliquity makes a similar point in a more readable book but one that lacks so much hard research. Another book worth reading on the subject of profits and value is Mariana Mazzucato, The Value of Everything.

Q: Where I’ve seen companies use OKRs they are set by the people at the top and passed down the organisation. Surely letting teams set their own OKRs would loose alignment?

Yes, I get the impression that this is what many companies do. But to my mind that is little more than a re-invention of MBOs (management by objective) and ignores agile. Agile demands that teams be given real responsibility and authority.

As for alignment I would rather the organisation put its efforts into removing the need to align, removing dependencies and building independent, autonomous teams. (I’ve written about Amoeba teams and the MVT model before.)

This is not to say alignment isn’t important but it is secondary. First you want teams which are delivering benefit, when you have that you can seek to optimise them.

Succeeding with OKRs in Agile

Q: How do OKRs work in organisations with large numbers of teams who need to resolve competing visions and priorities but who depend on each other?

Q: To what extent should OKR’s be negotiated – either between teams (where Team A is dependent on the output of Team B); or between senior management and Teams?

OKRs aren’t a silver bullet. Yes OKRs can help, because OKRs define an API to the team you can tell others what to expect. Better still, you – or your product owner – can consult and negotiate with those other teams and find out what they need.

The ultimate answer is not better co-ordination or even communication, it is removing those dependencies, making teams more independent. Conflicting OKRs will highlight those problems but aligning those OKRs will never be a complete solution.

What you absolutely must avoid is having one person, or a small cadre of people, decide what each group needs and issuing OKRs to others to fulfil it. That destroys team independence, the aim here – in agile, in the twenty first century, in digital business – is independence.

Some people talk about these ideas under the title “Descaling the corporation.” This about increasing team coherence and reducing coupling. Corporation need to reduce the connections and dependencies.

Q: How granular should OKRs be (in terms of departments), e.g. should you have separate OKRs for Product and Customer Success? Even though they are both partially responsible for renewals?

I’d have to look at the context here but in general I would rather remove that distinction between those departments. Your aim is “customer renewals”, the question is “what can we do to increase renewals?” – maybe that is best achieved through a product enhancement, maybe through helping customers succeed or maybe though something else. Don’t just span boundaries, rethink them. Start with the outcome and work back rather than starting with your own structure.

Q: How to start to introduce OKRs in corporate environment?

Q: What can be a first step with OKRs in deeply traditional company?

As always start small, run an experiment. However, there is a difference to agile. My approach to agile has always been very much “just do it.” There are lots of agile practices and you as an individual can just start adopting them, in time you can involve other people . Its far easier to introduce agile bottom-up than top-down.

But with OKRs things are a little different because OKRs are a team level tool. So right from the start you need to take your team with you. Second, because OKRs represent a communications interface – a team API if you like – and because Agile OKRs require respect for team autonomy you need someone a little higher up to support the move. That someone should be able to provide “air cover” for your experiment.

Once you have those positions in place then just try it, run an experiment for a quarter or two. Hopefully you will be able to see success which can propel you further and help enrol others.

One technique I’ve used before it a book study group: gather some people who are interested in learning and improving. Choose a book – my OKR book being the obvious choice! – and meet (lunch time if you want) every two weeks. Work through the book together, discuss every chapter.

I don’t think that prescription changes if the company is “deeply traditional” – although I expect the journey will be harder, you may have more trouble recruiting companions or securing air-cover.

Q: How do you deal with resistance of change in organisations?

Unfortunately there is no silver bullet. I feel introducing any change is often an exercise in throwing mud at a wall, or even banging your head on the wall. The level of personal perseverance can be very high, make sure you celebrate every win no matter how small.

Perhaps the best advice I’ve ever heard comes from the head of the IMF, Kristalina Georgieva, she was asked a similar question in a Financial Times interview last year: “The mistake we often make is to try to zero in on the naysayers and try to convince them, rather than empower and excite the agents of positive change and just ignore the noise.”

Q: How much would you like SMART kind of goals comparing to OKRs?

Most of SMART – specific, measurable, achievable, relative and time-bound – works, although more at the key results level than the objectives level. I would take issue with the A though – achievable or attainable depending on your preference.

Really you want goals which are a bit more than you think you can do. Otherwise you get a problem that economists call satisficing: people aim low, they play it safe as a result the whole exercise becomes a game play.

Now each organisation needs to make a call on what level of balance they expect. Google apparently only expect 70% of OKRs to be achieved, they lean towards more risk, less predictability and more misses.

I do think it is important that leaders stand up and say very clearly what they expect from teams using OKRs. Is the company challenging teams to do their best and accept some failures will occur? Or does the company value predicability and accept some slack in the system? Both are valid choices.

Q: How do you come up with the hypothesis of the Key Results?

Good question, and it is not one confined to OKRs. I’m going to duck the question and suggest you read Barry O’Reilly on Hypothesis Driven Development.

Q: It sounds like you view OKRs as a “root and branch” replacement – its all or nothing?

Maybe. Hopefully.

No, I think you can add OKRs to an existing agile system – that is what I was part of originally. But, once you start working with OKRs and once you start following the logic of OKRs, that is where you end up.

I’ve arrived at a point where I hope OKRs are the basis for a big change in the way we do agile. As I said at the start, many companies do a form of “corporate agile” which lacks the high aims that many of us who dreamed of when doing agile in the first decade of the millennium.

Q: Why do you think the corporate agile virus exists and what is the cure for it?

I could give you a dozen reasons and the truth will still be something different. Let us be clear, corporate agile is better than what went before but it falls far far short of what we dreamed about at the start of the millennium. Right now the biggest problem is probably scaling, companies want a high R-value but in chasing agile working they are getting teams with a very low E-value (effectiveness.)

The cure is the one true test of agile, ask the question: Are we still working the same way we were three months ago?

If you are (the same) then you are not agile. Agile is about learning and changing, hopefully for the better but there will be some backwards steps. Learning creates change and change creates learning – experiments help. Keep learning, keep trying new things, keep changing.

Q: How is this different from the OKR we apply to Strategic themes in Lean Portfolio Management?

I’m not familiar with Lean Portfolio Management so I can’t really comment. Quite possibly it is an alternative implementation of the same ideas.

Q: What if a company has Vision & Mission, and KPIs (company wide, squad wide). should we implement OKRs also?

First: are those things giving you what you want? If so then leave well alone! You could conduct an experiment with OKRs, take a couple of teams, relaxed the other metrics and let them run with OKRs for a year then look at the results.

I don’t know how exactly you are using vision and mission but I would assume you retain them. OKRs are about delivering, in the next three months, progress against your missions which themselves build towards your vision. They should all be expressing your purpose in different words over different periods.

KPIs is more tricky.

To my mind KPIs are a measuring tool, they are a way of saying “We are 1.4 meters high.” In that sense they are compatible with OKRs because you would just have an OKR to advance an KPI, “Objective: increase KPI to 1.8m.”

However, if you are using KPIs as targets things are different. They are overlapping with OKRs, in which case use one or the other.

More worryingly you might hit Goodhart’s Law, goal displacement or satisficing. These are problems I discuss in the book in-relation to OKRs but they are not confined to OKRs.

Finally, mission, vision and KPI already sounds like a lot of competing techniques, if you are going to add OKRs please look again at how you manage “objectives” (in the broadest sense). You may have too many mechanisms. If you are adding OKRs be ready to remove something.

Q: What would you say is the biggest regret / challenge in Succeeding with OKRs in Agile? Something you wish you could have done differently?

Half of me wishes the book was smaller: I believe people are more likely to read (and buy!) smaller books. In terms of getting this message out there I think smaller is better.

The other half of me wishes the book was longer: there is more I have to say, some chapters were left “on the cutting room floor”. So there may be a sequel with these and some new chapters. Plus, a rewrite of a few chapters were I think the message could be reduced and made clearer.

Q: What is / will be the #-tag for these better smarter corporate agile virus enhancing OKR?

Ha ha, I was burned by #NoProjects, it made me famous but I still have the burn scars. So I am absolutely no going to say #NoBacklogs – although you could read that into some of my work.

Increasingly I think Agile needs to lay claim to bottom-up OKRs, not the MBO-lke top-down OKRs which I see some adopting and even hear being advocated. So maybe #AgileOKRs.


Succeeding with OKRs in Agile is available now in print and e-book versions from Amazon.

Audio book coming soon


The post OKRs in Agile Q&A (part 1) appeared first on Allan Kelly Associates.

Purpose over Backlog

Backlogs are a good idea. Backlogs ease the transition from the old “requirements up front” world to the new more dynamic agile world. Backlogs provide a compatibility layer for agile teams to interface to more traditional project management and governance. Backlogs even allow you to take a stab at done date!

Backlogs allow you to even out work between the quiet periods and the busy times. Backlogs give you a place to store good ideas which you can’t do just now. And because stakeholders can see their request is not forgotten they don’t need to shout for it today.

Yes backlogs are good. I’ve seen them work well myself and I’ve taught many teams to effectively use backlogs.

But – you knew there was a but coming didn’t you? – but…

Backlogs have problems, too many teams are labouring under the Tyranny of the Backlog, they have become backlog-slaves and practice something we might call BLDD – Back Log Driven Development.

(To be clear, when I say “backlog” I am primarily thinking of the product backlog – the long list of all the things the team (might) do in the future. This is different to the sprint backlog (iteration backlog). The sprint backlog is a shorter list of things the team aims to do this iteration. I am using Scrum terminology but the ideas are pretty much “generic agile” and I’m thinking more broadly than Scrum. Many implementations of Kanban feature a product backlog of sorts so while Kanban is less prone to these problem it is not immune.)

1) Lump of Work Fallacy

There is usually an assumption that the backlog represents all the work to be done – an impression reinforced by early implementations of Scrum. In the short term that leads to agile teams being seen as inflexible and prioritising process over need because new work is not allowed in.

In some cases teams even struggle to get started on work because a big-up-front requirements gathering and analysts activity is required to create a backlog. In the worst cases that work is even estimated and end-dates forecast before a line of code is cut or developers hired.

In the longer term it is simply unrealistic to assume the backlog is fixed. Even with more and better analysis it is impossible to foreseen future requests. The agile adage “it is in doing the work that we understand the work” cuts both ways: coders understand what they need to build and customers/stakeholders/analysts understand what they want.

Work will arrive after you begin, any system that does not incorporate that truth will fail one-way or another.

2) Bigger then you think

Not only does the backlog grow with completely new work the work in it changes – and grows. There are many reasons this happens: new opportunities appear, hidden ones become clear, requests require more work than expected and so on.

Humans are very bad at estimating, especially about the future, and, it turns out, they are also very bad at estimating time spent in the past. If you want accurate forecasts you need to invest in them, you need to make structural changes and you need to use statistics.

However, because of the lump of work fallacy and the belief that humans can make estimates, poor end-date projections get made and when they are missed (because they were wrong to start with) everyone gets upset.

3) Fallacy of Done

Backlogs come with burn-down charts and an assumption that there is an end; and that end is when everything is “done.” The team will be done when the backlog is empty. That assumption is baked into BLDD, traditional project management and even governance.

I have long argued that software is never done. I’ll accept that I might be wrong, but in the digital age, when business runs on digital technology (i.e. software) your products are only done when you business is done. The technology is the business, and the business is the technology. Stop the backlog growing, stop growing you technology and you kill the business.

4) Backlog Bottomless pit

Put all those reasons together and the backlog becomes a bottomless pit. In the early days of agile, when I managed teams myself, the backlog would often sit on my desk, written out on index cards and held together with rubber bands. I could get a sense of how big the backlog was my looking.

Today everyone uses electronic tracking systems. Not only do these allow an infinite number of items they rob us of perspective. To paraphrase Comrade Stalin: “2 outstanding backlog items is tragedy, 200 is a statistic.”

5) Backlogs obscure strategy & purpose

With so many backlog items it is easy to get lost – you can’t see the wood for the trees. Arguments over what will be done next start to resemble deciding who should get a lifeboat place on a sinking ship, add in the demands “when will you be done?” (plus explaining why the date has changed) and “the bigger picture” gets lost.

In Back Log Driven Development the sense of purpose and strategic goals is lost as teams struggle with the day-to-day demands of just doing stuff.

6) Powerless product owner (i.e. backlog administrators)

Tyranny of the backlog seems worst were product owners lack real authority and skills. They are little more than backlog administrators. They spend most of the week adding requests to the backlog, then passing a few chosen items to developers in planning meetings. A vicious circle develops, the product owner can’t win so people trust them less, their authority wanes, and the backlog spirals.

Few organisations give product owners the power needed to get a grip on this situation. Indeed, many product owners are plucked from the ranks for development or support and given a battlefield promotion to product owner but lack the skills required. (See The problem with Product Owners.)

A solution?

For years I’ve been suggesting teams throw away the backlog – you will not forget the important things. But then how do you know what to do?

Take a step back, start with your purpose, your mission, the reason you team, your company, your organisation exists. What should you be doing? How can you fulfil that purpose and sever your customers?

This is where I see a role for OKRs and jobs to be done. Both these techniques – together, or separately – can be used as story generators. Every time you need to more work, more stories, you return to your OKRs and ask “what can we do now to move us towards our objective?”

When writing Succeeding with OKRs in Agile I became more and more convinced this is the path to take. Increasingly I sum this up as Purpose over Backlog.

Step 1: Clarify your purpose – what is your overarching reason for existing?
Step 2: Clarify how your existing strategy builds towards that purpose, and if you don’t have a strategy create one.

Repeat steps 1 & 2 annually.

Step 3: Think broadly, set your OKRs as a team so you build towards your purpose by following your strategy.
Step 4: Spend the next 12 weeks executing against those OKRs

Repeat steps 3 & 4 every 3 months.

Step 5: In each planning meeting take stock of what you have done and progress against OKRs
Step 6: Ask “what do we need to do next to move towards the OKRs?”

Succeeding with OKRs in Agile

Repeat steps 5 and 6 every 2 weeks

And if you are Kanban’ing then keep steps 1, 2, 3 and 4, adjust 5 and 6 as appropriate.

Having finished, completed, published Succeeding with OKRs I really wish I had been clearer in the book. The ideas are there but with time they have become so much clearer… maybe I need another book.

Buy Succeeding with OKRs in Agile at Amazon today.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Purpose over Backlog appeared first on Allan Kelly Associates.

Technical Debt: Engineers, you are not alone

I don’t read many books about software or technology these days, I tend to read outside the domain: economics, business and management – which after all is much of what I do in the technology world these days.

Recently I’ve been reading Winning now, winning later by David Cote and find really interesting. He hardly mentions software and never mentions agile but he is giving me a new perspective on technical issues, particularly technical debt (or technical liabilities as I prefer to call them). He talks about issues which have similar characteristics to tech debt but are completely different, legal issues for example. He sees these issues as conflicts between short-term thinking and long-term thinking.

Cote’s argument is that short term actions should support, not conflict, with long term goals. I agree. It might not be easy but if actions in the hear-and-now conflict with longer term goals then the chances of reaching those goals is diminished.

Cote is writing about his time as CEO of Honeywell – a US industrial conglomerate if you don’t know. Unusually Cote is honest about many of the dirty problems the company faced when he took over – a lot of business books glossy over such problems or talk about “challenges” or “opportunities”.

For example, Cote describes how Honeywell managers were chasing numbers and targets every quarter. They had no time for long term improvements because they were so busy “making the numbers”. One of his managers cut down a forest to sell as timber in order to make the end of quarter numbers. Sales people would give products away to new customers or offer large discounts at the end of the quarter. However customers knew this would happen so delayed orders until they were sweetened.

Making the short term numbers meant the company undercut itself so lost revenue next quarter. Management time was spent finding accounting tricks to “make the numbers” rather than improving the business. And since targets ratcheted up the next quarter was more difficult and required more diversions.

Other examples included legal cases Honeywell was fighting: spending time and money on lawyers, building up bad will with customers, politicians and local people. This in turn made it more difficult to get support when the company needed it.

I read these examples, and others, and I hear an engineer saying “Technical debt.” That is exactly what it is.

A software engineer who does a dirty job on a code change because they feel under pressure stores up problems for themselves and future engineers who need to do the next change. Which is exactly the same as a factory which dumps waste into a lake as a quick fix and then needs to clean up the late later.

Actually economists have a term for this: externalities. These are the costs which are forced onto other payer, e.g. the factory saves money on waste disposal but the local government has to pay to clean the lake. I’ve long thought a lot of “technical debt” could be considered an externality because it pushed the cost onto someone else.

Today it is probably harder than ever to escape these cost – in code, in law, in financing – because there are more and more people out there looking for these things. Environmentalists look at waste in lakes, society expects companies to pay if they pollute and courts make companies pay. Smart investors will look closely at a firms accounts and discount the firm, or short them, if they see dubious practices.

This is Cote’s argument: in the short term it might save or generate money to fight legal cases (deny deny deny), sell off forests, discount sales and such, but, in the longer term – and the longer term might just be weeks – it will costs. And when it costs it will damage growth.

Doesn’t that sound just like technical debt/liabilities?

Naturally it is hard to see a company that chases numbers, pollutes and fights all legal claims caring about the quality of code. Engineers will have a hard job fighting for technical excellence there.

Cote argues, and I agree with him, that it doesn’t have to be this way. Acting responsibly and thinking about tomorrow – whether that is pollution, sales, accounting, code quality – will make it easier to grow later. Just because it is difficult to act in a manor that meets todays needs and make the world better for tomorrow does not allow use to ignore it: all of us need to think harder and find a solution that doesn’t mortgage tomorrow.

And sometimes the right answer is to accept the slow path, take it on the chin, pay the cost you’ve been avoiding. For Cote that mean settling legal cases and accepting some costs, for software teams that means doing the refactoring, rewriting a module or just saying No to more changes.

As I’ve said before: in software the long term comes along very soon.

As as I’ve blogged before there is no such thing as quick and dirty, only dirty and slow.

We might talk about debt/liabilities but really we are talking short-term v. long-term, a pay-day loan v. investment. Engineers have an unfortunate habit of talking about technical debt as a binary good v. evil debate with no other options.

Finding these less obvious paths which satisfy the short-term and long term is hard(er) but also offers the opportunity for higher, and longer, term improvement, something which is itself a competitive advantage.


Subscribe to this blog by e-mail and download Project Myopia ebook for Free

The post Technical Debt: Engineers, you are not alone appeared first on Allan Kelly Associates.

Warning signs of a failing outsourcer

It is 2021 and unfortunately on Friday I felt the need to repost “Dear Customer, The Truth about IT“. Little has changed in the 10 years since I wrote the original – if I was writing it today probably the only thing I would change is “IT”, I’d write “Digital” (I should probably also change Manchester United but …).

Unfortunately the vast majority of supplier’s are engaged on the basis of their marketing materials, sales pitch and promises. This tells you nothing about their actual ability to deliver working software. The suppliers can all hire great marketing people and use the same words. They can hire and incentivise the best sales people, and they can all take you out for a good meal, a round of golf or to a strip-club. (O, and they can all find a few “satisfied customers” to provide a testimony.)

The only real way to know if a supplier can deliver is to see them in action. So how can you tell things might be going wrong? What are the warning signs?

With help from Mike Burrows and John Clapham I’ve came up with this list of early warning signs. We were thinking in the context of a client-supplier (outsourced) relationship but many of them apply if you are working with internal teams too.

Staffing

1) Supplier loads teams up with extra managers: test managers a speciality
1.1) Team members don’t make decisions and defer problems to managers: there is a manager for every problem
1.2) Offshore teams have parallel management hierarchies
1.3) Suppliers feel the need to mark all your managers with their own manager (who is then duplicated offshore)

2) Inverted staffing pyramids (few devs at the bottom, lots of managers, BAs & other non-coders above)

3) People get swapped by suppliers with little notice
3.1) Short term substitutions are made: I once saw a supplier bring in a temporary SAP HR consultant to cover the usual consultant’s 2-week holiday. There was no way the substitute could come up to speed in that time let alone contribute positively.
3.2) People bait & switch: the people you meet first met didn’t last long, they were substituted for inexperienced people
3.3) “I can do that” – you get people new to their role, you get who they have available, people with experience in one role fill another role; a project manager plays coach, a delivery manager plays scrum master

4) Part time assignees (particularly managers): work a few hours a week on the project, see 1.1.

Get ready

5) Long running “set up” phases
5.1) You spend longer pondering the future than the time it takes to create the future
5.2) A lot of time is spent agonising about infrastructure changes rather than just doing them
5.3) Team advocates for, and does, investment in infrastructure and “reusable code” before anything is usable is actually delivered

Reporting not delivering

6) Supplier does not deliver working software

7) Supplier does not deliver working software every two weeks

In 2021 delivering working software to production every two weeks, or at least usable, potentially releasable software, is table stakes. The best teams deliver multiple times a day. If the supplier can’t deliver something by the end of week 4 you have a second rate supplier. Get out now.

8) Reporting hours done rather than demonstrating working software and stories

9) “Watermelon report” Green on the outside when everything inside is Red; impressive looking reports which don’t distract from the fact that nothing, or very little, was actually complete
9.1) Claiming stuff is done when it hasn’t finished testing
9.2) A Definition of Done which leaves work not-done – Mike has a good post at agendashift.com/done.

Other warning signs

10) You invest as much time in their org design as your own, if this starts to include people performance monitoring and management what are you gaining over using your own people?

11) Suppliers always say yes: no push back and no negotiation, feedback and scrutiny of your requests are signs they are paying attention to your needs. It you ask for the impossible it is better the supplier tells you so than accepts what you ask for. Ideally you want a supplier who can highlight the difficulties with your suggestion and work with you to achieve something akin to what you want even if you have to rethink your request.

12) Your own people are disenfranchised/disgruntled/frustrated by the arrangement. Particularly noticeable where people are expected to work in a different time zone to suit the other partly and when outsourcer staff are elevated (faster, smarter, etc) over the existing people.

In most of these cases the supplier is working around their own constraints rather than putting your needs first.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Warning signs of a failing outsourcer appeared first on Allan Kelly Associates.

Dear customer, the truth about IT

10 years on I feel the need to repost this classic letter from the IT industry to our clients.

Audio version, read by Allan Kelly.

Dear customer,

I think it’s time we in the IT industry came clean about how we charge you, why our bills are sometimes a bit higher than you might expect, and why so many IT projects result in disappointment. The truth is that when we start an IT project, we don’t know how much time and effort it will take to complete. Consequently, we don’t know how much it will cost. This may not be a message you want to hear, particularly since you are absolutely certain you know what you want.

Herein lies another truth, which I’ll try to put as politely as I can. You are, after all, a customer, and, really, I shouldn’t offend you. You know the saying “The customer is always right”? The thing is, you don’t know what you want. You may know in general terms, but the devil is in the detail – and the more detail you try to give us beforehand, the more likely your desires are to change. Each time you give us more detail, you are offering more hostages to fortune.

Software engineering expert Capers Jones believes the things you want (‘requirements’, as we like to call them) change 2% per month on average – thats close to 27% over a year once you compound changes. Personally, I’m surprised that number is so low.

Just to complicate matters, the world is uncertain. Things change, and companies go out of business. Remember Enron? Remember Lehman Brothers? Customer tastes change. Remember Cabbage Patch Kids? Fashion changes, governments change, and competitors do their best to make life hard. So, really, even if you do know absolutely what you want when you first speak to us, it is unlikely that it will stay the same for very long.

I’m afraid to say that there are people in the IT industry who will take advantage of this situation. They will smile and agree with you when you tell them what you want, right up to the point when you sign. From then on, it’s a different story; they know that changes are inevitable, and they plan to make a healthy profit from change requests and late additions at your expense.

While I’m being honest, it is true we sometimes gold-plate things. You might not need a data warehouse for your online retailer on day one. Yes, some of our engineers like to do more than what is needed, and yes, we have a vested interest in getting things added so that we can charge you more.

It is also true that you quite legitimately think of features and functionality you would like after we’ve begun. You naturally assume something is ‘in’ when we assume it is ‘out’. And, in the spirit of openness, can you honestly say that you’ve never tried to put one over on us? (Let’s not even talk about bugs right now: it just complicates everything.)

Frankly, given all this, it is touching that you have so much faith in technology to deliver. But when IT does deliver, does it deliver big. Look what it did for Bill Gates and Larry Page, or Amazon and FedEx. Isn’t it interesting that when the IT industry develops things for itself, we end up with multi-millionaires? When we develop for other people, they end up losing money.

How did we ever talk you into any of this? Well, we package this unsightly mess and try to sell it to you. To do this, we have to hide all this unpleasantness. We start with a ritual called ‘estimation’ – how much time we think the work will take. These ‘estimates’ are little better than guesses. Humans can’t estimate time. We’ve known this since at least the late ’70s, when Kahneman and Tversky described the ‘planning fallacy’ in 1979 and went on to win a Nobel Prize. Basically, humans consistently underestimate how long work will take and are overconfident in their estimates.

To make things worse, we have a bad habit we really should kick. Between estimating the work and doing the work, we usually change the team. The estimate may be made by the IT equivalent of Manchester United or the New York Yankees, but the team that actually does the work is more than likely a rag-tag bunch of coders, analysts and managers who’ve never met before.

Historical data – data about estimates, actuals, costs, etc – can help inform planning, but most companies don’t have their own data. For those that do have data, most of it is worse than useless. In fact, Capers Jones suggests that inaccurate historical data is a major cause of project failure. For example, software engineers rarely get paid overtime, so tracking systems often miss these extra hours. Indeed, some companies prohibit employees from logging more than their official hours in their systems.

So we make this guess (sorry, ‘estimate’) and double it – or we might even triple it. If the new number looks too high, we might reduce it. Once our engineers have finished massaging the number, we give it to the sales folk, who massage it some more. After all, we want you to say “yes” to the biggest sticker price we can get. That might sound awful, but remember: we could have guessed higher in the first place.

Please don’t shoot me: I’m only the messenger.

We don’t know which number is ‘right’, but to make it acceptable to you, we pretend it is certain and we take on the risk. We can only do this if the number is sufficiently padded (and, even then, we go wrong). If the risk pays off, we get a fat profit. If it doesn’t, we don’t get any profit and may take a loss. If it’s really bad, you don’t get anything and we end up in court or bust.

The alternative is that you take on the risk – and the mess – and do it yourself. Unfortunately, another sad truth is that in-house IT is generally even worse than that provided by specialists. For a software company development is a core competency – such companies live or die by their ability to deliver software, and if they are bad, they cease to trade. Evolution weeds out the poor performers. Corporate IT on the other hand rarely destroys a business – although it may damage profits. Indeed, Capers Jones’ research also suggests specialist providers are generally better than corporate IT departments.

Sales folk might be absent, but the whole estimation process is open to gaming from many other sources and for many other reasons. The bottom line: if you decide to take on the risk, you may actually increase risk.

I know this sounds like a no-win scenario. You could just sit on the fence and wait for Microsoft or Google to solve your problems with a packaged solution, but will your competitors stand still while you do? Will you still be running a business when Google produces a free version?

Beware snake oil salesmen selling off-the-shelf applications. Once people start talking about ‘customisation’ or ‘configuration’, you head down a slippery slope. Configuring a large SAP installation is not a matter of selecting Tools, Options and then ticking a box. Configuring large packages is a major software development activity, no matter what you have been told. The people who undertake the configuration might be called ‘consultants’, but they are really specialist software developers, programmers by another name.

There really isn’t a nice, simple solution to any of this. We can’t solve this problem for you. We need you, but you have to work with us. As the customer, you have to be prepared to work with us, the supplier, again and again in order to reduce the risk. Addressing risks in a timely and cost-effective manner involves business-level decisions and trade-offs. If you aren’t there to help, we can either make the decision for you (adding the risk that you disagree), or spend your time and money to address it.

You need to be prepared to accept and share the risk with us. If you aren’t prepared to take on any risk, we will charge you a lot for all the risk we take on. Sharing the risk has the effect of reducing the risk, because once the risk is shared you, the customer, are motivated to reduce risk. One of the major risks on IT projects is a lack of customer involvement. You can help with that just by staying involved.

Ultimately all risk is your risk: you are the customer, you are paying for the project one way or another. If it fails to deliver value, it is your business that will suffer. When you share risks, when you are involved closely, risks can be addressed immediately rather than being allowed to fester and grow.

Finally, you may have grand ambitious, but we need to work in small chunks. I know this may not sound very sexy, but software creation works best when small. Economies of scale don’t exist. In fact, we have diseconomies of scale, so we need to work in tiny pieces again, again and again. If you are prepared to accept these suggestions, then let’s press ‘reset’ on our relationship and talk some more.

Yours sincerely,

The IT Industry


Dear Customer was first publishing this blog nearly 10 years ago, a polished version became famous in Agile Journal (now Agile Connection) a few months later and forms the prologue to Xanpan, 2015.


Subscribe to my blog newsletter and download Project Myopia eBook for Free

The post Dear customer, the truth about IT appeared first on Allan Kelly Associates.

Videos: ITIL & the Product Owner

Last month I appeared in two videos now available on YouTube.

First I was interviewed by Adrian Reed about the Product Manager and Owner roles for The BA Fringe. My interview appears about 12 minutes into the programme and lasts about 10 minutes.

I also joined an expert panel discussing the ITIL 4 High Velocity IT – aligning agile and lean. It was a great conversation and a lot of fun to record, we hardly mentioned ITIL but #NoProjects did get a look in.

I know, ITIL is not something I’m usually associated with but digital and agile means ITIL is changing and I contributed chapters on Product Owner and Continuous Digital (aka #NoProjects) to the recent ITIL High Velocity IT book.

The post Videos: ITIL & the Product Owner appeared first on Allan Kelly Associates.

Coordinating teams like synchronised flying?

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.

Most software dies young

My old ACCU friend Derek Jones has been beavering away at his Evidence Based Software Engineering book for a few years now. Derek takes an almost uniquely hard nosed evidence driven view of software engineering. He works with data. This can make the book hard going in places – and I admit I’ve only scratched the surface. Fortunately Derek also blogs so I pick up many a good lead there.

One of Derek’s most thought provoking finding is: most software has a very short lifespan.

At first this finding worried me: so much of what I’ve been preaching about software living for a long time is potentially rubbish. But then I remembered: what I actually say, when I have time, when I’m using all the words is “Successful software lives” – or survives, even is permanent. (Yes its “temporary” at some level but so are we, as Keynes said “In the long run we are all dead”).

My argument is: software which is successful lives for a long time. Unsuccessful software dies.

Successful software is software which is used, software which delivers benefit, software that fills a genuine need and continues filling that need; and, most importantly, software which delivers more benefit than it costs to keep alive survives. If it is used it will change , that means people will work on it.

So actually, Derek’s observation and mine are almost the same thing. Derek’s finding is almost a corollary to my thesis: Most software isn’t successful and therefore dies. Software which isn’t used or doesn’t generate enough benefit is abandoned, modifications cease and it dies.

Actually, I think we can break Derek’s observation into two parts, a micro and a macro argument.

At the micro level are lines of code and functions. I read Derek’s analysis as saying: at the function level code changes a lot at certain times. An awful lot of that change happens at the start of the code’s life when it is first written, refactored, tested, fixed, refactored, and so on. Related parts of the wider system are in flux at the same time – being written and changed – and any given function will be impacted by those changes.

While many lines and functions come and go during the early life of software, eventually some code reaches a stable state. One might almost say Darwinian selection is at work here. There is a parallel with our own lives there: during our first 5 years we change a lot, we start school, things slow down but still, until about the age of 21 our lives change a lot, after 30 things slow down again. As we get older life becomes more stable.

Assuming software survives and reaches a stable state it can “rest” until such time as something changes and that part of that system needs rethinking. This is Kevlin Henney’s “Stable Intermediate Forms” pattern again (also is ACCU Overload).

At a macro level Derek’s observation applies to entire systems: some are written, used a few times and thrown away – think of a data migration tool. Derek’s data has little to say about whether software lifetimes correspond to expected lifetimes; that would be an interesting avenue to pursue but not today.

There is a question of cause and effect here: does software die young because we set it up to die young or because it is not fit enough to survive? Undoubtedly both cases happen but let me suggest that a lot of software dies early because it is created under the project model and once the project ends there is no way for the software to grown and adapt. Thus it stops changing, usefulness declines and it is abandoned.

The other question to pondering is: what are the implications of Derek’s finding?

The first implication I see is simply: the software you are working on today probably won’t live very long. Sure you may want it to live for ever but statistically it is unlikely.

Which leads to the question: what practices help software live longer?

Or should we acknowledge that software doesn’t live long and dispense with practices intended to help it live a long time?

Following our engineering handbook one should: create a sound architecture, document the architecture, comment the code, reduce coupling, increase cohesion, and other good engineering practices. After all we don’t want the software to fall down.

But does software die because it fails technically? Does software stop being used because programmers can no longer understand the code? I don’t think so. Big ball of mud suggests poor quality software is common.

When I was still coding I worked on lots of really crummy software that didn’t deserve to live but it did because people found it useful. If software died because it wasn’t written for old age then one wouldn’t hear programmers complaining about ‘technical debt” (or technical liabilities as I prefer).

Let me suggest: software dies because people no longer use it.

Thus, it doesn’t matter how many comments or architecture documents one writes, if software is useful it will survive, and people will demand changes irrespective of how well designed the code is. Sure it might be more expensive to maintain because that thinking wasn’t put in but…

For every system that survives to old age many more systems die young. Some of those systems are designed and documented “properly”.

I see adverse selection at work: systems which are built “properly” take longer and cost more but in the early years of life those additional costs are a hinderance. Maybe engineering “properly” makes the system more likely to die early. Conversely, systems which forego those extra costs stand a better chance of demonstrating their usefulness early and breaking-even in terms of cost-benefit.

Something like this happened with Multics and Unix. Multics was an ambitious effort to deliver a novel OS but failed commercially. Unix was less ambitious and was successful in ways nobody ever expected. (The CPL, BCPL, C story is similar.)

In fact, this all starts to sound a lot like Dick Gabriel’s Worse is Better argument. Perhaps there is a pattern here.

Finally, what about tests – is it worth investing in automated tests?

Arguably writing test so software will be easier to work on in future is waste because the chances are your software will not live. However, at the unit test level, and even at the acceptance test level, that is not the primary aim of such tests. At this level tests are written so programmers create the correct result faster. Once someone is proficient writing test-first unit tests is faster than debug-later coding.

To be clear: the primary driver for writing automated unit tests in a test first fashion is not a long term gain to test faster, it is delivering working code faster in the short term.

However, writing regression tests probably doesn’t make sense because the software is unlikely to be around long enough for them to pay back. Fortunately, if you write solid unit and acceptance tests these double as regression tests.

Subscribe to my blog newsletter and download Project Myopia for Free

The post Most software dies young appeared first on Allan Kelly Associates.

Next short online workshops

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

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?

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

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

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?

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

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.

Testing Testing 1 2 – video blog

Testing isn’t, or shouldn’t be, about finding bugs. Type-1 Testing is about ensuring you can go to Type-2 Testing and get some useful feedback. Customer feedback is the really valuable stuff: does your product address the need you saw? Is there more to do? More value to be got? – and does the value delivered justify the cost of doing it?

Testing-Testing 1 2 is a 13-minute video blog rerecording of a private presentation I did during lock-down, I hope you find it interesting.


September micro-workshops now booking, space limited

User Stories Masterclass, Agile Estimation & Forecasting, Maximising value

Early bird discounts, free tickets for unemployed & furloughed – Book with code Blog15 for 15% discount or get more details


The post Testing Testing 1 2 – video blog appeared first on Allan Kelly Associates.

Is Agile is obvious?

iStock-1174931869-2020-07-27-14-29-1.jpg

From time-to-time people say to me:

“Agile is obvious”

When I’m being honest it is kind of hard to argue with them, it is certainly “obvious” to me. But at the same time agile is not obvious, or rather, the opposite of agile is also obvious. For example,

Agile says: obviously, you don’t know the future so don’t plan and research too far into the future.
Non-agile thinking says: obviously, failure to plan is planning to fail, obviously you need a plan of action, you need to plan for the future.

Agile says: obviously, people work best when they are self-motivated and given a say in what they do.
Non-agile says: obviously, people are lazy and will do as little as possible, therefore someone needs to manage them.

Agile says: high quality makes it easier to change in the future, obviously.
Non-agile says: obviously, quality is an endless quest, there is no point in polishing something which isn’t important, 20% of the effort gives 80% of the reward so don’t do any more.

Agile emphasises the here and now, the soon, obviously requirements can be handled just-in-time, so live for today.
Non-agile says: if we don’t think about the future we will obviously duplicate work and incur additional costs.

And my own entry: obviously, software development as diseconomies of scale therefore optimise for lots of small. The opposite is equally obvious: economies of scale are what makes modern business – and the cloud – successful so exploit them

There are a number of obvious examples that go with that:

Agile says: obviously we should test every change and new feature by itself to avoid the complications of interacting changes.
Non-agile says: obviously full test runs are slow and expensive so bundle work together and test it on mass.

Both agile and not-agile are obvious. What you consider obvious depends on your starting point. Once you start thinking “agile” a lot of things become obvious. But if you are not thinking agile then, if you are thinking some other model, then the opposite is also obvious.

Some would term this “An Agile Mindset”. However I don’t want to do that, I find the idea of “an agile mindset” too nebulous. I also note that most of the people I hear talking about “an agile mindset” seem to clinging on to some piece of holy lore which I consider not very agile and they believe is totally agile (the project model and upfront requirements usually.)

Instead I find myself going back to Theory-X and Theory-Y. In general people fall into one camp or the other. If you, your philosophy on work and life, align with theory-Y then all the “agile is obvious” statements above are indeed obvious. Conversely, if you generally follow a theory-X philosophy then all the non-agile statements are obvious.

Perhaps surprisingly I find people can flip, and be flipped, from X to Y. What is more difficult is getting people to unlearn behaviours and actions which they acquired with a theory-X mindset. Even if some element of theory-Y (and agile) is now obvious people need help to learn the new way and let go of the old. Some people can do this by themselves, others need help – or at least help speeding up the change.

Yes, thats part of my job as an Agile Guide. Sometimes just talking (and reflecting on recent events) helps. Sometimes exercises (or process miniatures they are sometimes called) help. Sometimes it is by experiments, exposing people to others can help as well – so conferences, user groups.

Rarely do people change because they went on training and were lectured too, but good training incorporates talking, reflection, exercises, etc. Such training is less training and more about practicing the future.

Obviously, my training is like that: I aim to make my training courses a rehearsal for future actions. Actually, while I “sell” training I prefer to think of it as a rehearsal or kaikaku event – kaikaku events also call a “kaizen blitz”, they are big change events from the people who brought you kaizen, more on them another time.

So when someone I’ve worked with turns around and says “Agile is obvious” I take it as a sign of success. They no longer seem agile as something strange, it is normal, it is onbvious.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Is Agile is obvious? appeared first on Allan Kelly Associates.

September micro-workshops – tickets!

I’m running all three of my half-day workshops again in September:

You can read reviews of these workshops on the Allan Kelly agile training pages where you will find more details too.
SlimCoupon-2020-07-27-14-21.jpg
Tickets are on-sale now with Tito – with a 20% early bird discount. (I’m using Tito this time because it promises to handle VAT better for those of you outside Europe.) If you have any problems with Tito or would prefer to receive an invoice contact me directly via e-mail, allan at allankelly dot net.

Blog readers can get another 15% off with the code “Blog15”.

Plus, if you book and pay for one workshop you will receive a code for 50% off the other workshops – buy one get two half price offer.

As before there are a few free tickets for the unemployed and furloughed. I might release more unemployed free tickets nearer the time so join the wait list if you are unemployed and miss out.

The post September micro-workshops – tickets! appeared first on Allan Kelly Associates.

Recent talks online

During the last few months I’ve done a lot of online talks and presentations. Most have been public but some have been private, some have been repeats (with updates) of past presentations while others are completely new.

As always a full list in the insights section of my website and on my YouTube channel. These include:

And “Everything think you ever wanted to know about the Product Owner but were afraid to ask”, a conversation with Adrian Reed.

Unlike conference recordings which show me dancing around a stage these were all delivered online so I expect you will find the recordings better quality. The slides are available as PDFs, again on my website.

The post Recent talks online appeared first on Allan Kelly Associates.

The Business Case for Agile in 2020 – video blog

A couple of weeks ago I gave a private presentation to an organization entitled: “The Business Case for Agile in 2020.” Actually, it surprised me a bit that in 2020 people still wondered what the business case for agile was but that probably says more about my arrogance and the agile bubble I live in.

I’ve re-recorded the presentation and it is now on-line: The Business Case for Agile in 2020 is on YouTube and embedded below.

The post The Business Case for Agile in 2020 – video blog appeared first on Allan Kelly Associates.

September workshops

Summer is here so things are quiet. I’m not running any more workshops during the summer and will use the time to review what I’m doing. Still, I have started to create an initial programme of events:

Tickets are not on sale but the events are listed on Tito so if you are interested register your interest today and as soon as tickets are on sale you will know. More details are on my Agile training pages – where you will also find some great reviews from people who have been on the courses recently.

I have lots of ideas for more online workshops so if there is a subject you would like to see please drop me a note (contact at allankelly dot net) and I’ll see what I can do – it would be great to know what people actually want!

I’ve not yet decided what to do about free tickets for the unemployed and furloughed. While I like offering these tickets – it feels like the right thing to do – I am getting high dropout rates from people who register for these tickets. The old case of people registering for something and having nothing to loose if they don’t turn up.

The post September workshops appeared first on Allan Kelly Associates.

Agile & OKRs – the next book

Last year I had a surprise: the company I was working with introduced OKRs – Objectives and Key Results. I started off very cynical about how effective these were likely to be but …

Not only did I come to like OKRs and the OKR setting process I came to see how they plugged a gap in agile and how they can be powerful for agile teams.

So a few months ago I started writing a book: A little book about Agile with OKRs.

I stalled for a few weeks but I’m working on it again so expect more updates in the coming weeks. Please let me know what you think of the book, and if you are using OKRs I would especially appreciate your thoughts and stories – I might even include them!

(Yes the name is deliberately chosen to build on the success of my “Little Book about Requirements and User Stories”.)

The post Agile & OKRs – the next book appeared first on Allan Kelly Associates.

I’m an Agile Guide

aron-visuals-3jBU9TbKW7o-unsplash-2020-07-1-09-44.jpg

Anyone who keeps a keen eye on Linkedin might have noticed I recently changed my job description to Agile Guide. I feel “guide” more accurately reflects what I do: part coach, part advisor, part teacher.

I work as a consultant – a hired gun – but “consultant” is a very vague term and covers a lot of ground. Plus a lot of people in the technology industry have a very negative view of consultants. I’ve been known to share that view myself so while consultant might be an accurate description it was also vague and open to misinterpretation.

Many people consider me an Agile Coach, and I have worked as an agile coach. However – as I’ve written before – this too is a conflicted term. Most of us who go by the title “agile coach” like to talk about helping people help themselves, unlocking the individual, respecting the individual as the expert, and so on. I agree with a lot of that and I do it. Sometimes.

I also know what professional coaches do and I don’t feel I’m one of them. I have a lot of respect for real coaches. Such coaches put their own opinions second and I don’t. I am prepared to tell people the way I think it should be – they are free to ignore my advice but I’m prepared to say it.

Thats why I also regard myself as part teacher: not just direct training sessions (which I do) but also one-on-one and in small free format group sessions.

So what title should I use?

I’ve struggled with this for years. My epiphany came a few weeks ago: Agile guide. I help others to get more agile, coaching is one tool but so is direct advice and teaching.

Hadn’t others thought of “Agile Guide”. So I checked out LinkedIn myself. One person. Someone I respect, someone I call a friend: Woody Zuill.

I checked in with Woody and his thinking parallels mine.

So I’m an Agile Guide – I help individuals, teams and enterprises become more agile in a digital world.

Part coach, part advisor, part teacher, plus thinker and route finder. I use skills of coaching, teaching and consultancy.

Who knows, maybe, it will catch on. After all, as Woody pointed out, we have both changed the world already.


Subscribe to my blog newsletter and download Project Myopia for Free

The post I’m an Agile Guide appeared first on Allan Kelly Associates.

The future of office working

HomeOffice-2020-06-30-16-47.jpg

The lockdown hasn’t effected my work environment that much. This is a picture of my home office, my garden office, my “man cave.” I am very lucky. When I’m not on site with clients I spend most of my time working here. Still, I miss visiting clients and conferences – although I did squeeze in Agile on the Beach New Zealand in the closing days of the old world.

A friend of mine works for Canonical – the Ubunto Linux people. The vast majority of the people at Ubunto work remotely. So while my friend lives in New Zealand he works with a team spread out across the world.

Once or twice a year, his whole team co-locates. They all fly together and work together for a couple of weeks, a sprint. Then they return home and work remotely with each other for another six months, then repeat. Once or twice I’ve seen Tim as he works in, or passes through, London. But as luck would have it the week I was in New Zealand he was on his travels.

In all this talk of how wonderful working-from home can be I don’t think there has been enough discussion about what makes a good experience and what makes it bad. The Ubunto story highlights a couple of points which I think are missing from much of the current discussion over remote/home working.

Firstly the team are equal: they are all remote.

Over the years I have observed big differences in the way teams which are all distributed operate and the way teams with only one or two members operate. When the bulk of a team are co-located and only one or two are remote there is an unequal relationship. My intuition says teams are better off when they are either all remote or all co-located. When five of the team are co-located and a sixth member is remote then things are more difficult.

The way lockdown came about this year teams went from one to the other overnight, literally. Which also means it was very egalitarian. Everyone was in the same position. That can only be a good thing.

The second thing I take from Ubunto is that face-to-face time is still valued. In fact, as we unlock I expect home working will be more common, more remote tools will be used but we will value co-locating and face-to-face contact all the more.

Where companies keep people remote I expect we will see the emergence of deliberate co-location. This might be a two week block like my friend or it might be a few hours or a whole day. I can easily imagine benefit from an agile team coming together for one day a fortnight to close out a sprint, run a retrospective and then plan the next sprint. (That will have a knock on effect in the office market as companies stop renting offices for years and rent meeting rooms by the day.)

In fact this will be essential. It is easier to build social capital – trust, comradeship – when you are face-to-face. For the last three months we have been running on the social capital and experience teams built up over years working together. The social capital account now needs toping up.

Existing teams, existing social capital and egalitarian distribution helped people work during the lockdowns. As we slowly move back to our offices that is going to change and we will need to make deliberate efforts to replenish social capital, keep people equal and build new teams.

New teams will benefit from working together face-to-face to get to know one another. Build some social capital and norms.

New employees in particular will need time together. Especially those, like fresh graduates, who are new to work altogether. Such people need to learn how to work. Doing that in a distributed environment is a challenge.

Those new to the workforce face an additional challenge: space.

Home working is OK for me, I have a garden big enough for an office (and I had the money to buy one.) How many people have been working of their kitchen table? or bedroom? Mixing your sleeping space with your work space can damage sleep patterns and add to stress.

How many new workers have that space?

I remember when I was a fresh graduate finding my way in the world I lived in house shares. I had a room in a shared house with similar people. Some of them I counted as friends but not all of them. Some of them had bad habits. Going to an office for work was important, staying in the house – especially when they were all staying in! – would have been too much.

Then there is the question of broadband: I have 200Mb fibre to the door but many people make do with a lot less and that can be variable. Not that 200Mb comes cheap…

If a company expect someone to work from home then I think they should pay for good broadband internet. They should also provide the equipment – I have heard of only a few employers who have given staff money to buy equipment for home.

In February and March many people all over the world found themselves having to work from home. Its been a better experience than many expected but I know people are flagging, I know people keen to get back to the office. In future I expect we’ll value face-to-face contact even as many people stay at home.

In the coming months people aren’t just going to walk back to the office and pick up where they left off. Work will be more varied. But now the initial pleasure and surprise of working for home is over we need to have a conversation about what companies need to do to support working from home in future and how it can be made sustainable.


Subscribe to my blog newsletter and download Project Myopia for Free

The post The future of office working appeared first on Allan Kelly Associates.

Time value profiles – a little tool with big implications

TimeValueProfile-2020-06-23-15-06.jpg

User Stories Masterclass onlne, 6 July NOW BOOKING – Code BLOG_READER for 30% discount + 25% Early Bird discount

New: Agile Estimating & Forecasting, 13 July NOW BOOKING – Code BLOG_READER for 45% discount + 25% Early Bird discount

The picture above is a time-value profile: it shows how value changes with time. It is a graphic illustration of cost of delay.

A fine wine might increase in value over time but most things – think product, project, feature or just story – decay with time. Having something today is worth more than having it next week.

I invented Time-Value profiles – although I’m happy to acknowledge Don Rienertsen’s influence. I’ve included time-value profiles in many presentations and courses (they are a key part of my value workshop) but oddly, while I’ve mentioned them in this blog before I’ve never described them. So here goes…

Imagine we want to build a feature for a product. Naturally we ask: “what is this worth?”

Money is the obvious way to measure value but strictly speaking money is not itself valuable – unless you happen to want small colourful pieces of paper or decorated lumps of metal. Money is a store of value. The value of money is not the money itself but what you can exchange the money for. And because money can be traded for a wide variety of things, which are themselves valuable, money is a useful medium for comparison and measurement.

So the question “what is this worth?” may be answered qualitatively (“a vaccine is valuable because it saves lives”) or quantitatively (“a vaccine is worth $10 trillion because it allows life to return to normal”). In order to compare competing opportunities and valuations, and in order to draw a graph, giving value a numerical quantity helps greatly.

A time-value profile shows quantitive value over time when value is measured numerically: maybe in hard money like dollars or yen, or an abstract measure like business points, wooden dollars or Atlantic shillings (I just invented that but it works).

The graph starts today: we say “If we had feature X today it would be worth 100,000 shillings”. Maybe it is worth 100,000 because that is what a customer would pay for it, or maybe because we could sell 100,000 units at 1 shilling each, or so on.

But we don’t have X today. “If we get feature X next month it will be worth 90,000 shillings.” One month delay, one month late to the customer, one month later on Amazon, costs 10,000 shillings.

“If feature X is 3 months away then it is worth less than 50,000 shillings.” And so on.

Now, the unit of value – dollars, francs, shillings, wood – is of little important. Sure $1,000,000 is very different to 1,000,000 (Russian roubles if you don’t know) but as long as you don’t mix currencies the actual currency is unimportant.

What is important is the shape of the curve and, especially, where abrupt changes happen. Look again at the graph above: between months two and three there is a sudden drop in value. That has scheduling implications.

Once you start to think about time-value profiles then it becomes obvious that value is a function of time and we need to understand what that function looks like for any given work – project, product, initiative, feature, story, just anything in fact.

It should also become clear that the question “how long will it take to build X” needs to be inverted: “how long have we got to build X?”, “how much of X could we build?” or “in the time we have what could create something to satisfy need X”

And then “how much of the available value can we capture?”. Having X might be worth 100,000 but having a half of X might still be worth 50,000 more than not having X.

As I’ve written before: to any given problem there are multiple solutions. Engineering is not about creating the best possible solution, it is about creating a solution within constraints – as my widgets exercise shows.

Add in capacity planning and a whole new paradigm of scheduling opens up.

Not that I wish to ignore costs – and effort estimates – but they are secondary, and the subject of another blog. I’ll write more about this, and perhaps put something into a workshop, in the meantime my value workshop is the best place to find out more.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Time value profiles – a little tool with big implications appeared first on Allan Kelly Associates.

Product Owner: meet the customer

alejandro-escamilla-BbQLHCpVUqA-unsplash-2020-06-16-12-37.jpg

User Stories Masterclass, 29 June & Agile Estimating & Forecasting, 13 July

Discounts below

I was once responsible for coaching a Product Owner called Jac. It was product owner for an “enterprise product” – a product sold to big companies to use internally. Sprint to sprint Jac got to decide what got done. In my book Product Owner authority went further: what was to be done in future sprints, what kind of things would be done in months to come, and the “roadmap” where the product was going. But… Jac seldom met customers, Jac might talk to them on the phone when they had a problem but Jac didn’t talk to the more senior people who signed the purchase orders.

Being an enterprise product there were consultants in the mix too: installing the product on site, configure the product, train customers and hold their hands. They went to customer sites and they met all sorts of people. Naturally the consultants had a view on what the product should do, what should be developed next and what should be done in coming months.

And all a consultant had to do was name a customer “Anna at Credit…” or “The CFO of first…. told me” and you could just see the product owner being undermined. I used to groan internally, I hated it – I hated it for my PO – but they were right.

When you meet customers you carry extra authority.

Last week I did a webinar entitled to Agile London entitled “Product Owner Common Mistakes” (the PDF). Guess what common mistake number #1 was?

(I also did a webinar with Adrian Reed entitled “Everything you ever wanted to know about the Product Owner but were afraid to ask” which was a great chat and audience Q&A session.)

Product Owner mistake #1: Not meeting customers

And here I mean Customers, and/or Users, and/or Stakeholders, I mean: people – and it is people – who have expectations, needs or wants for your product. Even if they don’t know your product could help address those needs and wants.

And when I say “meet,” well yes, I really would like you to meet them, shake them by the hand and share a coffee. I think you are both more likely to open up, share more and understand more. If possible spend some time observing them work.

I’m not stupid, I know we all work from home now, I know physical meetings are more difficult than ever so please substitute “meet” with Zoom, Skype, WhatsApp or plain old telephone. But as soon as you can get out and meet people.

In meeting people Product Owners get two big benefits.

The most obvious benefit is that Product Owners understand their customers and their needs better. They can learn how the product could help more, or where the product trips them up. They can learn how the product is beneficial and valuable and how that value might be increased.

Product Owners will also learn things they might not like to hear, things which might not be said over the telephone: where the product stinks, what alternatives might be considered and where the product gets in the way.

“what the customer buys is seldom what the company sells” Peter Drucker

People don’t like giving bad news and it is easier to hide such facts phone call, let alone in an e-mail.

The second benefit, as described in my opening story is authority and legitimacy.

Product Owners are specialists in what customer problems need solving, how enhancements to the product can add value and therefore what needs to be done to the product. They can only do that when they meet customers.

Meeting customers brings authority, one can say “Anna at Credit Bank told me…”

Meeting customers brings legitimacy because most other people never interact with actual customers, or only interact with a small subset when they have problems.

And as my example shows: if a Product Owner is not meeting customers they leave themselves vulnerable to those who do. When someone else, like a consultant, comes along and says “Anna from … says… ” they have authority, if the PO can not say “Mez from … had a different perspective…”

Direct access to customers – speaking to them and visiting them – confers authority and legitimacy. Product Owners need that authority and the knowledge that comes with it.

User Stories Masterclass is running online again, 29 June NOW BOOKING

Use code BLOG_READER for 30% discount + 25% Early Bird discount

New online class: Agile Estimating & Forecasting, 13 July – NOW BOOKING

Use code BLOG_READER for 45% discount + 25% Early Bird discount


Subscribe to my blog newsletter and download Project Myopia for Free

The post Product Owner: meet the customer appeared first on Allan Kelly Associates.

User stories are not…

UserStoryNot-2020-06-8-16-16.jpeg

Final call: Adding Value to Stories, starts 5 June

New: User Stories Masterclass waitlist, 29 June – waitlist available

When started writing what became “Little Book of Requirements & User Stories” I thought I was writing a few thousand words about the relatively straight forward subject of User Stories in agile development. A “few thousand” became a dozen online articles for Agile Journal and a few tens of thousands of words in the book.

Now those same lessons form the basis for my online workshop “User Stories Masterclass”. Still I find new perspectives and insights on User Stories. I was wrong, there is more to the simple “as a… I want… so that…” than I ever thought possible.

But for once I think we need to draw some boundaries, we need to be clear on what User Stories are NOT.

User Stories are not promises or commitments. Stories are ideas. Stories are tokens for work that might be done. Little more.

Simply writing a User Story, even adding it to a backlog in no way commits anyone to doing anything. Indeed I regularly recommend deleting stories from a backlog. I hear from start-ups who tell me that 30% to 50% of stories are never done.

User Stories are not functional specifications, although if you add enough acceptance criteria they may start to look like that.

User Stories are not functional specifications because User Stories are not complete. They are intended as a “placeholder for a conversation” or “a token for work to be done”. If they were complete there would be no need for that conversation and they would be much more than a token. They are deliberately incomplete to allow the conversation to happen. If the story was complete what can a conversation add? There is more value in the conversation than the story.

User Stories are not unambiguous, or rather: User Stories may contain ambiguities. In the same way User Stories are not complete they can be ambiguous. Again, if stories were clean cut and unambiguous there would be little to talk about in the famous conversation.

And by the way, the User Story conversation is not necessarily a one-off event: if you have the conversation then later, say, during development or testing, then talk some more.

User Stories are not user documentation, a collection of stories does not make a User Guide. If you need to create a user guide then the stories might serve as a reminder of what the software does but using them as user documentation would make for a very poor user guide.

If the system you are building needs a User Guide then the act of writing the User Guide is probably a story itself, a token for work to be done:

As a new customer using the system for the first time
I want a guide to get started
So that I can quickly get the benefits of the new system

All the usual rules of user stories apply here: be specific about who is using the system and what they need, include a so that clause to explain why they want to do this, leave some space for discussion (do the really want a user guide or a quick start guide?) and ensure the story has value in itself.

Similarly, User Stories are not any sort of system documentation, e.g. architecture document, maintenance guide. Again these are work to be done and may be the subject of a User Story.

In general User Stories are not part of the contractual commitment a team enters into. User Stories are poorly suited to be contractual documentation. Because User Stories are not complete and because they are ambiguous they perform poorly when used contractually.

Similarly, User Stories are not good as a record of what has been done. They can be forced into this role if they are updated after they have been developed – and preferably delivered. But that requires more work.

As with any documentation – user guide, system guide, a record of what was done, etc. – you should always ask: what value does this documentation have? and who will complain if this document does not exist?

Documentation is not free. Indeed documentation is very expensive – both to write and to read. And documentation is itself work to be done. Which means: if someone is writing a document then they are not doing something else, e.g. if a developer is documenting the system they are not adding new functionality.

Even when there is a technical author on staff to write documentation other work is displaced. The money used to pay a technical author could be spent elsewhere, another programmer or a tester maybe.

Documentation is expensive. Documentation is another deliverable.

User Stories are not intended to form part of the deliverable. They are transient, they come into existence to represent work that needs doing. They change as understanding improves and can, even should, be thrown away when the work is done.

User Stories Masterclass is running online again at the end of June.

Rather one session a week this time the class will be one afternoon, or possibly one and a half afternoons. Tickets will be on-sale soon, in the meantime you can join the waitlist and be the first to know when tickets go on sale.


Subscribe to my blog newsletter and download Project Myopia for Free

The post User stories are not… appeared first on Allan Kelly Associates.

Sander Hoogendoorn @ Agile on the Beach Keynote – and discount

AOTBKeynote-2020-06-8-16-06.jpg

As most readers will already know – and everyone else will have guessed – Agile on the Beach 2020 isn’t happening. Gather than try and move the whole conference online we are running some smaller events. Two of these are now booking: an online talk and an online TDD workshop.

Sander Hoogendoorn will be giving his Agile on the Beach 2020 online on July 8 – yes, that is the day he would have been giving it live in Falmouth if you-know-what hadn’t happened.

Tickets are free to those who have bought Agile on the Beach 2020 tickets (which will be honoured at AOTB 2021 too) so just remember to register for a ticket.

For everyone else there is a £20 fee – but if you enter the code “AOTBSH2050” will get you a 50% discount.

But before Sander’s talk, AOTB’s sister organization Software Cornwall is running a Test Driven Development workshop with Kevlin Henney and Jon Jagger. Again there are free tickets for AOTB ticket holder but places are limited so book soon.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Sander Hoogendoorn @ Agile on the Beach Keynote – and discount appeared first on Allan Kelly Associates.

Product owner as a homeowner

house-illustration-clipart-free-stock-photo-public-domain-pictures1-2020-05-21-14-50.jpg

For years people have been comparing software construction with building construction. Think about how we talk about “architecture” or foundations, or the cost of change and so on. As I’ve said before, building software is not like building a house. Now it occurs to me that a better metaphor is the ongoing ownership of the building.

Every building requires “maintenance” and over time buildings change – indeed buildings learn. While an Englishman’s home is his castle those of us, even the English, who are lucky enough to own a house don’t have a free hand in the changes we make to our houses

Specifically I’m thinking about the Product Owner. Being a Product Owner is less about deciding what you want your new house to look like, or how the building should be constructed, its not even about deciding how many rooms the house should have. The role of the Product Owner is to ensure the house continues to be liveable, preferably the house is getting nicer to live in, and the house is coping with the requests made on it.

I own a house – a nice one in West London. As the owner I am responsible for the house. I do little jobs myself – like painting the fences. More significantly I have to think about what I want to do with the house: do we want to do a loft conversion? What would that entail and when might I be able to afford that?

I am the Product Owner of my own house. I have to decide on what is to be done, what can wait and what trade-offs I can accept.

When I bought the house the big thing to change was the kitchen and backroom. There was little point in any other works until those rooms were smashed to bits and rebuilt. I had to think though what was needed by my family, what was possible and what the result might be like. I received quotes from several builders – each of whom had their own ideas about what I wanted. I hired an architect for advice. I looked at what neighbours had done. And I had a hard think about how much money I could spend.

An Englishman’s home is his castle – I am the lord of my house and I can decide what I want, except…

My wife and children have a say in what happens to the house. Actually my wife has a pretty big say, while the children have less say there needs are pretty high on my list of priorities.

My local council and even the government have a say because they place certain constraints on what I can do – planning permission, rules and building codes. The insurance company and mortgage bank set some constraints and expectations too.

My neighbours might not own my house but they are stakeholders: I can’t upset them (too much) and they impose some constraints. (In my first flat/apartment the neighbours were a bigger issue because we shared a roof, a garden and the walls.)

So while I may be lord of my own house I am not a completely a free agent. And the same is true with Product Owners.

The secret with Product Owners is: they are Owners. They are more than managers – managers are just hired help. But neither do POs have a free hand, they don’t have unlimited power, the are not dictators, they are not completely free to do what they want and order people around.

Like me, Product Owners have limited resources available: how much money, how many helpers, access to customers and more. I have to balance my desire for a large loft conversion (with shower, balcony and everything else) with the money I can afford to spend on it. That involves trade-off and compromises. I could go into debt – increase my mortgage – but that comes with costs.

Product owners have responsibilities: to customers and users, to the those who fund the work (like the mortgage bank), to team members and peers to name a few. Some decisions they can make on their own, but on other decisions they can only lead a conversation and guide it towards a conclusion.

What the homeowner metaphor misses entirely is the commercial aspect: my house exists for me to live in. I don’t expect to make money out of it. The house next door to mine is owned by a commercial landlord who rents it out: the landlord is actively trying to make money out of that house.

Most Product Owners are trying to further some other agenda: commercial (generating money), or public sector (furthering Government policies), or third sector (e.g. a charity). In other words: Product Owners are seeking to add value for their organization. This adds an additional dimension because the PO has to justify their decisions to a higher authority.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Product owner as a homeowner appeared first on Allan Kelly Associates.

Adding Value to User Stories

4Coins-2020-05-21-12-06.jpg

My next online workshop is now available for booking: Adding Value to User Stories.

As with my previous online workshops this is a series of four 90 minute online (zoom) sessions delivered on consecutive weeks. And as before a few tickets are available for free to those who are furloughed or unemployed.

This workshop is for Product Owners (including business analysts and product managers), Scrum Masters, Project and Development Managers.

Learning Objectives

  • Appreciate the influence of value on effort estimates and technical architecture at the story and project level
  • Know how to estimate value for user stories and epics
  • Recognise how cost-of-delay changes value over time, why deadlines are elastic by value and how to use Best Before and Use By dates when prioritising work
  • Appreciate how values define value, and how this differs between organizations

Details and tickets on the EventBrite booking page. Alternatively you can book directly with me.

The post Adding Value to User Stories appeared first on Allan Kelly Associates.

The problem with Product Owners

HeadacheiStock_000014496990Small-2020-05-8-12-40.jpg

Advertisement: at the time of writing there are still a few tickets available for my online User Stories Masterclass beginning this Wednesday, 90 minutes each week for 4 weeks.

After submitting his review of The Art of Agile Product Ownership one of the reviewers sent me a note about the review was and said:

“Gee, I really wish I could be that type of Product Owner.”

His comment made me smile. He nicely summarised much of the argument in Art of PO. The book makes a case for an expansive product owner – one with product management skills and business analysis skills; a product owner who looks to improve value over the short and long run, and for product owners with more customer empathy and marketing skills than code empathy and technical skills.

Many of the Product Owners I meet aren’t really owners of the product. Rather they are “Backlog Administrators” and as such the industry is creating another problem for itself.

Over the years the product owner role has been diluted, so many product owners are not really owners of their products. Instead their role is limited and constricted. They are judged on how many features they get the team deliver, whether those features are delivered by some date or whether they have met near term goals of doing the things customers – or internal users – are complaining about.

In other words the whole team is a feature factory: requests go in and success is measured by how many of those requests reach production.

Sure that is one way to run a team, and in some places that might be the “right” way to do it (a team dedicated to addressing production/customer issues perhaps.)

Unfortunately agile is prone to this failing because of the sprint-sprint-sprint nature of work. The things in front of you are obviously more valuable than the things that are not. The people shouting at you today obviously represent greater value than those who are sitting quietly asking nicely. And both groups can mask bigger insights and opportunities.

Hang on you say: Is this the same Allan who has argued against long term planning? And against analysis phases? The Allan who always argues for action this day?

Well, yes I am that Allan. And I agree that I regularly argue that teams should get started on coding and limit planning and analysis.

But that doesn’t mean I’m against these things, it only means I’m conscious of the diminishing returns of planning; and I know that what is technically possible frames not only the solution but the problem – because often we can’t conceive of the problem until we see how a solution might change things.

Teams need to watch out for the “bigger” questions. Teams need to take some time to thing long term. Time needs to be spent away from the hurly-burly of sprint-sprint-sprint to imagine a different world. Dis-economies of scale may rule but there still needs to be consideration of larger things, e.g. jobs to be done over user stories.

The responsibility rests with the Product Owner.

They own the product the way I own my house: I have to pay the mortgage and I have to change blow light bulbs but I also need to think: how long will the roof last? Will we build an extension? When will we rebuild the patio? And where am I going to put a car charging point when that day comes?

I don’t take those decisions in isolation, I don’t spend lots of time on them and I don’t let them get in the way of work today. But spending a little time thinking about them, and I may well leader on the discussion. Taking a little time to think through out how things might fit together (don’t do the roof until after the extension is built) has benefits.

And so many Product Owners aren’t doing that. Worse still their organizations don’t expect them to. Maybe they see an Architects doing that, or a Product Manager – or maybe nobody does.

The thing is: the Product Owner is the OWNER.

Managers and architects are hired and fired as needed. The buck stops with owners.

Many organizations have got this the wrong way round. The Product Owner role is diluted and individual Product Owners emasculated.

Advertisement: at the time of writing there are still a few tickets available for my online User Stories Masterclass beginning this Wednesday, 90 minutes each week for 4 weeks.

The post The problem with Product Owners appeared first on Allan Kelly Associates.

User Stories: online workshops – booking now (free for furloughed)

iStock-512327190s-2020-05-4-09-16.jpg

Last month I ran an experiment: I delivered my one day workshop on User Stories, Requirements and Backlogs as a series of four 90 minute workshops and offered them for free. I had a great response with over 20 people signing up immediately and during the last month we all learned something – I had great feedback.

I’m now reworking that workshop further into two series: User Stories Masterclass and Value Driven Planning. Both of these will run as four 90 minute workshops online over successive weeks.

Booking is are now open for User Stories Masterclass. This will start next week, Wednesday 13 May (3pm, London BST time.) There will be one class at the same time each week.

Places are limited so don’t hold off booking. (If you miss out let me know and I’ll try to schedule another soon.)

Workshops 1 and 2 will focus on User Story format and what makes a good story. Workshop 3 will consider some of the processes that fit around User Stories (definitions of done and ready, acceptance criteria, etc.) and, importantly non-functional requirements. The final workshop will look at splitting stories.

I’m making some tickets free for those who have been laid-off or furloughed because of you-know-what.

For everyone else there are two price points. “Self pay” for those of you who are paying out of your own pocket. And a more expensive “Company paying” ticket for those with a generous employer – who can reclaim or avoid UK VAT.

To sweeten the extra price I’m including a one-hour one-on-one consultation for those who pay the higher price.

More about the value workshop soon – and why the split? Well, a) it turns out I have more than enough material, and b) people had some great questions and I want to allow time for conversation.

More details on my website.


Subscribe to my blog newsletter and download Project Myopia for Free

The post User Stories: online workshops – booking now (free for furloughed) appeared first on Allan Kelly Associates.

Pandemic in the digital age

plastic-syringe-and-test-tubes-2020-04-14-10-10.jpg

It was hoping to keep this blog virus free. Indeed my “Conflicts in coaching” was going to be the first of several on agile coaching (what else could I do in the air going to and from Agile on the Beach New Zealand?) But…. the world has changed, I’ve changed…

It is a very scary time. Both health wise and economically: I know at least one software engineer who has lost his job as a result of the slow down. But I also know random (inappropriate) coding jobs still appear in my mailbox, I continue to see job adverts on Twitter and LinkedIn and I know one company that has landed work and had to hired contractors to work on a corvid-19 project. So some observations…

Observation 1: Covid-19 will go down in history as the first digital health crisis.

Digital technology has a big role in fighting the virus. Decisions and actions are being driven by software models of what could happen. The famous Imperial model is now OpenSource and Microsoft engineers are reported working to improve the model. (At a few hundred lines of R code there isn’t that much to refactor – although there are some very long functions and I can’t see any unit tests.)

Apps are being created to track contacts and you can bet that the search for antidotes and vaccines is utterly dependent on software. Digital powered home delivery networks and internet shopping have made closing the economy just about possible.

Those who are not directly fighting the virus are continuing to work because of digital technology. Zoom, Skype, and the like might be the most obvious beneficiaries of the virus but many others will benefit too. Although the virus is simultaneously putting a strain on our digital infrastructure and necessitating human action – witness the search for Cobol programmers in the US.

Not only have most IT, sorry digital, workers decamped to home but so too have many others – in fact almost any occupation that can. Schools are delivering lessons and distributing home learning kits online. Industries which can’t move to online working will suffer the most. (Except those which put themselves in harms way like medical staff and, to a lesser degree, delivery staff.)

And when not working online media like Netflix, YouTube and BBC iPlayer keep us sane.

For us digital folk this is no big deal. It is an extension of normal life: we are at home 5 days a week not one. But for other folk, this is big. Even the most digitally inept lawyer is having to get with the technology. As people are forced to become familiar with digital technology …

Observation 2: Digital technology adoption will be accelerated by the virus

Which means, while some technology companies (like my friend’s) will not survive, those that do are set for a boom. Post virus swaths of the economy will be destroyed but technology is in for a boom.

That boom is driven by the three forces above: 1) unlike others, our industry is not destroyed, 2) technologist continue to work remotely, and 3) non-technologist will learn to use more technology.

In particular digital healthcare – both back-office big data background analysis and customer centred applications – will play an oversized part. This field was already growing rapidly but the experience gained during this crisis can only help the sector.

But also…

Observation 3: The economic devastation caused by the virus will open up many new opportunities for digital companies to enter markets and thrive

Companies which fail create opportunities for new companies – either a like-for-like replacement or a new type of company. Previously, while those companies were active, digital technology had to compete with the existing providers, the incumbents. With those companies gone the way is clear for new digital technology companies to enter the market.

I’m not saying this isn’t going to be horrible; company failures will be painful and it new entrants will take time to get established.

And what of Agile?

Observation 4: Covid-19 is the ultimate test of agility

Forget arguments about what is agile and what is not agile. Forget ScrumBut, Wagile and the other insults hurled at those judged to be less agile than thou.

Forget agile assessments and agile maturity frameworks; forget ticking off ceremonies and declaring yourself agile. In the new world the more agile you are the greater your chances of survival.

On paper you may have the most agile team in the world but, if that team, and your organization, cannot now demonstrate how it changes rapidly it just isn’t agile.

Every single plan that existed before March 1st is now invalid. Right now companies need to pivot like never before. Agility helps companies pivot. Those who can’t pivot, or can’t pivot fast enough stand to loose the most. If you can’t pivot you aren’t agile, QED.

Companies which still operate in hierarchal command-and-control mode will find it more difficult to switch to distributed teams and remote working. When everyone is remote you need to delegate decision making. Companies which don’t trust employees, companies which constantly check what employees are doing will find home working incredibly difficult and expensive.

Individuals and interactions are more important than ever before. Processes and tools are essential but few heavy weight processes will survive the instant shift to completely distributed working. Any tool which doesn’t help now is an impediment.

Those companies which are still struggling with technical liabilities (aka technical debt) will find the cost of living with those liabilities just increased.

Observation 5: Test driven medicine

Day after day I read in the papers that the UK is not doing enough testing. It seems that countries like South Korea which do a lot of tests and base their strategy on knowing who is infected (and therefore who is safe) and then tracing the virus are doing best.

That means testing needs to be rapid – a short feedback loop.

And testing needs to be cheap so it can be done at scale.

Doesn’t that sound familiar?

The cost of not testing is precautionary isolation. That cost is not sustainable.

If you could test anyone, and everyone, instantly the offices, shops and schools could reopen: you would just test everyone who arrives.

The testing strategy agile has been advocating is now needed to fix the world. And in the UK the Government seems to be as resistant to a test first approach as the most obstinate software manager or engineer.

As much as I hope the world will shortly return to how it was it will not. It will never be the same, we don’t quite know how it will be but it is already clear that digital technology and agility will be part of it.

(Test tube image taken from PublicDomainPctures.net)


Subscribe to my blog newsletter and download Project Myopia for Free

The post Pandemic in the digital age appeared first on Allan Kelly Associates.

Allan’s online offerings

iStock-1213772070lite-2020-04-13-15-52.jpg

I admit it: I’ve been scared of running online training workshops for years.

I just didn’t see how they fitted with the way I liked doing things. Online training I’ve joined in the past has been boring and I’ve found it difficult to keep my attention. So I assumed that everyone was like that and all online training suffered from the same failings.

But like so many other people in the last few weeks I’ve been forced to reconsider.

And I’ve had really positive experiences. In fact, I’m wondering if online might actually be better suited to my preference for interaction and discussions. Although I’ll admit, it makes designing exercises harder.

Last week I delivered what was a 2-day agile course as four half-day workshops. This seems like a win-win: it is less disruptive for the team undertaking the course, avoids days spent on video meetings and provides more opportunities to adjust content to suit need – plus its cheaper!

So, as of now I have two workshops redesigned and tested online. In addition I’m making myself available for online consulting/coaching. In the past it was only feasible to provide consulting and coaching to companies who could buy whole days. Delivering this online makes it possible to work with individuals.

Improving with Agile
Based on my existing and much delivered Agile Foundations course this four half-day online workshop looks at how teams can use ideas from the agile toolkit to work better. This could mean going from “no agile” to “agile”, or from “existing agile” to “better agile.”

Stories and Value
Derived from my long standing Requirements, Backlogs and User Stories 1-day workshop this is now delivered as four 90-minute workshops. This revised version continues to look at how to write good user stories however now the emphasis is on understanding and delivering business benefit, i.e. value.

I’m part way through delivering Stories and Value to those who signed up to my free workshop offer a few weeks back.

These are on my website now.

I may well offer both of these workshops as public (open enrolment) courses in the next few weeks – although this time I will need to levy a charge. If history is a guide I expect private deliveries to existing teams will be the main customers.

If you are interested in either – joining a public workshop or having this workshop for your own team – please contact me. Who’s interested?

I’m still finalising my plans for personal coaching and consulting, so again, if you are interesting in getting some of my time please get in touch.

And if you have suggestions for workshops or tutorials I should offer I’d love to hear your ideas!


Subscribe to my blog newsletter and download Project Myopia for Free

The post Allan’s online offerings appeared first on Allan Kelly Associates.

Coaching conflicts

CoachingConflicts-2020-04-1-12-36.jpg

Last year I was coaching a team. One of the big problems the team faced was excessive work in progress – and tendency for developers to start new work when they hit a blockage. Eventually, with the help of the Product Owner who saw the problem too, we starved the work pipeline. The team actually ran out of work. We saw this as a great success. It had never happened before and meant we could really focus and prioritise work.

Unfortunately, this happened when the two of us were not instantly available. You can argue that we should have been instantly available. Or that people should have made more of an effort to contact us. Or that we should have left a secret stash of work to do. Or that the team should have self-organized to fix the problem. That is easy in retrospect but really, I still don’t see it as a problem.

A few hours without work? I see it as a momentous moment, the start of something great.

But that is not how others saw it. The team, the Product Manager, another Agile Coach on site, and anyone these people could tell were quick to tell us how awful it was: “the team ran out of work.” Word spread quickly that the team had run out of work. My name was dirt.

Doing good by one group isn’t always seen as good by others. When you work as an agile coach conflicts occur daily. But some are bigger and more persistent than others.

For most of the last 10 years I’ve mainly worked as a “drop in” coach (“light touch” I like to call it). I visit clients for a short period of time, talk about improvements, problems, solutions, give directive or non-directive coaching and don’t return for days or weeks. I’m not the same clients every week, maybe I drop in a few days a month and talk to people.

Last year was different, I spent almost all of it with one company, mostly embedded in one team as an official “Agile Coach.”

Comparing these two approaches to coaching has left me with a lot to reflect on. In particular I found a number of conflicts which troubled me, I’m not sure I ever worked these out and I’m sure others find the same things. So I’d like to share…

Responsible to the team, accountable to the organization

I was lucky, it was one of the team members who called me in but it was the bigger organization that was paying my fees. While I felt responsible to the team I was accountable to the organization.

That organization wanted things and expected me to deliver: they wanted a team which performed better (delivered more stuff and more value!) They wanted the team to share common practices and ceremonies with other teams.

For the organization I was the bringer of change to the team. But I could only do that if I was accepted by the team. That limited my ability to push through changes. Even if nobody else saw that conflict I felt it every day.

At one level team did want to change but they also wanted the organization to change and I had very little power there. Both sides, the team and the organization had no-go areas. More conflict.

The organization restricted my ability to do things I thought would improve the team. Things the team accepted would help: like spending money on training. So I was bearer of bad news to both sides: one side saw me asking, then arguing for money while the other saw me failing to deliver.

That organization also expected me to operate within the organization: join coaches meetings, sign up to shared coaching goals, complete team assessments, etc. None of these things were necessarily bad in their own right but it meant I had two masters: the team and the organization.

When push came to shove I prioritised the team but I know some coaches who prioritised the organization. I know some team members mistrusted their coaches because they believed their coach would put the organization first.

Honouring self-organization but creating change

So an agile team is self-organizing. That gives them the right to self-organise to work exactly as they do today. Self-organization gives them the right to not change anything – something I wrote about way back in Changing Software Development.

But, almost by definition, the (agile) coaches role is to bring about change, to help the team do better. Conflict is inevitable.

Sure you say “its a question of motivation … the coach needs to create the motivation to change and do better” and I would agree, but, even in creating that motivation one is creating change, one is intervening. Which brings us nicely to….

Leading without authority

Agile coaches lack authority – if they had authority they would be managers, I’ll blog about that in future. In a way not having authority is liberating, one can’t use the whip no matter how much one wants to! But it is also difficult.

The organization, and the coach, wants to create change but without authority even the smallest changes can become massive efforts. When the team is divided themselves, or even when one team member objects to implementing a change becomes like wading through treacle. That can be demoralising for the coach.

Yet a little authority can go a long way in pushing through change and overriding objections.

And on occasions I did reach for authority, but that creates a conflict within oneself as a coach: was I right to do it? am I honouring the team? the team members? am I creating a learned dependency?

Accepted while pushing the unpopular

Nowhere is that conflict clearer then when pushing through an unpopular change in the face of opposition – even minority opposition. As a coach one risks loosing future changes because, most change the coach “initiates” is done with the acceptance of the team, pushing through an unpopular change – even with a majority, even with leadership support – risks future acceptance.

One is constantly asking: how far can I take this team right now?

And: if I take them too far will they trust me tomorrow?

And, most of all: am I right to do this?

Hardly a day pasted last year when I didn’t agonise over these questions. And as I write this I imagine one of those teams members reading this and saying “Huh, and you got it wrong.”

Who gets the credit?

As a coach your job is to make others perform better, but really, only they can perform better. You can’t make them, you can only help them. The final decisions rest with them.

So who should get the credit? – surely it is them, they made the change, they did something different.

That creates an inner conflict. It also creates a conflict with the organization: why should they keep me employed? After all I didn’t make any difference, they did it.

We know the value of positive praise and acknowledgement, but when there is nobody to praise you, when the team don’t recognise the coaches role (which can be hard if the coach is doing a good job) then one becomes demoralised and that saps ones strength to carry on.

As people we need acknowledgement, as a human we all have needs. But the coaches role so often demands that we forego acknowledgement, praise and recognition.

Conflicts exists

This isn’t an exhaustive list of the conflicts I’ve encountered and hopefully as you read this you can see solutions – I can myself! But what I want to say is: these conflicts exist, I’m sure other coaches have them and even when there are solutions those solutions need to be applied.

Living with these conflicts can be hard, mentally and emotionally. Burnout happens to coaches.

And organizations get fed up with coaches who don’t deliver change, don’t turn up to non-team meetings, keep asking for money, don’t crack the whip or exceeds their (none existent) authority.


Subscribe to my blog newsletter and download Project Myopia for Free

The post Coaching conflicts appeared first on Allan Kelly Associates.

Want to join a (free) online workshop?

 

iStock_000004600893Small-2020-03-24-11-31.jpg

Consider this a gift, its also an experiment. Numbers are limited so if you would like to join please e-mail me today – if it goes well I’ll repeat, although I might ask for money next time.

I’m going to tun an online workshop entitled: Stories and Value.

Participation is limited to a 16 and its going to be first come first served – blog/newsletter readers are getting the first chance to sign-up.

This is based on my existing “Requirements, Backlogs and User Stories” workshop which has itself mutated into a discussion of stories and value. The workshop will run as a series of 90 minute sessions, one a week for four weeks online.

I want the workshop sessions to remain interactive, I’m sure I will use some slides at some point but I want to keep it interactive. So I’m going to limit participation to 12.

The draft schedule is:

  • Workshop 1: How value influences our thinking
  • Workshop 2: Good and Bad User Stories
  • Workshop 3: Estimating story value
  • Workshop 4: Time value profiles and closing discussion

I plan on using exercises throughout and I think I know how to run them online. And I want discussion! – I may even set a little homework between sessions.

But in all honesty, it’s an experiment. So, I’m not planning on charging for this – it is Free!

If you find it valuable you can make a payment – like those “pay what you like” restaurants. That will itself be feedback.

I’m thinking Wednesday, 3pm UK time so those in mainland Europe could join too (sorry US and Asia, maybe next time); on a Zoom conference. Start next week, April 1 ? – once I know who’s in we might debate this between ourselves.

My thinking is still developing on this so let me know if you have any ideas to contribute. (And if you can’t join but want to let me know, feedback is valuable too! Likewise, if you are tempted but want to see something different please tell me and I’ll see what I can do.)

So, if you want to join these sessions please e-mail me, allan@allankelly.net.

This is a minimally viable experiment so its all a bit crude.

The post Want to join a (free) online workshop? appeared first on Allan Kelly Associates.

#NoProjects everywhere

iStock-173005469Medium-2020-03-3-16-10.jpg

After years of shared #NoProjects advocacy I finally for to meet Evan Leybourn exactly two years ago. Over lunch in a Melbourne cafe we talked #NoProjects and how we were both moving on. It may have been a little pre-emptive and some might call it arrogant but we felt #NoProjects was triumphant.

Two years on and projects are still with us, projects aren’t going away anytime soon but the ideas behind #NoProjects are mainstream. The leading thinkers in the software/agile/digital space generally support the thesis – certainly nobody is arguing the case for projects. Cutting edge teams don’t use projects. The language of projects remains (unfortunately) but the supremacy of the project model increasingly looks like a historical footnote.

Two years on from that lunch and it is clearer than ever that the (digital) world is moving away from projects. This was really brought home to me last week when I joined an unconference organized by the McKinsey consultancy. Nobody said “#NoProjects” but nobody was talking projects. Nobody was advocating more project managers or new project management approaches. The CTO of a bank came pretty close to saying “#NoProjects” but why bother? – not saying it meant it was accepted.

#NoProjects is in your face. #NoProjects is an invitation to start a flame war. #NoProjects is confrontation in itself. #NoProjects is very negative. #NoProjects doesn’t tell you what to do only what not to do.

Back in 2013 #NoProjects needed saying, Josh Arnold, Steve Smith and myself started Tweeting it to death – Evan came later. (I think it might have been Josh who first used the tag.)

As much as I’d like to take all the credit we were just the public face of #NoProjects. We were far from alone. Woody Zuill and Vasco Duarte started the #NoEstimates movement about the same time. While in my mind #NoProjects and #NoEstimates are different things many people see them as two sides of the same coin.

I’d first heard Mary Poppendieck talk candidly about problems with the project model over dinner at Agile on the Beach 2011. Many, many, other people were reaching the same conclusion. Once you start looking at the project model, especially in an agile environment, the problems are easy to see.

The logic against projects can be overwhelming but exposing it was a career threatening move. Even today being an open advocate for #NoProjects means there are jobs you cannot apply for. None of the original names will ever be considered for a project management job.

Look around you today: The Project Manager role is being replace by the Delivery Manager role.

SAFe is a #NoProject model.

Spotify is a #NoProject model.

Continuous Delivery is a #NoProject model.

And my own entry: Continuous Digital is certainly #NoProjects (it was written to tell you what to do instead of projects).

Sure masochists can add projects to SAFe, Spotify and CD but why? These models work well enough without projects.

Even Government departments suggest funding teams not projects.

Today, at every conference and event you will hear people say “Products over projects.” There is a realisation that products last, projects end – who wants to work in a business that plans to end?

Again, to be clear: I’m talking about the digital world, what we used to call software or IT. I don’t know about construction, transport, policing or whatever other discipline you might want to draw a parallel with. I’m sure, some projects will always exist. Somethings do end. Even I will end one day.

That the IT/software/digital world can do better than projects is now recognised. Other management models create more valuable outcomes.

One might say that #NoProjects is heading into retirement. As Josh said:

“The first rule of #NoProjects is not to talk about #NoProjects.”

So don’t wave the red flag of #NoProjects and rub peoples noses in it. For your own benefit understand where the project model goes wrong. Use that knowledge to watch for problems such as goal displacement, commitment escalation, imaginary triple lock contracts, undercutting quality, control through planning, value destruction, cost of delay ignorance, Diseconomies of Scale of course, and unlearn the project funding model.

(If you haven’t already check out my own Project Myopia or Evan’s #NoProjects book.)

Then, set a course for a better world: call it SAFe, Spotify, Products, Continuous Digital, Continuous Delivery or whatever you like. Aim to harness the power of early release, evolving design, requirements and learning. Retool your governance process and management models.

Use the carrot not the stick.


Subscribe to my blog newsletter and download Project Myopia for Free

The post #NoProjects everywhere appeared first on Allan Kelly Associates.

All about Agile on the Beach

This week has been a bit of a feast about Agile On the Beach. So here is a list of this weeks writing and some previous posts.

And some older entries that explain us:

This possibly shows that AOTB takes up far more of my life than it should! ?

The post All about Agile on the Beach appeared first on Allan Kelly Associates.

Mimas is OpenSource

256px-Mimas_Cassini-2020-02-24-11-36.jpg

That picture above is Mimas, one of the moons of Saturn – yes, I’m still a bit of a “geek”. Mimas is the name I chose for the Agile on the Beach submission system I started developing about four years ago.

I am a bit surprised that Mimas has grown to over 10,000 lines – mainly Python and HTML, a very small amount of JavaScript and a super tiny bit of CSS. O, and 239 unit tests which now take about 8 second to run. (Like so many other systems the front end isn’t covered by automated tests. This hasn’t been a big problem, the tests I have giv great confidence.)

I’m not completely surprised by the fact that four years later we are still using it.

The code has lots of failings – doesn’t every system? – but I’m immensely proud of it as more than I’m embarrassed by it. I’m particularly proud of the way the system held up to 300 submissions and 55 reviewers this year. This was the most use it has ever had.

As of last month the system is also OpenSource – MIT License. You can browse the code – and tell me about all my failings: Mimas on GitHub.

The system itself runs on the Google App Engine here. Anyone can log in and create their own conference. Although this being the post-review period, and me having some time, I’m taking the opportunity to make some improvements. If it is down it won’t be down for long. Unfortunately Google are forcing a database upgrade (NDB to Cloud NDB) on a move from Python 2.7 to 3.x (which I should have done a while back.)

Once upon a time I thought that other people might like to use the system for their conferences but nobody ever has. The offer is still there.

I’d love it if anyone else wants to help with development on the system – but I’m realistic to know this is unlikely. (If you want to help there are a lot of places in the UI where a little JS or CSS could improve things. In the backend I know a few places that could do with changes too.)

For the record this is what Mimas does:

  • Conference organisers create a conference and accept submissions.
  • Speaker details are retained for future conferences as are talk details.
  • Submissions are accepted into tracks, they can have co-speakers, formats and duration are configurable.
  • Two rounds of reviewing are supported, these are configurable. AOTB uses scoring for round 1 and ranking for round 2.
  • Reviewers can volunteer and be assigned (random) submissions to review.
  • Conference permissions allow for different users to have different capabilities.
  • E-mail acknowledgements, acceptances and declines are handled via SendGrid – you can also define custom messages via templates.
  • Half a dozen or more types of report plus export to Excel capability.
  • OAuth login currently supporting e-mail, Google and Facebook via Firebase.
  • Share reviewer feedback and comments with submitters.
  • Some conference branding.
  • (There is an open speakers directory and tagging mechanism, I should either improve this or scrap it.)

I’m currently building out a scheduler so the accepted submissions can be organised in the system too. Its half done.

There are bunch of ways I could develop it further: it could support paper review rather than conference review, it could support shepherding, it could be used for reoccurring events, and a whole lot more.

Finally, it is surprisingly cheap to run on the Google App Engine.

Anyway, its OpenSource, its live, let me know what you think.

The post Mimas is OpenSource appeared first on Allan Kelly Associates.

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.

The post Why does AOTB have its own submission system? appeared first on Allan Kelly Associates.

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.

The post Notes on Agile on the Beach submissions appeared first on Allan Kelly Associates.

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”

The post Agile on the Beach – update on review process appeared first on Allan Kelly Associates.

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 said 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? XanpanNewlite-2020-02-5-12-18.jpg

Xanpan

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

The post Framing the question frames the answers – my crown jewels appeared first on Allan Kelly Associates.

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!

The post Dear customer, the truth about IT appeared first on Allan Kelly Associates.

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? XanpanNewlite-2020-01-31-12-05.jpgXanpan

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

The post Object oriented hierarchy? – a postscript appeared first on Allan Kelly Associates.

New Zealand, Australia and Fresh ideas

FreshNZ-2020-01-21-11-41.jpg

Before this weeks regular post (In defence of hierarchy) a commercial, by me, for me ?

In March I’m going on tour, I’m speaking at Agile on the Beach New Zealand. I hope to call into Australia on the way, and I’ve been invited down to Wellington too.

My itinerary is not confirmed yet and ideally I’ll delivery some more talks – and charge some fees to make the trip more sensible. So if you know anyone in Australia or New Zealand who would like me to deliver some training or presentation please put them in touch, allan@allankelly.net.

Which makes it a great time to introduce my Fresh Ideas workshops.

These are short (2 to 3 hours) workshops which expand on ideas you will find in my conference presentations and books. So far these are:

  • Value and the story: this includes an estimation poker exercise which is a lot of fun
  • Continuous Digital: ideal for regular readers of this blog who want to share these ideas with their colleagues.
  • Strategic capacity planning: this is largely an exercise extracted from my Strategic Product Owner course and builds on experiences with capacity planning

I’m also including two old favourites under here, maybe not entirely fresh but they fit the bill in other ways:

  • Better User Stories: extracted from my Requirements, User Stories and Backlogs workshop
  • Agile refresher: this features in my agile training and has been run a number of times as a stand alone exercise, it is a lot of fun and a way to start a conversation about getting better

As always, if you are interested in any of these get in touch – especially if you are in New Zealand or Australia.

The post New Zealand, Australia and Fresh ideas appeared first on Allan Kelly Associates.

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”

The post In defence of hierarchy appeared first on Allan Kelly Associates.

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”

The post Plan less, do more appeared first on Allan Kelly Associates.

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.

The post Requirements, User Stories & Backlog appeared first on Allan Kelly Associates.

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”

The post Flipping job descriptions appeared first on Allan Kelly Associates.

Product Owner: all about the what

FRTbasic-2019-11-15-14-47.png

I feel compelled to write this blog because I keep coming across the wrong type of Product Owner. I feel bad about writing this blog because a) I’ve made these points before in other forums so I’m repeating myself, and b) at the end of the day you, your team, and your organization, is free to define and use any title you like for any role you like, you are free to define any given role as you like.

So let me set out my model of a Product Owner and then at least there is a model to compare any other definition with.

Our old friend the Triangle of Constraints can help here – also know as “The Iron Triangle” and pictured above (I like to call it the FRT triangle). Now notice the version I use is slightly different from the more common model:

  • Rather than “cost” I label one side of the triangle “People”. I could label it resources but in software development resources are overwhelmingly people and the knowledge they bring. People deserve respect, calling them “resources” makes them sound like paperclips.
  • For software development costs are function of how many people you have and how long you have them for: costs = people x time. OK, there are some other “resources” to add to costs, e.g. buying laptops, renting time in the cloud, and so on but these are often themselves a function of the number of people you have. Such costs are a small increment on top of the wage bill.

Now the number of people you have is fixed in the short term, or to be more accurate: it is upward fixed. People can get ill or resign at anytime but adding people takes time. So in the short run one can consider that dimension fixed.

Time is also fixed. There is usually a business deadline, or rather a business benefit which is time elastic so you have a date to aim for. And on agile teams there are sprint deadlines (two-weeks, two-weeks, two weeks). So a large part time is fixed.

The final side of the triangle is labelled features or functionality, but might be labelled “requirements”, “the what” or “what are we building” – I like to think of it as the demand side.

With me so far? – so far that should be uncontroversial.

Now the traditional Project Manager role, and to a lesser degree the newer Delivery Manager role, tend to regard the third side – the what side – as fixed. There is a thing to be delivered. It is a known thing. It has been decided on and the manager’s job is to get it delivered.

To this end Project Managers are trained to regard the “thing to be built” as a given, preferably fixed, thing. Their training centres on the other sides: cost and time. They are trained both in rationing these commodities and allocating them in an efficient way. When things go wrong these managers ask for more time (which means more money because the same people need paying) or more people (which both costs more and makes things worse because of Brook’s Law).

So to summarise: traditional Project Managers focus on “when” and the input variables: people/resources and money.

Can you guess what I’m going to say next?

Product Owners – plus Product Managers and Business Analysts – focus on the “what”. What do we need to build next? What has the most benefit? What should we be building for the future?

For Product Owners the time and people are fixed. (This is most obvious in an agile environment but is actually true everywhere sooner or later.)

The thing being built is negotiable, the desired outcome may be achieved by different routes, different technologies and different solutions – the different time and cost will be a consideration but outcome is the primary focus.

In other words: Product Owners are all about the what.

In order to operate in the what-space product owners need authority and legitimacy to flex what they are building. When they don’t have that they are reduced to backlog administrators simply ordering the backlog and feeding it to technical teams. That turns the role into a type of Project or Delivery Manager.

So if you need to tell a real Product Owner from all the other misinterpretations of the role ask:

  • Does the product owner focus on what?
  • Can the product owner discuss different solutions and approaches to achieve an outcome?
  • Is the PO flexible about the backlog? (as opposed to slavishly trying to deliver it all)

Real product owners can answer Yes to all three.

(Notice I’m deliberately being careful in what I say about “Delivery Managers.” This role is still emerging and as such its wrong to generalise about it too much. In so much as a Delivery Manager brings management skills, communication and organization to an effort it can be a positive role. When a Delivery Manager is relabelling of the Project Manager role it can be damaging.)

Now that said, the fact that some organizations choose to define the “Product Owner” role as a role closer to “Project Manager” or “Delivery Manager” rather than a role closer to “Product Manager”, “Business Analyst” or (heaven forbid) business owner causes a lot of confusion.

Perhaps I’m wrong here, perhaps the “Product Owner” is a type of “delivery manager” but I think the majority of writers, thinkers and practitioners agree with me.

Even if you disagree with me I hope we can agree on one thing: because there are different interpretations and implementations of the role there is room for confusion; and that confusion makes it harder to fill the role and harder to be seen as a successful Product Owner.


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”

New book: The Art of Agile Product Ownership

AOPO-2019-11-15-14-47.jpg

The post Product Owner: all about the what appeared first on Allan Kelly Associates.

Retrospective cards, product Owners and #NoProjects

Sample-2019-11-10-16-30.jpg

A quick follow up on my last two blog post.

First, Team Retrospective cards – above – are now available for sale:

Both sites accept other credit cards so don’t worry if you have another currency and we can post anywhere – if you get stuck get in touch and we’ll find a way that works.

Second, as discussed in my last blog – Mission Impossible: the Product Owner – I delivered a presentation on that subject at the Oredev conference in Malmo last week. The slides are available for download: Mission Impossible: the Product Owner.

In retrospect I think the presentation should have had a big question mark (“?”) in the title. In many ways I’m asking “Is the Product Owner role impossible to fill well?”. I had some really good discussions on this topic after I gave the presentation and I will blog more about the role soon. In the meantime check out my new book if you want more of my thinking, The Art of Agile Product Ownership.

Finally, while I was at Oredev I gave another presentation: Evolution: from #NoProjects to Continuous Digital (also available for download). This presentation itself was an evolution. So I’ve christened this version the “2020 edition” to distinguish it from the earlier version. I am attempting to do two things here:

One, be clear that the #NoProjects argument has itself moved forward. When #NoProjects began in 2013 the argument was very much “The project model is not a good fit for software development.” Now, as we approach 2020, the argument has moved on: business (and just about everything else) is digital, in a digital world advancement means technology (software) change. Therefore rather than following a start-stop-start-stop project model are organizations need to structure themselves for continuous digital technology enhancement.

Two, building on that argument I try to talk more about how our companies need to update their thinking. Specifically what does the new management model needs to look like?

More on all these subjects in my usual depth soon.

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”

New book: The Art of Agile Product Ownership

The post Retrospective cards, product Owners and #NoProjects appeared first on Allan Kelly Associates.

Mission Impossible: the Product Owner

SecretAgents-2019-10-27-18-53.jpg

Is the product owner role impossible to fill well?

Do we set product owners up to fail?

Have you ever worked with a really excellent product owner? Someone you would be eager to work with again?

The lack of really outstanding product owners isn’t the fault of the individuals. I think product owners are asked to do a difficult job and are not supported the way they should be. Worse still, in many organizations the role of product owners is misunderstood, they are seen as a type of delivery manager when in fact they are a type of product owner.

There questions have been on my mind for a while, next month I’m giving a new presentation I’m Oredev in Malmo – and which coincides perfectly with the publication of my new book The Art of Agile Product Ownership (funny that). So by way of preview…

I’ve long argued that product owners need four things in order to do the job well: skills, authority, legitimacy and time. Lets look at each in turn:

1. Skills: the kind of thing a product owner learns on a Certified Scrum Product Owner course are table stakes. Yes POs need to be able to write user stories, split stories, write acceptance criteria, understand agile and scrum, work with teams, plan a little and so on. While necessary such skills are not sufficient.

The bigger question is:

How does a product owner know what they need to know in order to do these things?
How do they know what customers want?
How do they know what will make a difference?

Product owners need more skills. Some POs deliver products which must sell in the market to customers who have a choice. Such POs need to be able to identify customers, segment customers and markets, interview customers, analyse data, understand markets, monitor competitors and much more. In short they need the skills of a product manager.

Other POs work with internal customers who don’t have a choice over what product they use, here the PO needs other skills: stakeholder identification and management, business and process analysis, user observation and interviewing, they need to be aware of company politics and able to manage up. In other words, they need the skills of a business analyst.

And all POs need knowledge of their product domain. Many POs are POs because they are in fact subject matter experts.

That is a lot of skills for any one person. How many product owners have the right skills mix? And if they don’t, how many of them get the training they need?

2. Authority: Product owners need at least the authority to walk in to a planning meeting and state the work they would like done in the next two weeks. They need the authority to set this work without being contradicted by some other person, they need the authority to visit customers and get their expenses paid without having to provide a lengthy explation every time.

3. Legitimacy: Product owners need to be seen as the right person to set the priorities. The right person to visit customers, the right person to agree plans and write roadmaps. They need to be seen as the right person by the organisation, by peers and, most importantly, by the development team.

Authority and legitimacy are closely related but they are not the same thing. While the product owner needs both the lack of either results in the same problem: people don’t take their work seriously and other people try to set the agenda on what to build.

Unfortunately Scrum contains a seldom noticed problem here: product owners are team members, they are peers; the team are self organising and are responsible for delivering the product. (There is an egalitarian ethos even if this is only Implicit.)

But Scrum sets the PO as the one, and only one, who can tell he team what to do.

There is a contradiction.

4. Time: Product owners need time to do their work – which is a lot, just read that skills list and think about what the PO should be doing. And don’t forget the PO is a human being who needs to sleep for seven or eight hours a night, may well have a family and a home to go to.

When does the product owner get to do all of this?

Leave aside the question of where you find such people, or whether our companies pay them enough and ask yourself: do product owners get the support they need from their companies and teams?

So often the PO ends up in conflict with the company about what will be built and when it will be delivered, and they end up in conflict with their team about… well much the same issues every planning meeting.

Think about it: do we ask too much from our product owners?

Do we set up product owners to fail?

I’d love to hear your opinions, comment on this post or drop me a note or leave a comment.

I’m going to leave you hanging here today. In the Oredev presentation I’ll try and suggest some solutions – and there are some in the Art of Product Ownership. (Last year I described one in The Product Owner refactored: the SPO/TPO model.)


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”

Check out my books – The Art of Agile Product OwnershipContinuous Digital and Project Myopia – and the Project Myopia audio edition

The post Mission Impossible: the Product Owner appeared first on Allan Kelly Associates.

New books and cards – stuff happening

RetroCardsLores-2019-09-13-16-51.jpg

I am sure some of you have noticed that my blogs have been a less regular the last few months. That is because I’ve been busy on other stuff. So a break from deep thoughts and advice on the software world to mention some other stuff I’ve been working on.

UserStories_Audio-2019-09-13-16-51.jpg
For a start, available right now, my Little Book of Requirements and User Stories is now available in audio format to listen to. Full details – and the FAQ as a free download on my website. You will find links there to buy it on Audible and Apple (its cheaper on Apple, don’t ask me why.)

To my surprise Little Book has long been my best-seller so I teamed up again with Stacy Gonzalez – who voiced Project Myopia for me – to produce an audio version of Little Book. In the few weeks it has been available sales are already outstripping Project Myopia!

AOPO-2019-09-13-16-51.jpg

Second, as some know I’ve been working with Apress to turn The Art of Product Ownership from a LeanPub eBook into a full regular book. That should be out in October, you can pre-order it on Amazon now.

(And if you can’t wait, I’ve got a pre-copy edit version I can share with you provided you promise to write an Amazon review when the book is published. Mail me or use the contact form if you are interested.)

Finally, that picture at the top of the page. I’ve been working with Nicolas Umiastowski to create a playing card retrospective. These are based on my Retrospective Dialogue Sheets In our experiments they have given retrospectives another twist. More about these soon – and details of how you can get a pack (in the mean time get in contact if you are really keen to try them.)


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”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post New books and cards – stuff happening appeared first on Allan Kelly Associates.

The problem of the problem

Light-2019-09-3-19-31.jpg

Some years ago I was managing a team at an internet TV pioneer. Shortly after a release our biggest customer – ITV – was on the phone complaining about a bug. Unfortunately one set of data fields were retaining their value when they should be wiped clear. It took a couple of months before we could include a fix in the release but we were confident we would make ITV happy.

A couple of hours after the fix went live ITV were on the phone. Why had we removed the daily cache? They weren’t just “working around” the bug, they were utilising it as a feature.

Sometimes it seems the problem you think you are dealing with isn’t the problem you are dealing with. Sometimes the way to solve a problem is not to fix the problem head on. Rather the solution comes from reframing the problem so that it is easier to solve. To put it another way: the problem you are trying to solve is knowing the problem you are trying to solve.

I sometimes think of this as “go and look at it from a different place”. Whatever you are looking at – problem, opportunity, objective, way of life – looks different if you go and stand somewhere else. The more different the place you stand in the more different the thing looks.

Clearly one way of solving a problem is to define it as not a problem: “it is not a bug, it is a feature.” As the story above shows, one person’s “bug” can be another person’s “feature.”

The question is then: is the reframing acceptable to others? – can others share the reframed perspective?

By way of example, lets apply this to agile.

A big part of agile is focus: small user stories, morning stand-ups and sprint planning all help create focus. Once you decide what you are going to tackle you focus on it, push other things out of the way and do it. And do it to completion.

You might call this “eating the elephant”: don’t eat it all at once, carve off a small piece, eat and repeat.

Pushed to either extreme this approach has bad side effects. Focus too tightly or too inflexibility and you might deliver a thing but not a thing which others recognise as a solution to the problem. But taking a view too broadly, or being very flexible, negates the way of working because you don’t deliver anything, – or the solution you deliver doesn’t please anyone (the “you can’t please all the people all the time” problem.)

Reframing can be a powerful technique but it can also work against you if other’s reframe the problem.

So, how do you know, or rather how do you frame and decide what your objective is?

Deciding what the problem is requires some imagination, it requires focus and flexibility – to stare at the problem but be flexible in how you see it. It also requires understanding and then the ability to communicate that understanding to others.

While I often hear people say “we should focus on the problem” I wish we could spend more time focusing on the problem of knowing what the problem is.

Reframing the problem is an inherently human thing. While machines may now, or in the near future, be able to solve many problems there is a problem of knowing what problem to present to the machine.

A big part of human work – often managerial work – is framing problems and deciding which to solve and which not to solve. Framing can make a small problem big, or a big problem small. That is inherently a human activity.

So, how do you know what problems to address? how do you know where to look for opportunities?

Now isn’t that a problem in itself? – surely we could set that up as an objective in its own right. Again it needs defining and framing and… So how does one decide to eat an elephant? And which elephant? And even, why eat an elephant at all?

It all becomes recursive. You can’t recurse for ever so hopefully sooner or later you need to come to the top – otherwise you have just reinvented paralysis by analysis. Detailed problem thinking needs to be combined with vaguer, even oblique, thinking.

To make this very real: I’m a big fan of metrics, they help focus, they help you know if you are going in the right direction. But I detest metrics too because they are a blunt instrument which can mislead so easily.

Metrics are great for focus but they need to be combined with a healthy dose of scepticism and oblique thinking. Metrics have limitations.

Sorry no solutions today. Just awareness of the problem of problems.


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”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post The problem of the problem appeared first on Allan Kelly Associates.

Are we there yet?

Monk-2019-08-2-13-08.jpg

Those of us who don’t code any more, and perhaps many of those who do, need Electronic Monks to help us with software development.

There is an old Douglas Adam’s book (Dirk Gently’s Holistic Detective Agency) which features an Electric Monk. The job of an electric monk is to believe things for you. In Adam’s story people have too many things to believe so they offload all that believing to an electric monk. In my mind I’ve always considered part of the monk’s work to include worrying. I can’t remember if Adam’s says this explicitly or just implies it. (And as I no longer have a copy of the book I can’t check.)

I’m currently very engaged with one client as an Agile Coach (although I sometimes wonder if “Shadow Manager” might be a better term, more of that another day). I regularly find myself staring at the board thinking about the work it shows and worrying about whether it will be done. Sometimes my mind plays “what if games” – “If that card is finished soon, then the other one could move down and…”

The same worry plays out when looking at the backlog showing work not on the board. Or when I’m talking to the Product Owner. Or indeed when I find myself talking to middle managers and others in the company who have an interest in the work the team is doing.

Basically, there is very little any of us can do to move the work through.

Sure I can call a meeting and talk about optimising our workflow. But I’ve done that a few times already.

I could call a meeting and emphasis how important the work is to the company. I’ve seen this done many times. Some non-coders – call them “the business” – seem to think “If only the coders appreciated how important this work was then they would do it faster.” I hated this when I was a coder and I hate it when I hear others saying things like “Do they know how important this is?” Business folk sometimes seem to believe coders sit around drinking tea and coffee for most of the day.

By the way, I almost wrote “and Testers” in that last paragraph but then realised testers CAN make work go faster: they can just drop their standards, turn a blind eye to issues, accept things they wouldn’t have accepted last week. Piling pressure on Testers is a more effective route to getting work done than pressuring coders. But in both cases it is probably just piling up more work.

Pressuring people to do work faster usually creates problems which come a back and bite you pretty damn quick. As I’ve said before: There is no such thing as “Quick and Dirty” … “Quick and Dirty” actually means “Slow and Dirty”

I could go to the coders and ask “Are you done yet?” – or as 5-year olds say in the back of a car on a long journey (or just any journey) “Are we there yet?” In both cases it doesn’t change the time it takes to get to the end, the answer doesn’t usually say much but asking the question will annoy parents and coders alike.

But if I do anything – like calling a meeting or asking “are we there yet?” – which involves distracting coders from working then I am slowing work down. It is self-defeating.

Yes there are things I can do to make work go more smoothly but once a piece of work is in flight there is little I can do. Most of the change I can make are to do with the way work happens. Or to put it another way: I can influence the climate work happens in but I can’t control the individual weather events which are the work items.

All I can do is worry. Thus my desire to offload that worrying to an electronic monk. Maybe more people in and around software developerment need to recognise they are in the same position.


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”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post Are we there yet? appeared first on Allan Kelly Associates.

In the beginning there is architecture, well maybe

PlansiStock_000005364702Small-2019-07-26-14-59.jpg

I was on a panel last year when someone asked that old chestnut:

“Surely before you start coding anything you need to design an architecture?”

As regular readers might guess I took a very simple stand:

“No, you need to get something that works, you need to show you can address the problem in a way that delivers business benefit. You can retrofit architecture when you have shown that your thing is useful and valuable. Sure spend some time thinking about design and architecture but this should be measured in hours not days. As the system grows return to these discussions but keep them to hours not days. Embrace emergent design and refactoring.”

Another panellist disagreed:

“And…”

In 2018 you can tell someone is about to disagree with you because they don’t start “No” or “But” they start “And”

“Companies have databases, and data centres, and standards, and you need to spend some time thinking about them. You need to integrate to existing systems. Changing database schema’s, let alone database application servers is big work and you want to avoid it if you can.”

OK, I can’t remember his exact words but that is the tone I recall. I was told, I was wrong.

Despite all those very real concerns I stand by my position. OK, maybe I need to elaborate a bit so here goes…

The thing is, I have nothing against architecture. When you build a software system you will – before very long – have an architecture. It may not be a very good one but you will have one.

I encourage all developers to study software design and architecture. Coders make hundreds, even thousands, of decisions everyday when they are coding and there is an architectural angle to every decision. Coders need to be versed in good design practices so they make good decisions.

Nor do I have anything against guiding the architecture in such a way that it becomes better with time – indeed I think that is a necessity. Neither do I disagree with architectural conventions in a system or documentation, again they become more valuable with time.

What I’m not in favour of is: believing that you can set it from the start. I believe the more you try to predetermine the more time you will waste.

Architecture is nine-tenths what you have, and one-tenth what you think you have, or should have. Architecture exists in the minds and shared models of those who maintain the system as much as it does in the code.

There are some occasion when there is a completely blank sheet of paper to start with. New start-ups spring obviously, but even inside a large corporation there are occasions when it happens; say when the company wants to experiment with new technologies and approaches, or hedge options. There are two priorities here:

  • Be different, differentiate the solution from what already exists
  • Prove that this new solution delivers something of business benefit

So: pick the solutions that seem right to you now – thats “you” plural, you and the team you are working with.

Maybe spend a little time considering your options (Oracle? MySql? CouchBase? Mongo?) but don’t spend too long, hours not days. Accept that you will learn when you start using your chosen option and accept that you may change it, or that you may make a bad decision and be cursing you decision for ever more.

The thing is: all that time spent designing the architecture, researching options and making decisions is wasted if you do not deliver business benefit. If nobody uses it then having the perfect product, perfect architecture, is pointless.

Anyway, even if you spend months and agree the perfect architecture it will not survive. Once you start work you will find assumptions invalidated, you will find things don’t work as you expected, and you will find that the cheap code monkeys you hired to implement you wonderful design do things you didn’t expect.

Now consider the case where you start a new initiative in an existing environment. There are existing databases and systems to work with. Again you don’t need to spend a lot of time looking at options because you don’t have them. Instead you have constraints.

If the company standard is Oracle for databases you are going to use Oracle.
If you need to integrate with SalesForce then you need to integrate with SalesForce.

You might believe that CouchBase is a better solution than Oracle from the word go. In which case you can either:

  • Accept that right now Oracle is the standard and use it even if it is an inferior solution. In time if you demonstrate business benefit than you will be in a stronger position to change. Or you might find that even an inferior solution is good enough.

Or

  • Argue your case and hope to win: if you don’t win then you are back to the previous option, if you do then great.

What I would not do is: embark on a lengthy examination of all the possible options with the aim of deciding which is best. This takes time and means you will deliver later, which means cost-of-delay will reduce the value you deliver. Sure the great design might generate slightly more business benefit, or get sightly more performance from your development team but you are also delaying.

If you start with a good-enough solution you will learn. That learning may change your opinion, or it might confirm your initial opinion.

Remember: You are not building the ideal system. You are building the best system you can within constraints. The best system you can with the time and money available. In an existing environment many of those constraints are usually given before you start.

Unfortunately, us development folk tend to limit options thinking and exploring to the initial stages of a development effort – usually before any code is written. Once work is underway they don’t consider options often enough, we tend to jump at the first solution we think of.


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”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post In the beginning there is architecture, well maybe appeared first on Allan Kelly Associates.