STEP: Implement it in small, practical stepsAt a certain point, you just need to jump into the arena and get your hands messy. After all the meetings, word docs, PowerPoint slides, business ROIs, and cheering sessions, eventually someone needs to actually start writing code or changing scripts or procuring a tool so that the change actually happens. PowerPoint decks are not change; working C# code running on other people's machines is.Be practical - you must meet people where they're at. You want to give a drowning man a life preserver, not swimming instructions.
- Be prepared to build the prototype yourself - You may not be able to wait for your manager to give you schedule time or for the PMO to hire contractors to build it - necessity may demand that you start something yourself (this probably means nights or weekends). If the team thinks it has potential, you have a good chance of handing it off to other developers and letting them run with it.
- Your deliverable must be something concrete - Tools, approval emails from management, scripts, or code blocks are all concrete. An email with a link to a "cool" article, or a suggestion of what we "should do if we only had time", is not concrete - it will no more feed your team's need for improvement than an article on restaurants will feed a hungry family.
- Make it work - If you're making a tool, make it easily available (say, publish a working version to a public share - don't require them to compile the source code themselves), make it run on their machine, and ideally give it default config values so that it does something useful right off the bat. From the time Kurt agrees to look at your tool and you arrive at his desk, you have minutes to download it onto his machine, click a single icon or dos command, and have him see the pain that the tool saves him from.
- Start small, and continually add value in incremental steps - Have some deliverable every week. If you're working 20 hours on a project, there's got to be something to show for it. Avoid the "just give me 3 months and I'll give you the perfect solution," because they'll never give you a blank check for 3 months. Even if they do (say you've built up a great reputation with previous successes, so management risks big schedule time on your ideas), some big emergency will interrupt you 2 weeks in. You'll be constantly distracted with the "urgent" so you'll never get to actually do the "important". You're 3-month salvation project will lay in mothballs, taking some of your credibility with it.
- Don't be paralyzed by perfection. I.e., "perfect is the enemy of done". An imperfect solution that actually does something is adding more value (and relieving more pain) than the perfect solution that never got built. Consider building a quick "band-aid" or "throw-away" solution now to stop the bleeding and then building that perfect solution in 6 months when the schedule magically opens up and you have all the time in the world (yes, this is sarcasm).
- Don't be paralyzed by "coolness". Lots of developers like "cool" new technologies. However, such technologies often have risk and learning curves - which may mean that you only have enough time to come up-to-speed with the tech, but not to actually build something useful with it. Many of the infrastructure problems that most shops face have already been solved with older technology - look at classic books written in the 1990's like Code Complete and The Pragmatic Programmers, and ask yourself - how many of those good practices is a suffering department still lacking? Nightly builds, automated deployment, unit tests, modular design, layers - they were all done with over 10-year old technologies. If some cool new technology saves your day - great - but don't limit yourself to it. Sometimes a good old fashioned xml file and console app plumbing is sufficient to save your infrastructure.
NEXT: Part 6
No comments:
Post a Comment