software solutions / project leadership / agile coaching and training

Corporate frameworks and corporate standards

Posted on August 19, 2011

Most IT departments manage multiple projects and applications. As you go from project to project, you inevitably will find better ways to do things. Then at some point, someone might decide to get the smartest people together and come up with the one corporate framework to rule them all. All future projects will use the new framework, which makes sense because we’ve taken all of our good ideas and combined them so that other developers don’t have to go down the wrong path. I’ve had this idea before, it’s a great idea, right? We’ll have less risk of failure and we won’t constantly reinvent the wheel.

Companies think that by doing this, they will reduce the risk of failed projects. But they are buying into two things that are fundamentally incorrect — that they won’t be able to ever come up with a better way of doing things and that all projects are the same.

Ultimately what is lost when corporate standards are mandated is innovation. Developers are smart people, and many of them are trying to find new and better ways of doing things. If you don’t encourage them to find a better way, either they’ll quit trying, feel defeated because they can’t change things for the better, or get upset that the process is hindering them from getting things done better or faster.

Also, all projects are different. I’ve been on many “agile” projects, and every one did things differently. This is good because working on a two-person team at a startup is much different than working in an enterprise IT shop. I heard of one company who was trying to do an “agile transformation” so that they could find a methodology that they could standardize across the enterprise. It’s great to see people adopt agile practices (which are generally good), but trying to “standardize” so that everyone has to do things to same is directly opposed to the agile idea of continuous improvement. (Often times, the standardization of methodologies is mainly done so that common metrics can be established by which to judge teams, which encourages teams to game the system to make their metrics look better instead of solely trying to provide business value in the best way possible.)

The Alternative

What if instead of mandating that everyone used the same corporate framework, we encouraged teams to come up with the best way of doing things and then share them with other teams so that they can adopt each others’ best ideas if they so desire?

What if instead of mandating a framework, we created a repository of random pieces of code that people could pick from to do common tasks (e.g. an authentication library that authenticate to some corporate server)?

What if we stopped being obsessed with metrics and measuring teams and just went out and got the best developers that we could find, and then gave them everything they needed to do an awesome job?


  1. Amen! It’s funny, I’ve come full circle to your exact alternative way of thinking here. In fact, I have been the one championing the “frameworks” and “standards” in the past… but now that I’m a little older, wiser, more experienced and have had the opportunity to innovate I see the flaw in that mentality.

    Unfortunately, most corporate IT shops are so enamored with the standardization concept that continual improvement scares the bejesus out of them.

    So maybe the trick is finding a “standard” way to ease peoples worries in the big scary, uncharted world of continual improvement. ;)

    Ed Castaneda — August 19, 2011 @ 11:29 am

  2. Hi Jon,

    While I agree with your vision of things, I wonder how would you factor these things in:

    1. While like you said, developers are usually innovative and smart people, not all of them will get things right when they try to re-invent something (a specific feature or functionality) they feel they can do better than a proven framework (either company made or third party). Even if they end up getting it right, the time it will have taken them to figure out every possible quirk or scenario will add-up to client cost, no?

    2. Once again, they probably can figure out a different (probably better) way to do something. But will it scale? Most of the times, if a company dedicated time, effort and money to develop a framework, they will have considered a lot of scenarios from different projects that they want the framework to handle. Probably the way the developer coded a specific feature will require a lot of rework when using a proven framework would mean way less work/coding.

    Then again, I’m a developer, I’m all for the way you suggest of doing things. The approach you suggest if all developers (if at least most of them) were passionate and committed. However, that’s not the case, and I guess that’s the reason sometimes companies force projects to use frameworks.

    What do you think?

    Gabriel Rodriguez — August 19, 2011 @ 3:17 pm

  3. Two points:

    1) You missed what I think is the biggest argument against the corporate framework; architects and managers who abdicate their role/responsibility to the framework and stop working with developers or taking interest in the code that’s being written in their shop. I’ve seen this several times. The thought seems to be “If I put these shackles on tight enough, there’s no way they can do anything I don’t want them to do.” The problem is that the shackles are usually so tight the developers can’t do anything at all.

    2) Having said that, I have seen these types of frameworks work. The keys appear to be having the architects/technical leads remain involved with day to day development, keeping the framework flexible to enable the developers to “opt-out” of the framework if they have a task that is better accomplished doing something else and finally having a means to review and update the framework. This review process needs to be transparent and accept input from all interested parties; not just be the architect hiding in his office unilaterally deciding what everyone should be doing.

    Just my $0.02

    James Bender — August 20, 2011 @ 7:24 am

  4. @James,

    I don’t think I could’ve said it any better!

    Jon Kruger — August 20, 2011 @ 8:18 am

  5. You’d have anarchy. Sweet, glorious anarchy!


    Justin Kohnen — August 31, 2011 @ 3:55 pm

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
From Stir Trek 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010