What Product Owners should not do

Noproductowners-2018-04-18-11-27.jpg

Last time I set out some of the things a Product Owner should be doing – or at least considering doing. Even a quick look at that list will tell you the Product Owner is going to be a busy person.

So in this post I’d like to suggest some thinigs Product Owners should NOT be doing.

Product Owners Cutting code should NOT be cutting code

Having a former coder in the Product Owner role can be a great boom. Not only do they know how to talk with the technical team and (hopefully) can command their respect but they can also see how technology can apply.

But to be an effective Product Owner they need to step away from the keyboard and stop writing code.

Two reasons.

One: time.
Product Owners add value by ensuring that the code which is written addresses the most valuable opportunities with the smallest, most elegant, delightful way possible.

Every minute spent coding is a minute not doing that.

Second: Product Owners need to empathise with the customer, with the business users, they need to eat-sleep-and-breath customers.

Being a good coder – let alone someone called an architect – is to empathise with code, the system, the mechanics of how a system works.

Importantly both requirements and code need to be able to come together and discuss what they see and find a way to bring the two – sometimes opposing – views together. It is a lot easier to have that discussion if the two sides are represented by different people.

Asking one person to divide their brain in two and discuss opposing views with themselves is unlikely to bring about the best result and is probably a recipe for confusion and stress.

Thats not to say both sides shouldn’t appreciate the other. I said before, former coders have a great advantage in being a Product Owner. And I want the technical team to meet customers. But I want discussions to be between two (or more) people.

(I might allow an exception here for Minimally Viable Teams but once the team moves beyond the MVT stage the PO should stop coding.)

Product Owners should NOT be line managers

OK, senior Product Owners should might line manage junior product owners but they certainly should not be line managing anyone else. Most certainly they should not be line managing the technical team.

Product Owner authority comes not from a line on an organization chart, or the ability to award (or deny) a pay rise or bonus. Product Owner authority stems from their specialist knowledge of what customers want from a product and what the organization considers valuable.

If the Product Owner cannot demonstrate their specialist knowledge in this way then either they should learn fast or they should consider if they are in the right role.

Product Owners need to trust the technical team and the technical team need to trust the Product Owner. Authority complicates this relationship because one side is allowed to issue orders when trust is absent and the other side has to obey.

And again, Product Owner simply don’t have the time to line manage anyone.

Being a good line manager requires empathy with employees and time to spend observing and talking to employees, helping them develop themselves, helping them with problems and so on.

Product Owners should not Make Promises for Other People to keep

Specifically that means they should not issue “Roadmaps” which list features with delivery dates based on effort estimates. The whole issue of estimation is a minefield, very few teams are in a position to estimate accurately and most humans are atrocious at time estimation anyway. So any plans based on effort estimation are a fantasy anyway. But even putting that to one side…

Issuing such plans commits other people to keep promises. That is just unfair.

Product Owners can create and share scenario plans about how the product – and world – might unfold in the future.

Product Owners can co-create and share capacity plans which should how an organization intends (strategically) to allocate resources. And Product Owners can work with teams in executing against those capacity plans in order to deliver functionality the Product Owner thinks should be delivered by a date the Product Owner thinks is necessary.

In other words: provided a Product Owner is making the promise that they intend to keep themselves (i.e. they have skin in the game) then they might issue some kind of forward plan.

Product Owners should dump outbound marketing at the first opportunity

Outbound marketing, e.g. advertising, press releases, public relations and product evangelism, often ends up on the Product Owner plate – particularly when the Product Owner is a Product Manager. And in a small company (think early stage start-up) this just needs to be accepted.

However, in a larger organization, or a growing start-up, Product Owners should seek to pass this work to a dedicated Product Marketing specialist as soon as possible. Both roles deserve enough time to do the job properly.

The Marketing Specialist and Product Owner will work closely together – they are after all two sides of the same coin, the Marketing coin. The Marketing Specialist handles outbound marketing (telling people about the product) and the Product Owner handles inbound marketing (what do people want from the product?). (Again, in organizations with established Product Management this is usually easier to see.)

