Continuous Digital & Project Myopia

Reprojects-2017-09-11-10-56.png

This seems a little back to the future… those of you who have been following the evolution of Continuous Digital will know the book grew out of the #NoProjects meme and my extended essay.

I think originally the book title was #NoProjects then was Correcting Project Myopia, then perhaps something else and finally settled down to Continuous Digital. The changing title reflected my own thinking, thinking that continued to evolve.

As that thinking has evolved the original #NoProjects material has felt more and more out of place in Continuous Digital. So I’ve split it out – Project Myopia is back as a stand alone eBook and you can buy it today.

More revisions of Continuous Digital will appear as I refactor the book. Once this settles down I’ll edit through Project Myopia. A little material may move between the two books but hopefully not much.

Now the critics of #NoProjects will love this because they complain that #NoProjects tells you what not to do, not what to do. In a way I agree with them but at the same time the first step to solving a problem is often to admit you have a problem. Project Myopia is a discussion of the problem, it is a critique. Continuous Digital is the solution and more than that.

Splitting the book in two actually helps demonstrate my whole thesis.

For a start it is difficult to know when a work in progress, iterating, self-published, early release book is done. My first books – Business Patterns and Changing Software Development – were with a traditional publisher. They were projects with a start and a finish. Continuous Digital isn’t like that, it grows, it evolves. That is possible because Continuous Digital is itself digital, Business Patterns and Changing Software Development had to stop because they were printed.

Second Continuous Digital is already a big book – much bigger than most LeanPub books – and since I advocate “lots of small” over “few big” it makes sense to have two smaller books rather than one large.

Third, and most significantly, this evolution is a perfect example of one of my key arguments: some types of “problem” are only understood in terms of the solution. Defining the solution is necessary to define the problem.

The solution and problem co-evolve.

In the beginning the thesis was very much based around the problems of the project model, and I still believe the project model has serious problems. In describing a solution – Continuous Digital – a different problem became clear: in a digital age businesses need to evolve with the technology.

Projects have end dates, hopefully your business, your job, doesn’t.

If you like you can buy both books together at a reduced price right now.

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.