1. Google Android and Google Chrome OS are going to be a big deal. Sell your Wind River stock (VxWorks), embedded will be owned by Google.  A big question for developers, should you target Android or Chrome for 2010 projects?  Two great things, not yet the same. Dust off those old Java books because we’re going back.

2. HTML 5 will make a dent, but only a dent. Flash will continue to own the rich internet, Silverlight will only get table scraps and most people will eagerly look towards HTML 5 as they continue working in Flash. Not that HTML 5 won’t eventually take over, it’s just going to be a while. Silverlight was stillborn, and it’s likely to stay that way (yes, we’re a Microsoft shop saying that).

3. Agile Software Development will continue to both grow and splinter. More projects will adopt things they call Agile; but less of what people call Agile will be of any value.  Agile (the community) is too focused on Scrum/xP at a time when the excitement is across the street.  The Agile community is too busy reading each other’s blogs and not paying attention to the world around.  Agile will continue its march towards irrelevance by focusing on all the wrong things. Pigs, chickens, Kanban, whatever…

4. Cross-vertical integration (and cross branding) will be in everything. You shouldn’t design any software without leaving a little space for cross-vertical integration. Don’t ask me why integrating a Colgate toothpaste feature into the UI of a payroll system makes sense, but that’s the direction we are heading. Okay, maybe not towards pitching products from inside the enterprise firewall just yet…but anything consumer facing needs to have hooks for cross branding; and everything needs hooks for cross-vertical integration.  Your Blu-ray player already runs Netflix, a sign of the type of things to come.  Netflix, YouTube, Facebook, Sony, you name it. Expect to see lots of logos on every splash screen in the coming year(s).

5. 64-bit. This a no-duh but we need to say it. The desktop will be 64-bit in 2010. True, Linux has been 64-bit for a while, all three installs.  Expect EVERY Windows7 installation to be 64-bit. The driver issues that discouraged this with Vista and XP are mostly gone, so the average Dell order is going to be a 64-bit OS. Developers, you need to be ready for this if you have 32-bit products fielded today.

6. Parallel computing.  No prediction would be complete without ubiquitous parallel computing, again. One of these days this will hapen.  Lots of reasons to be encouraged this year, especially mainlining the GPU.

7. Standard UI controls will finally be dead.  User experience is king and every popular application will have its own unique controls…buttons…scroll bars…and original gizmos.  Some argue that custom controls and unique user experiences will increase confusion to the user.  After all, wasn’t the homogeneity of the user experience delivered by Macintosh and Windows 3.1 considered a big advance?  However, the market speaks loudly.  Inventions like iPhone that completely redefine Ux idioms, well…they sell just fine. In the old days a custom control meant lots of work, but now it’s painless.  Going forward your customers expect a smartly designed experience, if you don’t furnish one then your competitor will.

8. India and China won’t win. For those who predict India and China are going to take over the software business, I’ve got news for you.  Software outsourced to those places is largely below average in every way. While they write good enough code (and only good enough), the offshore ability to use ethnography, capture innovative designs, create attractive features for users, and all the rest is lacking.  Most offshore software pros are trained as engineers or computer scientists; not as artists, designers, ethnographers, or marketers. There's a reason your favorite products say "designed in California - made in China".  Moreover, the coding piece is becoming a smaller part of product development. Already the new tech stacks have reduced same-feature development by over 50% compared to 4 years ago.  With these advances in productivity, who needs off-shore labor?  You can run a small team of people on-shore and get much better results for a negligible end-to-end cost differential.  If you really need 100 people developing in India, rethink your situation. If you want good stuff (not just stuff), then on-shore will remain the best way to get it.

9. Pre-visualization storyboarding and prototyping is coming of age for software design.  Pre-production visualization has long been an essential ingredient for film and theater production.  Prototyping has long been an essential ingredient of industrial design.  In the software industry we’ve known that pre-visualization and pre-production prototyping would make a valuable contribution to the product design and innovation process…it’s just nobody knew how to do it and there were no good tools. Now, we have some tools…but more importantly we have a vector.  As coding and systems engineering becomes less central to the development process, and innovation/product-design take center stage; we can expect pre-vis and prototyping to gain importance.

