Posted on

Time value profiles

Allan Kelly from Allan Kelly Associates

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 appeared first on Allan Kelly Associates.

Posted on

Product Owner: meet they customer

Allan Kelly from Allan Kelly Associates

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 they customer appeared first on Allan Kelly Associates.

Posted on

User stories are not…

Allan Kelly from Allan Kelly Associates

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.

Posted on

Sander Hoogendoorn @ Agile on the Beach Keynote – and discount

Allan Kelly from Allan Kelly Associates

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.

Posted on

Product owner as a homeowner

Allan Kelly from Allan Kelly Associates

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.

Posted on

Adding Value to User Stories

Allan Kelly from Allan Kelly Associates

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.

Posted on

The problem with Product Owners

Allan Kelly from Allan Kelly Associates

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.

Posted on

User Stories: online workshops – booking now (free for furloughed)

Allan Kelly from Allan Kelly Associates

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.

Posted on

Pandemic in the digital age

Allan Kelly from Allan Kelly Associates

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.

Posted on

Allan’s online offerings

Allan Kelly from Allan Kelly Associates

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.