Category Archives: Uncategorized

Pattern of Innovation

Innovation follows a pattern.  If you know the pattern it can help you identify innovation occurring in your own company, it can also help you manage an innovate project.  First of all, you identify the different phases of innovation and have knowledge on how to respond to difficult situations.  It will also set your expectations correctly in regard to starting and running an innovative product development program.

The ideas behind the pattern of innovation are found in academic research published by Andrew Van de Ven in The Innovation Journey.  Through long running study of numerous innovative product development cycles, Van de Ven and team have amassed a great deal of knowledge around how innovation works and how to manage it.

I recently gave a talk on the pattern of innovation at Ricon2012.  You can see the full video here:

A Company Should Act Like a Cloud

I’m reading Harvard Business Review again after taking a few years hiatus after finishing an MBA.  There’s an excellent article in the Nov 2012 issue about innovation and work and having an additional operating system to manage innovation (ACCELERATE!, by John Kotter).  This got me thinking about how a company should act more like a Cloud.

The notion in Accelerate! is that to innovate a company needs a second operating system running along side the normal hierarchical structure.  This second operating system is a network of company appointed change agents along with volunteers that work for the cause.  Essentially it allows workers trapped in their box of a hierarchy to work on innovative projects in their “spare” time.  The networks spin up as need and as quickly dissipate back into the organization.

To me this sounds essentially like the same reasons Cloud computing has become so popular.  Instead of having compute units (workers) with additional cycles available languishing within a hierarchy (datacenter), we build a network that can tap into those units.  When we need to use them we throw a topic onto to the queue and see which compute unit picks up the work (master/worker).

This also greatly mirrors the Agile concept of self-organizing teams.  The network teams have no hierarchical leader and therefore must determine how to do the work amongst themselves.  This gives them both the power to decide and the mandate to implement their decisions at the same time.

If a company acted more like a Cloud than a hierarchy, who knows what it could do.



Why Agile Always Dies in the Twin Cities

Purely based on circumstantial experiential data, Agile always dies in the Twin Cities.  That being said, the same people pack their bags and move on together, or to the other current Agile refuges, to continue working the way they want to work.  I’m terming this the pedal-pub Agile development model of the Twin Cities, the party is always moving on.

When I say Agile I’m not talking about the latest IT initiative to make all their development projects Agile.  But the true grass roots, visionary leader who managed to convince their boss that Agile is the way to go.  Agile meaning developer empowered self-managing teams where no project manger or VP is asking for a five page status report each week.  Real Agile where everyone knows to just go look in the story tracking tool and see the burndown chart and what people worked on recently.  Than that same VP/PM goes and asks why the velocity is down this iteration and how they’d rather have the changes to the REST commerce services than the text updates in the UI.

 Why Agile Fails as a Process

The biggest problem with Agile over the last five years is that everyone is adopting it as the new great process to deliver software.  Alistair Cockburn gave a whole talk on how Agile is dead a few years ago.  The problem is when IT professionals get ahold of Agile they only take the process aspects and try to apply them.  Since to me, Agile is a state of mind which happens to have some well known process elements that re-enforce this mindset, Agile solely as a development process always fails.  You just have a bunch of developers that don’t care about processes or work environments enough to vote with their feet and move on to a truly Agile project.

 Failure Pattern

Even when grass roots Agile exists, the existence is always ephemeral.  Why is this Twin City developers?  Because Agile processes are at their best with new development with lots of unknowns and new technologies being tried out.  For your cookie cutter website builds agile works well, but as the project shifts into production the Agile team needs to shift into both a development and production support model.  DevOps has appeared to help solve this problem but I don’t know of anyone in the Twin Cities doing DevOps yet.

Back to the failure pattern, whenever there is the need for a large program that involves complicated web development and lots of new technologies, business teams are willing to take a flyer on some dude spouting Agile development as the way to do it.  Why are they willing?  Because anyone who has tried to implement a huge program before knows that they are certainly going to fail if they try to do it in whatever fashion the organization currently uses, be it waterfall/agile in-house or handing off to some “world class” service provider.  So having heard that Agile has saved someone else’s job, the business sponsors are willing to try anything to save their lives.

The Agile teams show up and assuming that they are well run deliver something of value.  But then reality sets in and new bleeding edge technologies are now old and gray, the money has stopped flowing because everything is complete and works, and the organization spotlight moves off somewhere else.  This is when Agile dies.

Waiting in the wings are all those managers and financial folks who swoop in and say “this project is out of compliance with corporate standards.”  Since you’ve lost your high level sponsors, you have no recourse to change anyone’s minds and the Universal Development Process flavor-of-the-day must now be applied and the project also needs to meet the corporate mandate for 60% off-shore and blended rate of $64/hour.  At this point you’ve had all your going away parties for the prima-donna (but really good) developers and are starting to wonder where to go next.

Best Buy is the Place

This is truly shameless touting of my current workplace but someone has to do it.  Someday, and that someday is right now, we’re establishing an Twin Cities Agile culture that will last for years and potentially forever.  Once Agile is established at one entire company the size of Best Buy, there will be no going back.  I’m saying it, I’m doing it, is going to be the first true Agile Engineering culture in the Twin Cities.