10. Augmented reality and organic experiences are the new black. A few years ago it was touch, but now touch is mainstreamed and our appetites are for something new. Don't expect Win7 multi-touch to make any difference to the world.  However, lots brilliant products have already shipped with augmented reality, and this is just the beginning. The modern user experience is a sheath overlaying the real organic world, not the chunkiness of a pure digital world. Analog is totally in.

11. Apple and Google will go nuclear. Apple can't get Google tech out of its products fast enough, and the conflict will escalate in 2010.  Google needs Apple not, but Apple totally depends on Google for a lot of its "coolness".  Mapping and search are only the tip of an iceberg.  As Google transforms from "math club" technology to platform vendor (Android, Chrome OS, etc..), Apple has the most at risk in terms of marketshare and demography. Google will try to "out hip" Apple in brand image, and even if Google can't 100% pull it off, Apple will be forced to go nuclear. It'll be ugly.  Both are great companies, but they are starting to be in each other's personal space.

• There’s an app for that
  iPhone apps blew a hole in the sky, completely democratizing the concept of application innovation. Those little apps have done more for raw software innovation than anything in the past 20 years.  

• Netbook sizzle to fizzle
  Enthusiasm for toogoodtobetrue Netbooks came and went as rapidly as BBQ Ribs at a NASCAR tailgate party.  Every one of those $199 pieces of ___ are lining the garbage bin as $299 real laptops hit the market. Netwhat?

• Cross-marketing - the new innovation
  The art of the deal.  Who would have thought embedding a Netflix engine was the best way to sell Blu-Ray disc players?  Clearly not Sony.  Netflix, Twitter, Facebook, YouTube, you name it, and it got integrated into an otherwise conventional furniture-top gizmo in 2009.

• Gadgets for the people
  Prices fell faster than Tiger Woods at Vegas showgirl convention. Top-shelf gizmos selling for next to nothing. Every kind of technology from beautiful flat-screen TVs, laptops, Blu-Ray players, and anything else you can name not made by Apple is basiclly free. The most sophisticated technology on the planet will come home with you for few hundred bucks. DLP projectors for < $200.  Makes you wonder what’s left for next year’s top shelf? Margins, who needs margins?

• No stinking storage problem
  From 64GB flash chips to 2+ TB hard disks to DRAM, storage density is mind blowing.  As product designers our options are greatly expanded due to cheap and almost limitless storage. Storage density is changing the world.

• Design ubiquity
  Design has been oozing its way into all things software, finally! Certainly the majority is still stylistic design, but that's a first step towards deeper product design that balances technology, art, and the human (anthropology). It's an exciting time to be in the software Design business.
   
• Cloud in the sky
  When the entire industry is bent on distorting reality, people will eventualy think the distortion is the truth.  When big firms bet the farm on cloud computing then clouds will be hot, regardless of whether anyone needs, wants, or buys them. Cloud computing = outsourcing. Duh!

• Blogs out, Tweets in, whatever
  In 2009 it became “uncool” to be a blogger and cool to Tweet. Fickle bunch aren’t they?

• Kindle the fire
  OMG! An e-reader that people actually buy!  These things are frigg’n everywhere.  Who saw that coming? So many companies offer e-readers, where will it end? Nook over there, it's another one.

• Android OS and green lasers
  Some also-rans.  So many little innovations that were really hard for people to make but don’t have a large-scale culture-defining impact. At least not yet.  Soon though!  Expect droid to be a 2010 phenomena.

As a product developer you realize that quality has recently been slipping. Customer's are no longer as thrilled with your products, which are now buggy, slow to market, and missing the magic of wow!  A self examination reveals un-structured product development processes that you aren't very proud of.  A loose structure worked well when your organization was younger and smaller, but now you have several products in various phases of development or maintenance and the lack of structure is causing problems.

