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.
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.
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.
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.
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.
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.
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
“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.
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.
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.
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.