Product Owners should dump pre-sales at the first opportunity

As with outbound marketing Product Owners often get dragged in as pre-sales support to account managers. And again this is more common in small companies and early stage start-ups.

There are some advantages to playing second fiddle to a sales person. The Product Owner might get actual customer contact (sales people too often block Product people from meeting customers.) And Product Owners should be exposed to some of the commercial pressures that sales people – and customers – encounter.

But doing pre-sales is very time consuming. And being wheeled in to help deliver a sales will distort the Product Owner’s view of the market – just ‘cos this customer wants the product in Orange doesn’t mean other customers want Orange.

And again, pre-sales is more effectively done by specialist staff as soon as the company can afford them.

Want to receive these posts by e-mail? – join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development

Busy busy busy: What Product Owners do

HeadacheiStock_000014496990Small-2018-04-10-10-18.jpg

If you hadn’t noticed I’m building a blog mini-series on the Product Owner role. Its a role I’ve long felt didn’t get the attention it should have. Frankly, in a Scrum setting, I think the Scrum Master gets too much attention and the Product Owner not enough.

One aspect in particular of the Product Owner role really annoys me: they have so much work to do.

Or rather, a Product Owners who is doing their job properly – as opposed to simply administering the backlog – has so many things they should potentially be doing.

So a few days ago I started to make a list…

Backlog administration: writing stories, reviewing and discussing suggested stories, splitting stories, weeding the backlog (throwing stories away), improving stories, putting value on stories, writing acceptance criteria

Working with the team: talking to the stories, reviewing work in progress, reviewing “completed” work, potentially signing-off or formally accepting stories, participating in 3-Amigos meetings with testers and developers, helping to improve the development processes

UXD: working even more closely with an UXD specialists because the two roles overlap, and possibly substituting for UXD specialists where they are absent.

Meetings: prioritisation pre-planning meeting, planning meeting themselves, stand-up meetings, retrospectives, show & tell demonstrations (potentially delivering them the show & tell themselves)

Interfacing to the wider organization: reporting and listening to internal stakeholders in authority, attending Governance and/or Portfolio review meetings, aligning product strategy and plans with company strategy and plans, plus feeding back to company strategy about their own product strategy and plans.

Planning: participating in Sprint planning with the team, planning for upcoming iterations (the rolling quarter plan as I like to call it), longer term planning which might take the form of a roadmap, a capacity plan, a scenario plan or all three

Customers 1: identifying customers and potential customer, segmenting the customer base, creating customer profiles and personas.

Customers 2: visiting customers, observing customers, talking to customers about stories and potential future work, reflecting on customer comments and feeding back to the team and other stakeholders.

Customers 3: similar activities to #2 for people and organizations who are not currently customer but who are potential customers (because potential customers who have unmet needs represent growth.)

I’m sure some of you are saying: “But we don’t have external customers, we have internal (captive) users”. And your right, if you have such “customers” then you have a subset of these activities. But then again, shouldn’t you be thinking about how our product is used by internal users to service the needs of external customers? And how you could improve that experience (for the customers) and improve the process (for the users?)

Marketing: inbound marketing the items just mentioned under customers plus market scanning (checking out the competitors) and potentially outbound marketing (advertising, PR, trade shows, etc.)

Sharing expert knowledge: providing knowledge about the domain and subject of development to the development team, supporting sales calls, demonstrating the product at shows. (And when the company is small helping the training and support teams.)

The offering: using the information gained in all these activities to refine the product/service offering to satisfy customers or improve business processes; Is it the right offering? Are you targeting the right customer segment? Should you be offering something else?

Close the loop: evaluating the effect on customers and/or process: Are the features bing used? Are non-feature improvements making a difference? What shouldn’t have been done? What arises form the changes that have been made? More software changes? Process changes?

Money: is all this making money? if the continued existence of the team positive to ROI?