Everyone concludes it's time to crank up the structure, hire a process pro, bring some consultants in, and execute a top down re-org to insert layers of management above all the moving parts. What used to be a small highly integrated team of multi-disciplined professionals working together evolves into departments of specialized skill-sets matrixed across multiple projects.  You inject the rigor of ISO 9000 derived quality control into the development pipeline by erecting phase gates, compulsory reviews, and formal verification and validation.  Acronyms ending with the word "Board" become the dread of every productive human in the organization.

You get encouragement from upper management because these steps are convincing proof that action is being taken to correct what everyone sees as a chronic problem with quality. 

Screech!

Fast forward a couple of years and you have a constipated organization that can no longer deliver innovation to customers. Everything has a bottleneck and there is a bottleneck for everything.  Product launches are few and far between, and when they do happen there's little or no enthusiasm in the marketplace because the technology is behind the times, depleting to users, and generally bland.  Adding insult to injury, despite all the phase gate checkpoints, compulsory reviews, and formal verification and validation - quality is as bad or worse. Essentially, you increased development costs and schedules and all you got in return was a poke in the eye.

What went wrong?

You needed structure but reached for the wrong kind, you reached for the kind of structure that makes things worse rather than better. High structure comes in various flavorings, some are really good and others are poisonous.  Fixing a broken product development organization involves more than just reaching for structure, it involves selecting the correct structure.

As John Hajdukiewicz from MIT/Honeywell points out, "Innovation and structured processes are at odds with each other and need to be managed with different approaches. Innovation processes require creative isolation from high structure to open degrees of freedom and the design space".

To wrap this up, as we've pointed out many times here before - product development consists of two main parts: You need a vibrant front end for innovation and creative design but you also need a highly structured back end for development. Agile tends to combine the front end and back end, which injects mediocrity into product design.  Waterfall and structured systems engineering processes impose a common work-breakdown flowchart around everything - resulting in numerous problems, one of which is really bad product design.

A good front end has a very special and in many ways "loose" structure. Creative talent (Product Designers) need to be isolated from the high structure used to crank out a red-shifted high quality delivery.

At the back end you want high structure, a machine that runs efficiently and swiftly under intense pressure.  You want the back end to wrap things up quickly, no more than 10 months for most products. Don't try to incorporate a lot of product-level innovation in the back-end, just focus on writing great code.  Also, don't try to iterate major elements of product design at the back end...development will be hosed.  If the back-end doesn't feel a little like a pressure cooker then there's a problem.  If your back-end staff doesn't completely grok the product design then you're also hosed.  This is why so much offshore outsourcing produces garbage.

Great software development floors are run at a constant but intense pace, where best practices are a religion and peer pressure is a force that drives things to be done right.  XP/Scrum practices work well at the back end, but you need a talented "floor boss" to drive quality and productivity.  Organizations that think the only way to control quality is with a heavy verification & validation process generally don't have these disciplines; that said, even great organizations benefit from having independent verification and validation disciplines. 

At the front end, the best innovation is driven from Design not requirements, so your process structure should be centered around Product Design not systems analysis.  Requirements capture and analysis disciplines are necessary but completely insufficient for great product innovation. Design is one-third art, one-third technology, and one-third modern anthropology.  Keep the creative pieces isolated from the pressure cooker of the back end, but make sure you have a "structure for creativity" and assess your design talent at every step.  The most talented designers should be recognized and used on the most visible projects. Less talented designers should get the scraps or be moved away from the creative front end.

It seems like everyone has some kind of Lean initiative. When organizations feel pressure to do something about their slowness, inefficiency and poor quality they naturally grab for things like Lean. Lean is one of those pin-up initiatives, like CMMi, TQM and Six-Sigma, that gives the impression you are serious about solving a problem, but in reality makes little or no difference. 