And if it’s not, text me the location of the pedal pub.

You should be sad if Best Buy were gone

Yes, I work at Best Buy and despite our recent stumbles (CEO resigns amid personal conduct probe, big miss of earnings in 2011, forgetting to deliver products by Christmas, everyone saying we’ll go out of business slowly, than quickly) I’m quite proud of the company.  As the Chief Architect of the .com website, we definitely have our work cut out for us over the next few years.

However, what bothers me is the feeling that many people seem ecstatic over the potential demise of the last big box electronics retailer.  While you may think our customer service is bad and that driving to a store and finding the item you wanted is out-of-stock (even though the website said the store had it in stock) is extraordinarily annoying, if Best Buy were gone it would put 180,000 or so people out of work and another big hole in Minnesota’s economy.

Even if you don’t care about that, hopefully you care about social engagement and corporate social responsibility.  One thing I can say after two years at Best Buy is that, as a whole, Best Buy has its heart in the right place.  We may fail but we try hard to put our customers first, we care about the employee environment, and we care about the communities in which we do business.

Just to list a few CSR items that I’m aware of:

  1. We recently completed a complete audit of our supply chain for labor abuses.
  2. We collect used electronic equipment for free at all stores.
  3. We donated $5 million to Fukushima relief along with millions more donated to other causes.
  4. We sent hundreds of care packages to our U.S. military last December.

And you don’t have to believe me, Forbes was impressed with our efforts if not all the results.  Or take a look at our Annual Sustainability Reports.  While we’re not to the point of triple bottom line reporting yet, we’re doing a lot more than paying lip service to sustainability.

Finally, it’s just a cool place to work; for the first time ever, my kids think I have a cool job.  Having worked at over 20 different organizations, I’ve also experienced many substandard environments.  Best Buy is highly employee centric from ROWE to the general environment.  The campus was created to promote networking and the general buzz around campus is energetic.  Despite our woes people are engaged and aggressively trying to work our way out of this current trough.  You can argue whether the strategies we’re embarking on are valid but you can’t argue with the will to survive and thrive.

So while there may be more efficient ways to deliver electronics to the market and many find the push to upsell everyone to protection plans and buy back reprehensible, if Best Buy disappeared it would be one more data point that treating your employees like adults is a failing strategy.  Just one less reasonable workplace in the world hopefully makes you at least a little sad.


Why it’s all about Platform

Keeping Up with the Speed of the Outside World

In a world where anyone or any business unit within a company can build an application on Google App Engine, Heroku or AWS, offering only heavy weight web development as the answer to the business needs is clearly inadequate.  Just as individuals forced the switch from Blackberry to iPhone in the enterprise, a similar shift is coming in web application development.

Groups have always bypassed IT based development as too slow and too expensive.  Every Fortune 100 company I’ve worked in has hired development teams outside IT to get crucial work done in a timely manner.  The better companies acknowledge this and try to at least train the outside developers in secure coding and process for their enterprise.  These outside groups were often stymied because they eventually had to deploy in the company datacenter for data access turning that quick 2 month project into a bitter 10 month project.  But the real problem is the mismatch between expectations driven by innovation outside the business, and the ability to execute within the business.

Bridging the Gap

The key for development service providers within the organization is to offer capabilities similar to what’s available externally yet customized to the unique information and systems available to the organization.  Basically, we need to offer Heroku to our internal business units to build applications, while also giving them APIs into all the enterprise data, content and transactional systems.  Thus the need for web development Platforms within companies themselves.

Platform Capabilities

The right internal platform offers several key capabilities:

  • Transparent operations and elastic scalability
  • SDKs and SLAs for UI and Service components
  • Built-in monitoring and reporting dashboards
  • Smart data caching
  • Simple UI driven interfaces
  • As far as possible, technology agnosticism (e.g. Java, Ruby, .Net should all be viable on the platform)
  • Security from common attack patterns (XSS,SQL Injection, etc.)
  • Metering and throttling
  • Priority for run the business applications
  • Automated failover
  • Disaster Recovery

What this is Not

We are not talking about an internal cloud, ESB or web portal.  We are talking about an internal development platform that likely sits on an internal (or external) (or both) cloud.  By being on the platform and developing as a registered user, you gain instant access to all internal services and data sources.  Where these are and who runs them hardly matters if they all have defined SLAs that are met.  Maybe there is an ESB back there somewhere but essentially no one cares if their service calls are managed correctly.

Unshackling the Business

The whole point of a flexible platform that barely dictates and mostly enables is to allow the business folks to get a little crazy.  In the past development was often the voice of reason guiding crazy ideas towards implementable ideas given time and money constraints.  Those days are over, it is time to let the business go unfettered by reason.  At today’s pace of change, the crazy ideas are the ones that may catch on and the platform of the future will allow those innovations to occur.  As technologist supporting business in this new reality, building internal platform capabilities is best way to meet those needs.