Coincidentally, while I was preparing this blog Marty Cagan published a blog entitled “CEO of the Product Revisited” in which he discussed offered a list of all the discussions a Product Manager can expect to be involved with. That is no short list either. And as anyone who follows my writing already knows I see the Product Owner role as a kind-of Product Manager – more on that in a future blog.

This is not to say that all Product Owners should be doing all of these things. Asking one person to take all this on is probably setting them up to fail. Every product owner should recognise every item on this list. If they aren’t doing any of these items themselves then I expect they can either cross it off (doesn’t need doing where they work), or name the person who is doing it.

And I also expect every product owner can add some things to this list which I have overlooked.

In future blog posts I intend to discuss (again) the Product Owner as a Product Manager and how Product Owners can reduce their work load.

Want to receive these posts by e-mail? – join the newsletter today and receive a free eBook: Xanpan: Team Centric Agile Software Development

Product Owner or Backlog Administrator?

3337233_thumbnail-2018-03-20-18-08.jpg

In the official guides all Product Owners are equal. One size fits all.

In the world I live in some Product Owners are more equal than others and one size does not fit all.

The key variable here is the amount of Authority a Product Owner has. In my last post I said that Authority is one of the four things every product owner needs – the others being legitimacy, skills and time. However there is a class of Product Owner who largely lack authority and who I have taken to calling Backlog Administrators.

About the only thing a Backlog Administrator owns is their Jira login. They are at the beck and call of one or more people who tell them what should be in the backlog. Prioritisation is little more than an exercise in decibel management – he who shouts loudest gets what they want.

A Backlog Administrator rarely throws anything out of the backlog, they don’t feel they have the authority to do so. As a result their backlogs are constipated – lots of stories, many of little value. Fortunately Jira knows no limits, it is a bottomless pit – just don’t draw a CfD or Burn-Up chart!

If the team are lucky the Backlog Administrator can operate as a Tester, they can review work which is in progress or possibly “done.” They may be able to add acceptance criteria. If the team are unlucky the Backlog Administrator doesn’t know enough about the domain to do testing.

I would be the first to say that the Product Owner role can be vary a great deal: different individuals working with different teams in different domains for different types of company mean there that apart from backlog administration there is inherently a lot of variability in the role.

The Product Owner role should be capable of deciding what to build and/or change.

So Product Owners need to know what the most valuable thing to do is. Part of the job means finding out what is valuable. While Backlog Administration is part of the job the question one should ask is:

How does the Product Owner know what they need to know to do that?

Backlog Administrators are little more than gophers for more senior people.

True Product Owners take after full Product Managers and Senior Business Analysts – or a special version of Business Analysts sometimes called Business Partners.

Product Owners should be out meeting customers and observing users. They should be talking about technology options with the technical team and interface design options with UXD.

Product Owners should understand commercial pressures, how the product makes (or saves) money for the company. Product Owners are responsible for Product Strategy so they should both understand company strategy and input into company strategy. Product Strategy both supports company strategy and feeds into company strategy.

Product Owners may need to observe the competitor landscape and keep an eye on competitors and understand relevant technology trends. That probably means attending trade shows and even supporting sales people if asked.

Frequently Product Owners will require knowledge of the domain, i.e. the field in which your product is used. Sometimes – like in telecoms or surveying that may require actual hands on experience.

And apart from backlog administration there is a lot of work to do to deliver the things they want delivered: they need to work with the technical team to explain stories, to have the conversations behind the story, write acceptance criteria, attend planning meetings, perhaps help with interviewing new staff and sharing all the things they learn from meeting customers, analysing competitors, debating strategy, attending shows, etc. etc.

I sure there are many who would rush to call the Backlog Administrator an “anti-pattern” but since I don’t believe in anti-patterns I don’t. I just think Product Owners should be more than a Backlog Administrator.

Product Owners need 4 things

iStock_000008515543Small-2018-03-5-16-09.jpg

