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.

Subscribe to my blog newsletter and download Project Myopia for Free

🔊 Listen to Post

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

🔊 Listen to Post

After years of shared #NoProjects advocacy I finally for to meet Evan Leybourn exactly two years ago. Over lunch in a Melbourne cafe we talked #NoProjects and how we were both moving on. It may have been a little pre-emptive and some might call it arrogant but we felt #NoProjects was triumphant.

Two years on and projects are still with us, projects aren’t going away anytime soon but the ideas behind #NoProjects are mainstream. The leading thinkers in the software/agile/digital space generally support the thesis – certainly nobody is arguing the case for projects. Cutting edge teams don’t use projects. The language of projects remains (unfortunately) but the supremacy of the project model increasingly looks like a historical footnote.

Two years on from that lunch and it is clearer than ever that the (digital) world is moving away from projects. This was really brought home to me last week when I joined an unconference organized by the McKinsey consultancy. Nobody said “#NoProjects” but nobody was talking projects. Nobody was advocating more project managers or new project management approaches. The CTO of a bank came pretty close to saying “#NoProjects” but why bother? – not saying it meant it was accepted.

#NoProjects is in your face. #NoProjects is an invitation to start a flame war. #NoProjects is confrontation in itself. #NoProjects is very negative. #NoProjects doesn’t tell you what to do only what not to do.

Back in 2013 #NoProjects needed saying, Josh Arnold, Steve Smith and myself started Tweeting it to death – Evan came later. (I think it might have been Josh who first used the tag.)

As much as I’d like to take all the credit we were just the public face of #NoProjects. We were far from alone. Woody Zuill and Vasco Duarte started the #NoEstimates movement about the same time. While in my mind #NoProjects and #NoEstimates are different things many people see them as two sides of the same coin.

I’d first heard Mary Poppendieck talk candidly about problems with the project model over dinner at Agile on the Beach 2011. Many, many, other people were reaching the same conclusion. Once you start looking at the project model, especially in an agile environment, the problems are easy to see.

The logic against projects can be overwhelming but exposing it was a career threatening move. Even today being an open advocate for #NoProjects means there are jobs you cannot apply for. None of the original names will ever be considered for a project management job.

Look around you today: The Project Manager role is being replace by the Delivery Manager role.

SAFe is a #NoProject model.

Spotify is a #NoProject model.

Continuous Delivery is a #NoProject model.

And my own entry: Continuous Digital is certainly #NoProjects (it was written to tell you what to do instead of projects).

Sure masochists can add projects to SAFe, Spotify and CD but why? These models work well enough without projects.

Even Government departments suggest funding teams not projects.

Today, at every conference and event you will hear people say “Products over projects.” There is a realisation that products last, projects end – who wants to work in a business that plans to end?

Again, to be clear: I’m talking about the digital world, what we used to call software or IT. I don’t know about construction, transport, policing or whatever other discipline you might want to draw a parallel with. I’m sure, some projects will always exist. Somethings do end. Even I will end one day.

That the IT/software/digital world can do better than projects is now recognised. Other management models create more valuable outcomes.

One might say that #NoProjects is heading into retirement. As Josh said:

“The first rule of #NoProjects is not to talk about #NoProjects.”

So don’t wave the red flag of #NoProjects and rub peoples noses in it. For your own benefit understand where the project model goes wrong. Use that knowledge to watch for problems such as goal displacement, commitment escalation, imaginary triple lock contracts, undercutting quality, control through planning, value destruction, cost of delay ignorance, Diseconomies of Scale of course, and unlearn the project funding model.