This has become increasingly frustrating in the software industry. It's not that I have any particular gripe about Lean Product Development (the type of Lean that software developers should use). As anyone who knows me can attest, I truly like and support most of what is commonly Lean, however having a Lean initiative seldom makes any difference to a product development organization.  To the extent that inventory or queue optimization makes sense, most organizations can't or won't take advantage of it. Moreover, most of the causes of slowness, inefficiency, and poor quality are not addressable by a Lean initiative.

The question is, what are you really trying to fix with Lean? Too slow, too inefficient, too crappy, or too what else?

Ten times out of ten an organization has problems in these areas because they don't actually value them.  Yes, there - I said it.  Organizations are slow because they don't value fast. They are inefficient because they don't value efficiency. They ship lousy products because they don't value excellence.  Organizations lie to themselves and pretend they value these things, but many don't; at least not as much as they value whatever they are trading them off for.  If they truly valued speed, efficiency, and quality then they would already be doing it.  Corporate cultures are inherently self-optimizing and if those things were important then the organization would structure itself around them. Anything else is faking it. You can try to blame process, methodology, or tooling but those are seldom the cause. 

Companies will invest millions in a Lean initiative but won't remove the pervasive and recurring reasons why projects are slow and inefficient, despite the fact that those causes have been known for years.  Ultimately any Lean initiative will run into these immutable behaviors and that's when the organization will get weary of Lean.

Whenever I see an organization complaining about being too slow, I usually see an organization that is wired to go slow. There's nothing pushing to cultivate fast  red-shifted development.  When I see organizations complaining about poor quality, at every turn I see them leaning on big clumsy processes while continuously looking the other way as qualities that really matter to customers get ignored. When I see organizations complaining about low innovation, I see them sitting out every opportunity to take risks, launch bold curve jumping ideas, or partner with cross-segment teammates.

Think of it this way: You have a good friend who admits he needs to lose weight and get healthy but he's taking 3rds from the long end of a buffet line.  He informs you that a new diet pill (Lean Rx) is really good and when you see him next month he will be 50 lbs trimmer.  For a friend like that the solution isn't a diet pill, it's fewer trips to the buffet and some exercise. Same goes for a software organization.

Lean is just a diet pill. It has some great ingredients that can be helpful if you are otherwise committed to efficiency and follow all the directions on the package.  However, if you pop the pill but keep gorging on inefficient processes and people then it won't make a darned bit of difference; you'll just be out the cost of the pill. Moreover, if you are really committed to improvement then a Lean pill isn't really necessary.

In a software shop if you want faster product development then cultivate a "waste anything but time" culture. If you want better quality, make sure high standards are deeply embedded in everything the organization does, from hiring to engineering to content to aesthetics, and especially to customer experiences.

What your people need to see is an intolerance from the top. They need to see intolerance for slow, inefficient, low risk, low reward behaviors.

Want to move faster in product development? Find your best team, you know who they are, and ask them who is in their way - then remove those obstacles (usually people). When you do that announce that "this company will no longer tolerate obstacles, blockades, and culture of no. Starting today, if you aren't focused on faster development or improving customer experiences then you don't belong at Acme Widgets".

Hire and promote people who accelerate product development and enhance customer experiences. When those people tell you something is in their way, nuke it. That's the core of it, everything else is gravy. 

If your best people have something in their way and they've told the bosses but nothing changes...those people are learning what the organization truly values.  Remember that.

Organizations today seem more interested in compressing development timelines than anything else. As well they should. Time to market rules!

In our push to red-shift product development we can't sacrifice quality or innovation. In fact, we need to maximize those.

All special considerations aside, the ideal amount of time for most new product development (software) is at most about 10 months.

Assuming that sounds desirable, how do you do it?

The first trick to going fast is to fix slow. We've done a lot of studies, including a recent customer funded review of a large portfolio of projects, some good and some bad. The #1 cause of slowness is directionlessness (not a word, but you get the idea). Project teams that have a clear idea of what they are building make good steady progress. Project teams that don't have that clear idea tend to thrash, churn, and struggle. The result is pretty much the same with or without Agile.