To be an effective Product Owner – and that includes product managers and business analysts who are nominating work for teams to do – you need at least four things. You may well need more than these four but these are common across all teams and domains.

  1. 1. Skills and experience

There is more to being a Product Owner than simply writing user stories and prioritising a backlog. Yes, you need to know how to work with a development team and how to work in an Agile-style process. Yes you need to be able to write user stories and acceptance criteria, perhaps BDD style cucumbers too; yes you need to be able to manage a backlog and prioritises and partake in planning meetings.

But how do you know what should be a priority?
How do you know what will deliver value? And please customers? Satisfy stakeholders?

Importantly Product Owners need to be able to do the work behind the backlog.

Product Owners need to meet people, have the conversations, do the analysis and thinking behind those things. Any idiot can pick random items form a backlog but it takes skills and experience to maximise value.

Product Owners need to be able to identify users, segment customers, interview people, understand their needs and jobs to be done. They need to know when to run experiments and when to turn to research journals and market studies. And that might mean they need data analysis skills too.

If the product is going to sell as a commercial product you will need wider product management skills. While if your product is for internal use you need more business analysis skills. And product managers will benefit from knowing about business analysts and business analysts will benefit from knowing about product management.

You may also need specialist domain knowledge – you might need to be a subject matter expert in your own right, or you might become an SME in given time.

Some understanding of business strategy, finance, marketing, process analysis and design, user experience design and more.

Don’t underestimate the skills and experience you need to be an effective Product Owner.

  1. 2. Authority

At the very least a Product Owner needs the authority to nominate the work the team are going to do for the next two weeks. They need the authority to choose items form a backlog and ask the team to do them. They need the authority not to have their decisions overridden on a regular basis. (OK, it happens occasionally.)

As a general rule the more authority the Product Owner has the more effective they are going to be in their role.

The organization may confer that authority but the team need to recognise and accept it too.

I’ve seen many Product Owners who while they have the authority to nominate work for a team don’t have the authority to throw things out of the backlog. When the only way for a story to leave the backlog is for it to be developed it is very expensive. This leads to constipated backlogs that are stuffed full of worthless rubbish and where one can’t see the wood for the trees.

If the Product Owner doesn’t have sufficient authority then either they need to borrow some or there is going to be trouble.

  1. 3. Legitimacy

Legitimacy is different from authority. Legitimacy is about being seen as the right person, the bonafide person to exercise authority and do the background work to find out what they need to find out in order to make those decisions.

Legitimacy means the Product Owner can go and meet customers if they want. And it means that they will get their expenses paid.

Legitimacy means that nobody else is trying to fill the Product Owner role or undermine them. In particular it means the team respect the Product Owner and trust them to make the right calls. Most of all they accept that once in a while – hopefully not too often – the Product Owner will have to say “I accept technologically X is the right thing but commercially it must be Y; full ahead and damn the torpedoes.”

It can be hard for a Product Owner to fill their role if the team believe a senior developer – or anyone else – should be managing the backlog and prioritising work to do.

  1. 4. Time

Finally, and probably the most difficult… Product Owners need time to do their work.

They need time to meet customers and reflect on those encounters.

They need time to work-the-backlog, value stories, weed out expired or valueless stories, think about the product vision, talk to stakeholders and more senior people, and then ponder what happens next.

Time to evaluate what has been delivered and see if it is delivering the expected value. Time to understand whether that which has been delivered is generating more or less value than expected. Time to feedback those findings into future work: to recalibrate expected values and priorities, generate more work or invalidate other work.

Product Owners need time to look at competitor products and consider alternatives – if only to steal ideas!

They need time to work with the technical team: have conversations about stories, expand on acceptance criteria, review work in progress, perhaps test completed features and socialise with the team.

They also need time to enhance their own skills and learn more about the domain.

And if they don’t have the time to do this?

Without time they will rush into planning meetings and say “I’ve been so busy, I haven’t looked at the backlog this week, just bear with me while I choose some stories…”

