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.
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.
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.
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.
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.
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!
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.
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.
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.
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?
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.
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.
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.
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.
