Architect Driven Development

Architect Driven Development, or ADD (just add the H in the appropriate place for most of us), is my new methodology of choice.  In the large Enterprise context, where Agile is difficult to implement across many teams, ADD hits the gap by positioning the Architect to enforce the development methodology as well as the software architecture.  Let’s face it, as Architects we end up being the people that, at least at first, are ensuring the development methodology is followed.

Why ADD?

In the Enterprise context where there are numerous teams spread across many mini-empires, one of the few roles that can be consistent is the Architect.  In my role at Best Buy, I run a 70 person development team.  That team is broken into eight different workstreams all lead by top tier architects.  As long as the architect team is aligned on both a methodology and high level architecture goals, we get consistent results from our teams.  It helps a lot that we all believe in Agile self-managed teams as it gives the developers the freedom to do the work how the team sees fit.  But the architects carry the consistency through the development process from start to finish.

There are also a couple hundred developers working on various parts of BestBuy.com that are not under architect control yet.  These teams are largely driven by outsourcers who have a vested interest in keeping Best Buy architects away from their work.  If we were there, they wouldn’t get to staff their $200/hr architect on the team or their 10 offshore counterparts.  The problem here is the outsourced architect is not on board with our development methodology or high level goals, and given our structure there’s little incentive for them to even care.

So as we strategized how to get better control over the dotcom platform, I put forth that as long as we controlled the architects and the process, nothing else mattered.  Inherent in that control is control of resources as well.  Since our hiring standards are tough, we only get top notch developers which makes everything else easier.  But without a strong architect voice to push a methodology, pick resources and keep the architecture vision, the process would fail.

Next time you are thinking about restructuring your development environment, stop thinking about what methodology you’re PMO is going to use and start thinking about getting strong technical architects to carry the vision and methodology.  You’ll find that the rest of the process falls into place afterwards.

Think, Do, and let the Doers Think Too

I just did my first video interview about what BestBuy.com is trying to build and how we are trying to build it.  It was fun but I came out of it thinking about the overall strategy Best Buy has applied toward technology for the last 10 years.  In a nutshell, and this is certainly not new information, Best Buy has decided that thinking is the most important part of technology strategy.  Therefore, we only staff managers who think about business problems, and farm out the doing to the cheapest vendor we can find.  If you ever try to do anything technology related at Best Buy, you have to have a big IT vendor do it for you.

The problem with this attitude is that no value is placed on the technical solution. When technology is driving the base strategies of so many eCommerce companies, it is hard to understand why we don’t place value on technology.  Last year alone we taught a number of our vendors how to build elastic systems in the Cloud.  When our projects were over, all those people we taught went off and built elastic systems in Clouds for other companies, likely our competitors as well.

Not only Think.  Not only Do.  Think and Do.

If you only staff Think you are reliant on someone else to Do.  You are giving away you’re strategies and technologies.  Most importantly, you’re giving away your minds that have learned new technologies and new strategies.

If you only staff Do you may pursue interesting technological pursuits, but their business value may be suspect.  From a tech person standpoint, just staffing Do is very seductive.  I’ve been on plenty of teams where the implementing team knew the business requirements better than the business.

Think and Do.  Tech and business teams highly coupled and dependent on each other can produce amazing results.  One of my favorite projects was with a highly engaged business customer who took a high functioning Agile team in directions we never would have expected.  The results were superior to anything the tech team could imagine.

But the best of the best comes from Think, Do, and let the Doers think too.  This is the core of the Agile process where decisions are distributed to the people that know the system best.

Think, Do, and let the Doers think too.