More often than not they will wing-it, they substitute opinion and guesswork instead of solid analysis, facts and data. They overlook competition and fail to listen to the team and other managers.

And O yes, they need time for their own lives and family.

I sometimes think that only Super Human’s need apply for a Product Owner role, or perhaps many Product Owners are set up to fail from day-1. Yet the role is so important.

I plan to explore this topic some more in the next few posts.

Books update: User Stories, Continuous Digital and Project Myopia

UserStoriesPrint-2017-10-27-17-34-1.jpg

Someone told me the other day “I can’t keep up with your books” – and you know what? I’m not surprised, it has been a busy couple of months for me on the books front but actually, there has been very little new writing – except with this blog.

First off, “Little Book of Requirements and User Stories” is now available in print.

This is a collection of pieces I wrote for Agile Connection a couple of years back which I compiled into an e-book. Sales of the e-book have been good, especially since I put it on Amazon and so, after a couple of request I’ve created a print version.

Right at the moment I’m amazed that Little Book is ranking as the 46th best seller in systems analysis and design which I think makes it a best seller!

The cheapest way to get the book is to buy thee-book on LeanPub. Amazon (all sites) have both print and ebook versions but they are more expensive. If you would like a copy for free please write me a review on Amazon UK and I’ll post you a copy – first six reviews only!

Next… Continuous Digital and Project Myopia….

ContDigital-2017-10-27-17-34-1.jpg ProjectMyopia-2017-10-27-17-34-1.jpg

Continuous Digital began life as #NoProjects, then Project Myopia, then became Continuous Digital. The name changes reflected the way my own thinking grew and changed. What began as a critique of the project model grew into an alternative model in its own right. In doing so it became something different, hence Continuous Digital.

But the more Continuous Digital stood alone the more the original chapters looked out of place. So I decided a few weeks ago to bundle them into their own book: Project Myopia.

I hope readers will find them complementary although I think they both stand alone. Both are only available as e-books on LeanPub, indeed there is an LeanPub bundle “Rethinking Projects” containing both. That said, right now Continuous Digital contains a coupon which allows readers to download Project Myopia for free. (It won’t be there for much longer.)

Splitting Continuous Digital in two has allowed me to race through my editing. There is still some work to do but content wise the book is pretty much done. It will remain a LeanPub only e-book for a little while longer and then…

Project Myopia would benefit from some more editing but I have no great plans to change it much. The changes I would make are all covered in Continuous Digital anyway.

Please, if you have any comments on any of these books, or suggestions to make them better let me know.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Books update: User Stories, Continuous Digital and Project Myopia

UserStoriesPrint-2017-10-27-17-34.jpg

Someone told me the other day “I can’t keep up with your books” – and you know what? I’m not surprised, it has been a busy couple of months for me on the books front but actually, there has been very little new writing – except with this blog.

First off, “Little Book of Requirements and User Stories” is now available in print.

This is a collection of pieces I wrote for Agile Connection a couple of years back which I compiled into an e-book. Sales of the e-book have been good, especially since I put it on Amazon and so, after a couple of request I’ve created a print version.

Right at the moment I’m amazed that Little Book is ranking as the 46th best seller in systems analysis and design which I think makes it a best seller!

The cheapest way to get the book is to buy thee-book on LeanPub. Amazon (all sites) have both print and ebook versions but they are more expensive. If you would like a copy for free please write me a review on Amazon UK and I’ll post you a copy – first six reviews only!

Next… Continuous Digital and Project Myopia….

ContDigital-2017-10-27-17-34.jpg ProjectMyopia-2017-10-27-17-34.jpg

Continuous Digital began life as #NoProjects, then Project Myopia, then became Continuous Digital. The name changes reflected the way my own thinking grew and changed. What began as a critique of the project model grew into an alternative model in its own right. In doing so it became something different, hence Continuous Digital.

But the more Continuous Digital stood alone the more the original chapters looked out of place. So I decided a few weeks ago to bundle them into their own book: Project Myopia.