Many of you know about the famous Toyota Product Development System (TPDS - not TPS).  Years ago Toyota was the first to compress automobile design to 2-years.  More recently they got development down to 1-year. Today they are at about 10 months. For a car!

That’s only half the story though.  Here's what the headlines don't say when Toyota brags about its famous red-shift product development: The 10-months begin after a "style freeze" phase gate. The creative piece, i.e. the "front end innovation" is not counted as part of Product Development. In fact, Toyota does not publically discuss how much time their projects spend at the front end.  They appear to have two product development management systems in place; one for the front-end and another (the TPDS) for the back-end.

The world's red-shifted organizations have several things in common, but mostly they have separate Design and Development phases and are able to fly though the "Development" phase.  The problem with most software projects (especially with Agile) is that the entire project is essentially Development. With no front end it's basically a crapshoot whether a software team will have clear idea where the product is going.

In the old days (Waterfall) we had a design phase, but it was the wrong kind of design. Sure, product design took place in that phase but activites more often focused on technical design and the results exhibited all the pitfalls commonly cited for Waterfall. The outputs were "specifications" not game-changing curve-jumping culture-defining market-satisfying ideas.

Two things that Agile does not fix: Time to market and innovation. I suppose it can't fix stupid either, but that's another problem (thanks Larry the Cable Guy).

Agile is without a doubt the best collection of practices available today for developing software. However, Agile (defined loosely as the contemporary fusion of XP and Scrum practices) can often fail to get a project pointed in the right direction, mostly because Agile doesn't address front-end innovation or product design. Agile is a production practice, not a creative practice.  Game-changing curve-jumping culture-defining innovation remains a scarcity even with Agile because people's attentions are fixated more on building software than on ethnography, ideation, experimentation, and Design.  Though you can do those things within an Agile iteration...they completely disrupt the productivity of Development.

Red-shifted product development starts *after* you know what you are building. (I can already hear Agilists getting their torches and pitchforks ready).  But whatever…this is how successful red-shifted product development shops work.

So here's the rub. If you want to go fast and red-shift your product development practice you will need to do a few things:

#1 - Separate the front-end from the back-end. We call our front-end "design innovation", you can call yours whatever you want. The front-end is about finding the right ideas, hopefully blending a bit of the unanticipated with the expected. It's about ethnography, ideation, experimentation, and Design.

#2 - Don't exit the front-end until the product concept "works". By works, we don't me that it runs...we mean that it is vetted, people like it, it's game-changing curve-jumping culture-defining market-satisfying.  You can't vet what people can't visualize, so prototypes and tangible artifacts are really important. Avoid PowerPoint, it's "show me don't tell me time". You should only gate into development after you’ve made it clear what exactly you are building.

#3 - Keep headcount and burn-rate low until you gate into development, but be ready to hit the ground running.  Keep your labor costs really low at the front-end, otherwise you'll get too much pressure from the top to gate out of innovation before you have anything cool.

#4 - Develop during Development. You're done with research and ideation, focus on building. 10 months and done! If you make major course changes during development we call that "thrashing". With a good front-end design process you'll still iteratively innovate and refine scope, that's what Agile does. However, the core personality of a product should be defined before Development starts. Make a qualified high-energy push-for-excellence person the "Floor Boss" and empower them to get things done right.

#5 - It's software, you don't have to do everything at once. Launch something innovative with good quality then update the heck out of it until it's perfect. If your updates are spaced out longer than 3 months then you are doing it wrong.  If you can't knock out a major update every 3 months then start firing people until you can. And FYI, 3 months is becoming a long time these days...

#6 - Have a healthy relationship with requirements and specifications.  There are parts of a product that are "Designed" and parts that are "Required". Don't write requirements for Design elements, but do have requirements where you need them.  An example of a requirement is "the gizmo shall oscillate at a frequency of 3.21GHz +/- 1Khz". That's a requirement; independent, assertable, and precise.  Design is softer. Design covers such things as how a user might get something she needs in a way that is intuitive, pleasing, useful, and efficient.  Don't invest in Design then write up the results as requirements...that's just dumb.  Err towards using Design over requirements when the choice isn't clear. Oh…and use people with some Design talent, it’ll go faster and everyone will be happier.

