Under the hood and working with .Net, TDD, Software Design, and Agile Stuff
I'm starting at a new client in a couple weeks. Last time I did this I created My Gameplan for Starting a New Project. I think it mostly held up with a few exceptions, mostly around the quality of the upfront analysis leading into the initial story list. I think next time I'd like to get just a bit more time and much more access to the business experts for building up the initial story list and release estimates. Last time I was worried about the effects of Analysis Paralysis and gaining momentum early. I want to revisit that just a little bit and think about the questions I want to ask my new client team right off the bat:
- What constitutes success for this project? What's the primary goal?
- What's the iron triangle constraints? Time, resources, or scope?
- Who are the stakeholders? End users? Who's paying for this thing?
- Who are the business and technical experts that we'll need at some point?
- How much contact and interaction are we going to be able to have with the end users and business experts? Are we going to have a customer representative or advocate embedded onto the team?
- What are the legacy systems we'll need to interact with? I want to know the challenges around the legacy system or existing infrastructure -- and you know there's always something nasty about a system of any age.
- What external teams are we going to need to interact with?
- Is the team self contained (testers, analysts, developers, and a PM all together under a single organizational structure and team), or is the testing team in a completely separate organization? Obviously, I think the first choice is far superior in terms of results and efficiency, but you gotta play the cards you're dealt.
- Obviously, I'm going to try to use Agile practices (mostly XP with some Scrum flavoring). Is that acceptable to you? Do you have any experience with a disciplined iterative approach (waterfall is still by far and away the most common SDLC)? What kind of project management practices do you use today? How about development practices? I would try to use Continuous Integration and Test Driven Development no matter what, but other practices can be harder to sell or do in non-Agile organizations. As an immediate example, I want to do Acceptance Test Driven Development anytime the analysts and testers can and will play along (I think we can in my next project, but couldn't on my current project).
- A very important question: can the team exert a great deal of control over their practices and process? Or are they bound by a corporate standard?
- Assuming that you can control your own process, what are your pain points today in your existing process? Theoretically as a consultant, you're supposed to do something to add value ;-)
- Where's the build server, and can I and the team have full control over it?
- What is your policy towards using Open Source software? Obviously I'd never advocate any tool under a viral license, but how about less restrictive licenses? Do I get my head chopped off for suggesting OSS tools when they're superior to the built in or nonexistent Microsoft offerings?
- What is it that you're not telling me? It's worth a shot ;-)
- Can I get my laptop in the network? More importantly, what am I not supposed to do on your network. Never hurts to ask.
- You are using Subversion right?
What'd I miss?
About Jeremy D. Miller
Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#.