I hope readers will find them complementary although I think they both stand alone. Both are only available as e-books on LeanPub, indeed there is an LeanPub bundle “Rethinking Projects” containing both. That said, right now Continuous Digital contains a coupon which allows readers to download Project Myopia for free. (It won’t be there for much longer.)

Splitting Continuous Digital in two has allowed me to race through my editing. There is still some work to do but content wise the book is pretty much done. It will remain a LeanPub only e-book for a little while longer and then…

Project Myopia would benefit from some more editing but I have no great plans to change it much. The changes I would make are all covered in Continuous Digital anyway.

Please, if you have any comments on any of these books, or suggestions to make them better let me know.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The Solution defines the Problem

Excel-2017-10-24-14-07.jpg

How many times have you encountered a user/customer/client who describes the thing they want in terms of Microsoft Excel? – “What I want is a macro in Excel to pick up all these data points and then…”

Many a Business Analyst has started from this point and worked back to discover what the clients real “problem” is. Quite possibly the client never considered themselves as having “a problem”. Quite possibly the “problem” would never have been spoken about it the client didn’t have an understanding of spreadsheet technology. And in the days before spreadsheets were invented the task may have been tiring, time consuming and prone to error but, thats just how it was.

Regardless of whether Excel is the solution they finally get, or not, it is only because they can imagine a solution that a problem can be defined. In fact, the Solution defines the Problem.

Excel is not the only example…

TubeEstimatedBill-2017-10-24-14-07.jpg

I was travelling on the London Underground the other day when this advert leapt out at me: “Estimated bills got you in a spin? Get accurate ones with a smart meter”. What?

Really, I mean: What?

I’ve been paying electricity, gas and other metered bills for over 20 years, not only have I never “got in a spin” about an estimated bill but I’ve never given it two thoughts. Neither can I ever recall anyone saying to me “Gee I hate estimated bills… they are so much hassle…”. OK, maybe some people have but so few that it hardly ranks as a world class problem.

Actually, now I think about it: I prefer estimated bills. It is hassle having a meter reader come to the door and having to show them the meters. And it is even more hassle reading my own meter, finding the box key, writing the reading down, trying to log into a website, doing “forgot my password” …

This advert, this whole product, is a great example of Solution Defines the Problem. Estimated bills are not a problem until you to have a solution.

Yes I know Solution defines Problem is hearsay to some. We are supposed to find the problem and work backwards from the problem to the solution, outside-in.

Yes I know that all you Business Analysts and Product Managers were trained – as I was myself – to look for the problem and then define a solution: a solution that might just happen to be technology based, and might just happen to be software.

And Yes I know to many of you the idea of a company creating “a problem” so they can then solve it is morally repugnant but… lets think about it for a minute.

What problem does the iPhone 8 solve? What was at the front of Apple’s hive-mind when they designed the iPhone 8?

440px-IPhone_8_vector-2017-10-24-14-07.png

And what problem does the iPhone 8 solve that the iPhone 7 didn’t solve? Or for that matter the iPhone 6? 5? 4?

(I mean “what customer problem”, one could argue the problem the iPhone 8 solves is Tim Cook’s need to have more sales revenue.)

Solving problems is not enough.

I’m not saying outside-in, problem first, innovation and development doesn’t work. Clearly such an approach has work in many cases. What I am saying is: it is not always appropriate; sometimes a more effective way of working is inside-out.

What can the technology do?
How can we make people’s lives better with this?

This approach too has a number of success stories. Rather than condemn it as “wrong” maybe we should be asking “When and where does it work?” and “Which approach is the most appropriate?”

When creating a new thing – be it software, hardware or services – our understanding of the problem evolves as our understanding of the possible solution, or solutions, evolve. One starts off thinking of a solution, or a problem, we seek to understand some more – maybe by building part of a solution or by talking to someone we think have the problem, we learn a little, maybe we continue in this mode or maybe we flip and work on the other side of the equation. And round we go again, iteration.

It is a learning cycle, the question is, what is the fastest way to learn?