(If you haven’t already check out my own Project Myopia or Evan’s #NoProjects book.)

Then, set a course for a better world: call it SAFe, Spotify, Products, Continuous Digital, Continuous Delivery or whatever you like. Aim to harness the power of early release, evolving design, requirements and learning. Retool your governance process and management models.

Use the carrot not the stick.

Subscribe to my blog newsletter and download Project Myopia for Free

🔊 Listen to Post

That picture above is Mimas, one of the moons of Saturn – yes, I’m still a bit of a “geek”. Mimas is the name I chose for the Agile on the Beach submission system I started developing about four years ago.

I am a bit surprised that Mimas has grown to over 10,000 lines – mainly Python and HTML, a very small amount of JavaScript and a super tiny bit of CSS. O, and 239 unit tests which now take about 8 second to run. (Like so many other systems the front end isn’t covered by automated tests. This hasn’t been a big problem, the tests I have giv great confidence.)

I’m not completely surprised by the fact that four years later we are still using it.

The code has lots of failings – doesn’t every system? – but I’m immensely proud of it as more than I’m embarrassed by it. I’m particularly proud of the way the system held up to 300 submissions and 55 reviewers this year. This was the most use it has ever had.

As of last month the system is also OpenSource – MIT License. You can browse the code – and tell me about all my failings: Mimas on GitHub.

The system itself runs on the Google App Engine here. Anyone can log in and create their own conference. Although this being the post-review period, and me having some time, I’m taking the opportunity to make some improvements. If it is down it won’t be down for long. Unfortunately Google are forcing a database upgrade (NDB to Cloud NDB) on a move from Python 2.7 to 3.x (which I should have done a while back.)

Once upon a time I thought that other people might like to use the system for their conferences but nobody ever has. The offer is still there.

I’d love it if anyone else wants to help with development on the system – but I’m realistic to know this is unlikely. (If you want to help there are a lot of places in the UI where a little JS or CSS could improve things. In the backend I know a few places that could do with changes too.)

For the record this is what Mimas does:

• Conference organisers create a conference and accept submissions.
• Speaker details are retained for future conferences as are talk details.
• Submissions are accepted into tracks, they can have co-speakers, formats and duration are configurable.
• Two rounds of reviewing are supported, these are configurable. AOTB uses scoring for round 1 and ranking for round 2.
• Reviewers can volunteer and be assigned (random) submissions to review.
• Conference permissions allow for different users to have different capabilities.
• E-mail acknowledgements, acceptances and declines are handled via SendGrid – you can also define custom messages via templates.
• Half a dozen or more types of report plus export to Excel capability.
• OAuth login currently supporting e-mail, Google and Facebook via Firebase.
• Share reviewer feedback and comments with submitters.
• Some conference branding.
• (There is an open speakers directory and tagging mechanism, I should either improve this or scrap it.)

I’m currently building out a scheduler so the accepted submissions can be organised in the system too. Its half done.

There are bunch of ways I could develop it further: it could support paper review rather than conference review, it could support shepherding, it could be used for reoccurring events, and a whole lot more.

Finally, it is surprisingly cheap to run on the Google App Engine.

Anyway, its OpenSource, its live, let me know what you think.

🔊 Listen to Post

Anyone who has submitted to Agile on the Beach in the last few years will have used our submission system: Mimas. Like so many other conference we, or rather I, created our own system.

“Why does AOTB have its own submission system?”

Flippant but true answer: because nobody else (yet) has decided to share out system. I’m more than happy to host other conferences

Perhaps the actual question should be:

“Why create your own system when there are others out there?”

Yes, good question. Well, two (plus one) reasons really.

One: About five years ago when I got fed up of the Heath-Robinson combination of Excel sheets, Google sheets, HTML and a little Python that I was using nothing fitted. If I recall correctly Papercall was just started. While many commercial conference management systems had a synopsis module most of these didn’t do public call for papers and they cost money. I thought about using CyberChair/EasyChair but these are quite off-putting and needed hosting.

Things have changed a bit now so I might not make the same decision today.

Two: I was really very keen to give submitters feedback on their submissions and this was missing from most systems. This is an agile conference and agile is all about feedback so we should give feedback shouldn’t we?

Hillside’s Pasture can do this but is quite a niche system and I’m not sure it could handle the load we get. Similarly the Agile Alliance have a system for their conferences which gives feedback but having submitted I wasn’t impressed.

So that was then. What about today?

Having our own system has allowed us to do things we wanted: like a public review with over 50 reviewers this year. Or changing the voting system.

Of course that comes at a cost: my time to change the system, my stress in keeping the system up (a lot lately). O, there are some charges for the Google Cloud but these are trivial, a less than $1 a year and most of them are down to one report I run repeatedly during the review processes.

Those might be reasons for keeping Mimas but really my overhead should encourage me to kill it. Of course, I’ve grown to love my code and while I admit is stinks in places (the look of the UI) I’m proud of it.

But, the over whelming reason right now for not moving to Papercall (or similar) is: Speakers.

There are more speakers and potential speakers than conferences. Possibly the money to be made from a conference submission system is not from the conference organisers but from the speakers who want to submit to conferences. A bit like advertising the service could be provide for free to conference organizers if submitters paid a subscription.

And I have met speakers who tell me the go to Pepercall (or whatever) and submit to conference X. Then look down the list of other conferences they fancy and make the same submission multiple times. That is valuable to potential speakers.

But, that ease of submission is a problem for organizers. Particularly organizers who want to give feedback.

Easy submission for speakers means more work for reviewers.

As a conference organizer I don’t want every Tom, Dick and Harry submitting to my conference. AOTB already has about 300 submissions a year, and as I’ve noted before some of these smell as if the submitter really doesn’t know much about us and hasn’t thought through the submission.

The interests of speakers and organizers are not aligned.

One way of solving this problem would be for conferences to share reviews. So if a speaker submits, say, to AOTB and Agile Cambridge and Agile Alliance then each conference can see what others thought of the submission. I could imagine that working.

I can also see obstacles. First of all: data privacy.

More troublesome I wonder if that would actually make it more difficult for new speakers to break in. The same old hands, with the same good reviews, would come to dominate the conference circuit and new ideas wouldn’t get in.

So there you go. AOTB has its own submissions system and I’ll tell you more about that next time.