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.
- 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).
| Buzzword | Description | Effort | Benefit | Prerequisites | Who cares? | Obstacles? |
| Access to QA database | Get devs read-only access to QA database | Minor - ask security team | Medium - lets devs assist with QA bugs | Manager approval | Devs, QA | Martin fears this will hurt QA performance |
| Purchase ETL tool | Instead of building ETL ourselves | Minor, but costs $$$ | Medium | Manager approval | Devs, QA (easier to test) | Procure funds |
| Developer CI build | Use TFS to have hourly build for dev source code | Medium (less than a day with Monty's help) | Huge - instantly detect compile errors, hook other steps into build like unit test and MSI packaging | Build Server, management to insist the build passes | All devs, managers, Bart [a senior dev] especially wants this too. | No spare machine for the build server |
| Split VS solution | Current solution is too big, hard to work with | Small | Faster compile times | Senior Dev support | Half the devs | Time |
| Make validation library | Put validation logic in reusable utilities | Small to start, could be big | Standard validation, supports future framework | Need a common assembly | Half the devs, Lisa [a product manager] | Just need time to do it |
| Add unit tests - Phase 1 | Just let devs optionally write tests | Medium - tools are free | Huge | Get test harness (like NUnit) | Devs | Culture doesn't support it, so tests not maintained |
| Add unit tests - Phase 2 | Make required, part of the build | Big | Enforces unit tests | CI Build, code coverage tool, manager support | Everyone | Lots of people don't like UT, "it takes too much time" |
- 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