This article was originally published by InformIT and can be viewed on their site. It is reproduced here with kind permission.
Part 1 of this series examined the explosion of mobile and embedded devices that characterize our future, explored the challenges posed by these changes, and considered a methodology for reliable innovation in this environment and the technology enablers required to support that approach. In part 2, we look at what types of strategies are likely to be effective in this new world.
Once you have a reliable methodology in place for fostering innovation and engaging the market, supported by the technology enablers mentioned in part 1, you are finally ready to start growing and developing visionary strategies to help you capitalize on the emerging world of ambient computing.
The big question becomes, “What should our vision and strategy be?” Unfortunately, there’s no stock answer I can prescribe (though I’ll be happy to help you figure it out), but I do have some pointers toward directions you should be considering.
The growing ubiquity of computing and omnipresent interfaces points to opportunities such as “any customer, anywhere,” and the explosion of profiling data opens up services based on the idea that “we know what you’re about to think.” The key is not what your exact vision is, but how you validate it and course-correct based on that feedback. This in itself is the strategy of rapid product evolution for which part 1 of this article attempted to lay out the foundations.
I always struggled to see how what Lean teaches us about pull systems can be applied to software development processes. That was until I had an “Aha!” moment a little while ago helping a client apply lean and agile principles to their delivery process.
The big fat lie
I understand how queuing theory can help identify and reduce bottlenecks in processes and have used finger-charts and kanban-boards to do this for a while, but I still find calling this a “pull system” to be slightly disingenuous. All that’s happening is that more “stuff” is being pushed based on a trigger when certain buckets get too low. This reminds me of my annoyance with early technologies on the web that were touted as being “push” but were really just “repetitive-pull” (but not in a good way). I’ve never seen a software organization where the developers have said to the business or product people “we’ve got nothing to do, can you think up some new projects or features for us please?”.
San Francisco is a wonderful place – I ended up having an interesting discussion last night with a self-styled “geek-at-large” about robots, ethics and unix while hanging out at a not-for-profit who are improving the world one wi-fi network at a time.
The robot maker’s argument was that robots don’t have to be super intelligent to carry out some pretty useful, robotic, tasks. He was suggesting that there’s a blind-alley in robotic research premised on being able to map and track everything in your environment in order to move and interact effectively. His argument was that instead you just needed to be able to identify a goal to move towards and be able to avoid collisions. That is a much simpler goal than understanding your whole environment.