I included the solution-problem hypothesis in my Agile Cambridge keynote last month. Afterwards I was e-mailed by someone whose email I’ve now lost (apologies!) and recommended a book: Overcrowded by Roberto Verganti.

Roberto Verganti, takes a similar but different approach to the same question. For him the key is: meaning. At first I wasn’t quite sure if “meaning” was the right word but as I’ve read more I think it is, albeit meaning in a fairly broad sense.

Verganti’s argument isn’t quite the same as mine but it is close enough, he is also arguing for starting with a solution and working backwards. For him the aim is to create new meaning, you might say that he identifies a generic problem “Humans needs more meaning in their world.”

Try the iPhone test in this context too: “What is the meaning of the iPhone 8?”

I’m going to be talking more about this in my keynote to TopConf in Tallin next month, in the meantime please let me know what you think. Madness?

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

MVP is a marketing exercise not a technology exercise

MVP-2017-10-2-11-03.jpg
… Minimally Viable Product

Possibly the most fashionable and misused term the digital industry right now. The term seems to be used by one-side-or-other to criticise the other.

I recently heard another Agile Coach say: “If you just add a few more features you’ll have an MVP” – I wanted to scream “Wrong, wrong, wrong!” But I bit my tongue (who says I’m can’t do diplomacy?)

MVP often seems to be the modern way of saying “The system must do”, MVP has become the M in Moscow rules.

Part of the problem is that the term means different things to different people. Originally coined to describe an experiment (“what is the smallest thing we could build to learn something about the market?”) it is almost always used to describe a small product that could satisfy the customers needs. But when push comes to shove that small usually isn’t very small. When MVP is used to mean “cut everything to the bone” the person saying it still seems to leave a lot of fat on the bone.

I think non-technical people hear the term MVP and think “A product which doesn’t do all that gold plating software engineering fat that slows the team down.” Such people show how little they actually understand about the digital world.

MVPs should not about technology. An MVP is not about building things.

An MVP is a marketing exercise: can we build something customers want?

Can we build something people will pay money for?

Before you use the language MVP you should assume:

  1. The technology can do it
  2. Your team can build it

The question is: is this thing worth building?and before we waste money building something nobody will use, let alone pay for, what can we build to make sure we are right?

The next time people start sketching an MVP divide it in 10. Assume the value is 10% of the stated value. Assume you have 10% of the resources and 10% of the time to build it. Now rethink what you are asking for. What can you build with a tenth?

Anyway, the cat is out of the bag, as much as I wish I could erase the abbreviation and name from collective memory I can’t. But maybe I can change the debate by differentiating between several types of MVP, that is, several different ways the term MVP is used:

  • MVP-M: a marketing product, designed to test what customers want, and what they will pay for.
  • MVP-T: a technical product designed to see if something can be build technologically – historically the terms proof-of-concept and prototype have been used here
  • MVP-L: a list of MUST HAVE features that a product MUST HAVE
  • MVP-H: a hippo MVP, a special MVP-L, that is highest paid person’s opinion of the feature list, unfortunately you might find several different people believe they have the right to set the feature list
  • MVP-X: where X is a number (1,2, 3…), this derivative is used by teams who are releasing enhancements to their product and growing it. (In the pre-digital age we called this a version number.) Exactly what is minimal about it I’m not sure but if it helps then why not?

MVP-M is the original meaning while MVP-L and MVP-H are the most common types.

So next time someone says “MVP” just check, what do they mean?

Read more? Join my mailing list – free updates on blog post, insights, events and offers.

Definition of Ready considered harmful

Small-iStock-502805668-2017-09-6-12-58.jpg

Earlier this week I was with a team and discussion turned to “the definition of ready.” This little idea has been growing more and more common in the last couple of years and while I like the concept I don’t recommend it. Indeed I think it could well reduce Agility.

To cut to the chase: “Definition of ready” reduces agility because it breaks up process flow, assumes greater role specific responsibilities, introduces more wait states (delay) and potentially undermines business-value based prioritisation.