THE BOTTOM LINE
The first secret to moving fast is knowing where you are going. If you have a great product design process at the front-end then you can kick butt on the back-end. The goal is for Development to be smooth and linear.  You won't get that from the aimless wondering of an Agile process any more than you can get it from the fat up-front System Requirements Specification and work breakdown structure of Waterfall.  You need ethnography (lots of it), creativity, talented Design, and visual prototyping to unlock the front-end and pave the road to a 10 month (or shorter) new product development cycle.

Lastly, if your ambitions are big (like an Operating System) then you have no choice but to acquire technology from the outside. You won't finish in 10 months but you can at least finish quickly.  That was how Apple OS X got done in short order, it was also how they got the iPhone done; how Microsoft did Xbox and Zune; the list goes on.  You don’t have to build everything, you just need to build the parts that make it special and identifiable as yours.

And just when you think it can’t be done…look at the teams doing it. For example, the Expression Blend™ team at Microsoft - check out how much innovation they've shipped over such short intervals. It’s inspiring and motivating.

Why iPhone apps are so much more beautiful
  

 
Every Ux Designer working today knows the iPhone is a game changer in raising the bar for the entire software industry.  It's often said that the iPhone ruined the gig for Developers because users now expect iPhone quality experiences in everything they consume. 

How many new product teams kickoff their desktop or web projects by saying they want "iPhone quality" in the Ux?  A lot do.  Most fail to deliver.

Why do iPhone app teams succeed at iPhone quality, but desktop developers don't?

Watch this vid.

From the video it is easy to appreciate the sheer number of revisions a single iPhone screen undergoes to become beautiful.  This is no simple process of drawing a few Buxton-style sketches then kicking the Design over to Creative for a chrome job.  It's a painstaking process of refinement where the Designer tries something, tosses it, goes back to the way it was, changes it, starts over, etc.  The most challenging and cool elements are the smallest details.  It's not 5 or 6 revisions to the Ux...it's 50 or 60.  Per screen!

Yet - it can be done.  Mostly because iPhone apps generally have one main screen (the goal screen) and only a few supporting screens (tool screens).  The majority of iPhone apps ship with under a half dozen screens.

Now consider the typical enterprise application, with its 50 - 500 screens, and imagine using that process from the video.  Yeah.  That ain't happening.

A Designer can afford to nerdfest one or two screens, but that level of quality quickly becomes unreachable with high screen counts.

On the Microsoft stack we can use WPF to make beautiful applications almost effortlessly, where beauty and simplicity have very little technical cost.  However, tons of iteration on the experience itself is still necessary - and when teams aren't willing or able to commit the necessary 50 to 60 iterations...the quality just won't be there.

An international Agile conference happens in Chicago, does anyone notice, or care? Seriously, what a bore.  For years we enjoyed attending the Agile conference but it's become such a rerun there's no point in going anymore, let alone blowing the usual $70K we spend on it.

If you doubt me, read the conference program: 

Compare 2009 against last year, or the year before, or the year before that.  Nothing ever changes, it's the same worn out people and worn out jibber jabber we've sat through since the days of OOPSLA.  Yes, it has those book club celebrities we all love. Yes, there are always a few new faces trying to impress the old guard with populist insights.  Yes, there's an ever present contingent of eager Europeans who seem to think a bunch of content-free North American academics and gray haired hippies on oxygen walkers can teach them something useful.  And while the masses learned to spell Kanban at an Agile conference (even if we can't pronounce it), be honest, is Agile a hotbed of anything relevant or innovative?

At least SXSW has the good taste to make getting bombed part of the show.

