It's worth mentioning that I’m talking about the integration of design into our delivery process which is usually Scrum for a larger project. In earlier stages the design and development process are fluid and experimental with lots of customer input in creating prototypes (which are also time travel to possible futures, just further away).

We make a fairly strong delineation between development – when learning is pretty much the sole goal – and when we are building a scalable, robust, maintainable platform for future learning. The latter is often bigger teams working for a longer time (a maximum of 3 months) before an initial release.

Six years ago we first started experimenting to integrate a design process into Agile development. We were convinced by Agile as the only way to approach software development and wanted to extend its benefits back into design and strategy. But at that point there were only a few people talking UX/design in Agile environments, and even less best practice. So we experimented heavily.

Agile means no (big) design up front so we tried starting design on a project at the same time as development, but rapidly got left behind by the Agile story delivery engine. We tried completing design one page at a time to FULL fidelity and then having it built in the next sprint (nightmare from hell). We tried more design earlier and started to look like waterfall with iterations.

We found good working models, things like a design foundation phase (just enough early design before development starts), design chunking and parallel track development to make it work. These always involved some type of working a set number of Sprints in front of development. But in the end this just produces lots of cascading waterfalls. It's better, but not fluid and not necessarily collaborative.

I remarked to Tom Harding a while ago that I didn’t see us worrying too much about the integration of design and software delivery. We agreed this was probably because the collaboration of designer and developers in the teams had reached such a high level that “thoughtfulness” was no longer necessary, it was natural.

But when we work with external development parties, these old problems re-emerge. I believe when you don’t have history and you don't have extreme collaboration, that is when you need process; some formulas for success.

Design is a holistic endeavour and it means you need to know how your whole product fits together, especially for the first delivery (your future platform for experimentation). Not in detail, but in concept, meaning and experience. Too often, Agile will churn forwards, continually delivering but with no idea of what makes a holistic MVP. This is because, as Bill Scott says, Agile has no Brain (sketch note in the link by Krystal Higgins). Too often, absolutely zero expectations are set for a release and not enough planning is done. I suggest reading Agile Estimation and Planning again. Which brings us to:

There is no need for a Sprint 0 of a fixed length equal to the lengths of your other sprints. Just cater for enough time before fixed Sprints to do prototyping and experimentation, to create a holistic product design that allows you to have a good backlog and estimated release plan. Its not Big Design Up Front if you don’t make it Big. Know the areas where you can’t estimate because either you have a) technical ignorance, and therefore need development spikes in your Sprints or you have b) product ignorance, and therefore you need design spikes in your Sprints. Which brings us to:

The job of the time travelling designer is to travel into the future of the product (or one of many possible futures) and then to come back to tell the team in the present what it looks like there. This means instead of working just a fixed number of Sprints ahead it becomes whatever is most useful to the team, either stuff for right now this moment, or the next sprint or even the next release. Determining what is most useful is a team decision based on what is needed to create the product. Time travel experiments are also a great thing to test with customers.

While it was originally just designers, I think that all members of the team are capable of time travelling. But the rules still apply…

1. You must know (and tell the team) how far in the future you have been.
2. There can be different possible versions of the future.
3. The further into the future you go the fuzzier your vision is (something to do with degradation of Tachyon particles). Therefore things in the near future should be crisp and in high-definition, things in the far future are abstract and in low-definition.
4. If visions of the far future are in crisp high-definition then it was probably a dream, NOT time-travel.
5. The further into the future you go the less time you can spend there.
6. You cannot go back in time but you can go back to the future.

So these concepts are useful to anyone working in a Scrum fashion but I think that Scrum is becoming a barrier to good product development rather than an aid. The reliance on rituals and rigour make it look like it is a “fool-proof” process to success but all the optimisation goes in the wrong place, in the delivery.

The real challenge is making the right product and that remains more art than science, and it's a collaborative art. I still want to continue using Scrum because the rhythmic nature of it helps a wider stakeholder group make sense of what is happening on a project. When you say "We are on Sprint 6 of the 8 Sprints that are in release 1", everyone gets a good read on where you are. Although of course all of those 6 sprints could have been wasted on stories that no one wanted. And that is where the real effort needs to go.