The original idea builds on “definition of done”. Both definitions are a semi-formal checklists agreed by the team which are applied to pieces of work (stories, tasks, whatever). Before any piece of work is considered “done” it should satisfy the definition of done. So the team member who has done a piece of work should be able to mentally tick each item on the checklist. Typically a definition of done might contain:

 

  • Story implemented
  • Story satisfies acceptance criteria
  • Story has been seen and approved by the product owner
  • Code is passing all unit and acceptance tests

Note I say “mentally” and I call these lists “semi formal” because if you start having a physical checklist for each item, physically ticking the boxes, perhaps actually signing them, and presumably filing the lists or having someone audit them then the process is going to get very expensive quickly.

So far so good? – Now why don’t I like definition of ready?

On the one hand definition of ready is a good idea: before work begins on any story some pre-work has been done on the story to ensure it is “ready for development” – yes, typically this is about getting stories ready for coding. Such a check-list might say:

 

  • Story is written in User Story format with a named role
  • Acceptance criteria have been agreed with product owner
  • Developer, Tester and Product owner have agreed story meaning

Now on the other hand… even doing these means some work has been done. Once upon a time the story was not ready, someone, or some people have worked on the story to make it ready. When did this happen? Getting this story ready has already detracted from doing other work – work which was a higher priority because it was scheduled earlier.

Again, when did this happen?

If the story became “ready” yesterday then no big deal. The chances are that little has changed.

But if it became ready last week are you sure?

And what if it became ready last month? Or six months ago?

The longer it has been ready the greater the chance that something has changed. If we don’t check and re-validate the “ready” state then there is a risk something will have changed and be done wrong. If we do validate then we may well be repeating work which has already been done.

In general, the later the story becomes “ready” the better. Not only does it reduce the chance that something will change between becoming “ready” and work starting but it also minimises the chance that the story won’t be scheduled at all and all the pre-work was wasted.

More problematic still: what happens when the business priority is for a story that is not ready?

Customer: Well Dev team story X is the highest priority for the next sprint
Scrum Master: Sorry customer, Story X does not meet the definition of ready. Please choose another story.
Customer: But all the other stories are worth less than X so I’d really like X done!

The team could continue to refuse X – and sound like an old style trade unionist in the process – or they could accept X , make it ready and do it.

Herein lies my rule of thumb:

 

If a story is prioritised and scheduled for work but is not considered “ready” then the first task is to make it ready.

Indeed this can be generalised:

 

Once a story is prioritised and work starts then whatever needs doing gets done.

This simplifies the work of those making the priority calls. They now just look at the priority (i.e. business value) or work items. They don’t need to consider whether something is ready or not.

It also eliminates the problem of: when.

Teams which practise “definition of ready” usually expect their product owner to make stories ready before the iteration planning meeting, and that creates the problems above. Moving “make ready” inside the iteration, perhaps as a “3 Amigos” sessions after the planning meeting, eliminates this problem.

And before anyone complains saying “How can I estimate something thing that is not prepared?” let me point out you can. You are just estimating something different:

 

  • When you estimate “ready” stories you are estimating the time it takes to move a well formed story from analysis-complete to coding-complete
  • When up estimate an “unready” story you are estimating the time it takes to move a poorly formed story from its current state to coding-complete

I would expect the estimates to be bigger – because there is more work – and I would expect the estimates to be subject to more variability – because the initial state of the story is more variable. But is still quite doable, it is an estimate, not a promise.

I can see why teams adopt definition of ready and I might even recommend it myself but I’d hope it was an temporary measure on the way to something better.

In teams with broken, role based process flows then a definition of done for each stage can make sense. The definition of done at the end of one activity is the definition of ready for the next. For teams adopting Kanban style processes I would recommend this approach as part of process/board set-up. But I also hope that over time the board columns can be collapsed down and definitions dropped.

Read more? Join my mailing list – free updates on blog post, insights, events and offers.