The "stages" at Agile2009 are platforms for Scrum/XP topics.  The one supposedly forward aiming stage, called "Agile Frontier", entices attendees with such leading edge topics as "New Approaches to Risk Management", "Big Balls of Mud", or "Working with large backlogs". 

Gee guys, is that the best you've got? Hold me back while I contemplate being surrounded for three days by people who still think "risk management" is leading edge.  Why not pass out Xanax tablets and be done?

What, no burning man?

The Agile2009 program actually lists three or four separate sessions on how to prioritize a backlog.  Wow!  Does that come with a laxative?  Come on, is it that hard to prioritize backlog?  No wonder so many Agile projects are in trouble, they're all constipated.  Where do people work that they need to be taught to prioritize?  Isn't prioritization kind of like breathing, aren't you born with the ability?  Guess not.

All this focus on managing risks and backlog, yet the Agile community has deliberately closed its eyes to product Design (design with a capital "D"), and therefore failed to notice that all the action is at the Front End of Innovation, not the Back-End where Agile lives.  To be fair, Agile does a fantastic job at back-end innovation...no gripes there, but when a project innovates at the front-end there's never any worry about prioritizing.  Silly rabbit. Didn't you get the memo?  It's all about the funnel.

That said, I might not like the conference but I still love Agile.  Our company will continue to use major pieces of Agile on software projects until the end of time, it's not a fad - it's part of any good software house.  It's just not transformative anymore.

Agile is yesterday - hit save on the good parts and move on. 
- Continuous Integration & Continuous Automated Testing, save
- Working software instead of big binder of stuff up front, save
- Iterative versus stage gate progress milestones, save
- Back-end innovation with customer participation, save
- Treat programmers nice, save
- Pick on traditional testers, save

Agile principles and practices are cool but where's the hot action in software?  Today it's all about innovation.  It's about what you can build for a customer that they never dreamt was possible.  A lot of that innovation arrives through Design.  Modern software Designers want people to love our products, not just sign-off in acceptance of them.  Being able to write great code quickly is a requirement for the job, the stuff Agile brings has become an expectation, not a feature.  If you can't bring game they'll find ten others who can. 

Since I mentioned Design, please don't start thinking it's all about User Experience either. Great product Design is about more than just User Experience.  While I'm thrilled to see User Experience getting serious keynote attention at Agile, Ux is just one aspect of Design.  Product Design is bigger than that, it's about deliberate repeatable innovation and altering culture by changing how people view their jobs, leisure time, and life. Products help define each generation.  Design defines products.

At Agile2010 I expect attendees will no doubt be busy trying to figure out how to arrange Kanban cards on a wall so as to integrate with Buxton-style Ux sketches... I'm sure that will be fun for them.  Back in the real world the serious players will be inventing new products by applying techniques pioneered in the planet's most competitive industries that rely on constant innovation for differentiation.  The software professionals who learn to perfect the funnel at the front end of innovation will enjoy life as market leaders, innovators, and game changers.  Sadly, those who pause too long to absorb simple back-end tricks will become the new blue collar workers as the rest of the globe makes software development a commodity.

I had hoped Agile would become a generational software conference where great creators of software would get together each year to share discoveries and insights.  Instead, it's just another place where people who build a tiny amount software but write a lot of books can congregate to promote their celebrity status among the gullible.  The Agile conference has become another OOPSLA; a single-theme conference that will expire with the times.  Long live contravariant polymorphism!

So, good luck and goodbye Agile Conference!

Hope to see the best of you at shows that are a little more...well...driven to innovate!

A parting tip: If you want to run a great software conference, require all presenters to have released a product or major update within the previous year or so.  Rather than submitting abstracts...how about submitting software titles?  If your biography doesn't start with "I built..." then how else are you to be judged? After all, it is a "software" conference, right? 

Delivering big ides to the masses was once the exclusive job of scientists, engineers, and tinkerers, but for a variety of reasons Designers are now at the cutting edge of creating and delivering the future.  Design is the new focal point for big ideas, especially as related to directing people’s motivations to buy, upgrade, or convert to new technology.