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.
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!
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.
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…
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?
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?
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?
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:
The technology can do it
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?
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 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.