Sunday, July 11, 2010

Change: Incrementally Making Things Better (Part 4)

[This was originally posted at]

  • Part 1 (Intro)
  • Part 2
  • Part 3
  • Part 4
  • Part 5
  • Part 6
  • STEP: Determine which initiatives to push

    I am continually surprised by how many smart, energetic, and good-intentioned veterans fail to change their organization because they're pushing the wrong initiatives.You cannot boil the ocean. There are simply too many good initiatives, and you cannot do them all. And even if you somehow could change the entire department (say you win the lottery, and kindly use it to hire a team of star consultants to fix everything), your team couldn't absorb it all. Therefore you must pick your initiatives wisely. Keep in mind that success will increase your credibility with the team, which encourage more success, whereas failure will decrease your credibility. Therefore a small success that actually just works is better than a huge initiative that "almost" works. Unemployed departments are full of cool projects that "almost" work. Here are guidelines to help pick good initiatives for change.
    • Knock off the low-hanging fruit. Start adding value (and therefore building credibility) with small wins - perhaps a quick tool or code refactoring or convention you can get done in less than a day.
    • Emphasize the high ROI ideas first. For example, updating legacy code that already works has a low ROI because you've gone from "app that works" to "app that worked - gee, I hope I didn't break anything - but now it's easier to maintain." Look for industry-proven changes that give a big return, such as the introduction of code generation, reusable blocks, unit testing, developer tools, change control, etc... New ideas that just "tax" the already-busy developers will go flat.
    • Focus on new code. No-one wants to go back and re-write legacy code. Much easier to get people to adapt for new code. If every change has to be applied to 2 million lines of legacy code, it will be like dragging a lead ball around; nothing will get done.
    • Pick changes that cooperate with other initiatives. If you're company is desperately trying to improve performance because angry customers complain about slow page loads, now's the time to introduce a caching framework. It will be like running with the wind at your back instead of against your face.
    • Break big initiatives into smaller steps. You may not be able to introduce that new attribute-based validation system right away. However, perhaps you can first start building a static utilities library of common validation functions so all the logic gradually gets aggregated in one place. Then you could modify the data layer to pass in entities. Then you could add the validation attributes to the properties on those entities and have a reflection-based component apply the logic. You may not be able to do the big goal all at once, but you could do the small steps piece-by-piece.
    • Show how the idea supports the business goals. The easy way to do this is to ask what business goals the managers care about, and pick technologies to support those, as opposed to picking techs that you think are "cool".
    • Have either unanimous team support or objective success metrics. We all love hard data, but sometimes a developer just has a "gut feeling" that they know something is right, and they don't have the data to immediately measure it. General rule: if everyone already wants the same goal, then you don't need to convince them with objective metrics ("we really need a tool to automatically merge changes from one branch to another"). However, if people aren't convinced, then you will need some way to objectively measure the benefit.
    • What do you care about? Even if something has low ROI, if you'd enjoy it such that you'd spend your own weekend building it - and would have fun doing so - then go for it. You hit two birds with one stone - you get to play with a niche technology or cool tool, and your day job benefits from it.
    • What do others care about? - What changes does the rest of the team want? If Lenny wants to automate deployment, and Susan wants better refactoring, and Sunil wants reusable UI controls, then consider adding your weight to those.
    • What are the prerequisites? Does your pet project require something else, say purchasing a new tool, refactoring tons of code, or a new team convention where people suddenly change their habits? If so, focus on those prerequisites first.
    • What other opportunities does this open up? Related to the previous point, some initiatives open up the door for other big opportunities. Say you purchase a tool (like CodeSmith) to introduce code generation so you can automatically generate data access CRUD plumbing. You can then use that tool to also code generate many other things (base data, install MSI packages, proxy classes, etc...)
    • Meet people where they're at - If the team culture is completely opposed to pair-programming, you probably don't want that to be your keynote initiative. If the team is being burnt alive putting out fires, they won't care about anything other than a water hose.
    • Can this initiative succeed? Seriously. Remember that a small success is better than a big "almost". Focus on attainable goals.
    Given these criteria, prioritize your ideal changes. If there's a hundred things you want to change - great - make an excel list. But then pick your top 3. Then pick your top 1.Some people need to see a list. If that's the team culture, then consider making an excel sheet. Depending on your team, you can make it informal (like the sample below), or very formal - complete with numeric weightings. There's no one-size fits all. If it's too informal, your team may say you "haven't thought it through". On the other hand, if it's too formal, then they may get stuck on inconsequential details like whether making a CI build takes 4 hrs or 8 hrs. In general, you'll want at these pieces of info about each initiative:
    • Buzzword - Some label, less than 3 words, that distinguishes the concept so everyone can easily refer to it.
    • Description - Any special notes or hints about how to do it.
    • Effort - Is this big, medium, or small? A formal scorecard could have an hour estimate here.
    • Benefit - Is this project even useful? A formal scorecard could have dollars or time saved here.
    • Prerequisites - Must be in place for this to work?
    • Who cares - Successful initiatives need people to support them. Will this benefit Cary in IT, the entire QA team, or make your manager's life easier?
    • Obstacle - Why isn't this already done? Is it just lack of time?

    Here's an informal sample. Of course you can add more columns and vary it up depending on your team culture. Note that some items will be small (get account access), but others could be team-wide initiatives (enforce unit test code coverage).

    BuzzwordDescriptionEffortBenefitPrerequisitesWho cares?Obstacles?
    Access to QA databaseGet devs read-only access to QA databaseMinor - ask security teamMedium - lets devs assist with QA bugsManager approvalDevs, QAMartin fears this will hurt QA performance
    Purchase ETL toolInstead of building ETL ourselvesMinor, but costs $$$MediumManager approvalDevs, QA (easier to test)Procure funds
    Developer CI buildUse TFS to have hourly build for dev source codeMedium (less than a day with Monty's help)Huge - instantly detect compile errors, hook other steps into build like unit test and MSI packagingBuild Server, management to insist the build passesAll devs, managers,  Bart [a senior dev] especially wants this too.No spare machine for the build server
    Split VS solutionCurrent solution is too big, hard to work withSmallFaster compile timesSenior Dev supportHalf the devsTime
    Make validation libraryPut validation logic in reusable utilitiesSmall to start, could be bigStandard validation, supports future frameworkNeed a common assemblyHalf the devs, Lisa [a product manager]Just need time to do it
    Add unit tests - Phase 1Just let devs optionally write testsMedium - tools are freeHugeGet test harness (like NUnit)DevsCulture doesn't support it, so tests not maintained
    Add unit tests - Phase 2Make  required, part of the buildBigEnforces unit testsCI Build, code coverage tool, manager supportEveryoneLots of people don't like UT, "it takes too much time"
     Lastly, as we discuss which initiatives to push, don't use any of these techniques - they will fail miserably:
    • Try to change everything at once.
    • Push for a change that no-one sees the benefit of (You'll just be branded as that "annoying guy who doesn't get it").
    • Don't have your own list, even a mental one. (Merely saying things are "bad" won't fix anything. You'll need concrete examples of what to change.)
    • Wait for your manager to give you a list and make it perfect. (Your manager is busy, and they're probably focusing on higher-level problems. They need you to pro-actively tell them the problems you're facing - and your proposed solution.)

    NEXT:  Part 5


    No comments:

    Post a Comment