No other way to describe it really. World seems to be getting more sci-fi every day.
Via Automaton
Ideally, verification failures, that is not building things right, should not occur between process steps. Given that software development is a product design process, validation failures, that is not building the right thing, is a bit different. Phenomena like "I'll Know It When I See It" means that sometimes the fastest way to discover what is the right thing to build is to simply try something and get feedback. Just try it and see.
Figuring out how much should be done up front to determine what to build should vary based on domain and the cost of discovery later. The Agile perspective is that the goal is to focus on reducing the cost of discovery later to reduce how much needs to be done up front. This is a fast responder mindset. For example, if like Zara, you can replace an entire line of production based on direct customer feedback in 15 days, how much time to you really want to spend to ensure that the dress you designed is the perfectly right one?
This is not to say that we should not do things to improve the likelihood that we've designed the right thing. It's just that we only choose those things that are fast enough to be more economical than just trying it and seeing.
We have to be careful about what is meant by "seeing". There is an understanding in the user experience community, similar to cultural anthropology, that you can't rely on what people tell you on what is actually happening. This is why contextual inquiry and iterative user testing is interesting in our space. One thing I'm wary of is that these activities must involve people to cover off all aspects of a design. It seems such a waste to develop context and then start throwing it away by having to translate it to another group of people.
In Lean manufacturing, in order to ensure that overproduction does not occur, you limit how much the process will take in. For example, drawing a line around an area where work in process is placed so that only a certain number of things will physically fit.
Since we don't have physical parts to move around, we use a physical token (i.e.an index card on a story wall) to represent work-in-process and we can limit work-in-process by restricting how many visible slots are available at each process step.
There is also the concept of minimum and maximum inventory. We may need to ensure there is a minimum amount of things available between process steps to manage variation in the production rate of each step.
This I think is really the point of an "iteration-free" approach. The time-box is just for data sampling. Rhythm is established by constraining work to the pacemaker of the process, which we typically assume to be the development team but that's worth measuring.
Just looking at how much work can fit within a timebox does not deal with constraining work to prevent overburdening and overproduction. It also doesn't emphasise that perfection is a batch size of one, that is one story (or similar self-contained unit of work) flowing through every stage of the process without any delays.
Via the IEEE Automaton blog,
"Gosh, I wish I had my very own Predator drone. The things I could keep under surveillance! The neighbors I could buzz! Yes, my life is empty without it."A web site on do it yourself flying drones.
Via Presentation Zen,
I'm not American but this is quite the inspiring presentation on Barrack Obama:
A reproduction of a picture I drew trying to explain the context of our continuous integration and testing strategy.
