Most good developers eventually have the opportunity to be managers. Whether they call you the "project manager", "Technical Lead", "Lead Developer", or some other classic middle-management title, you become the 'goto' guy between management and developers. You're the guy who is expected to keep the project in-line, track a schedule, and occasionally answer the question "How's it going?", and perhaps still contribute at a technical level. So how do you do that?

So what do you do next? How do you plan what needs to be developed? How do you know if you are 'on schedule' or heading off-track? Using good ideas from a bunch of successful projects (but no methodology in particular), you will learn the basics of good project planning, execution, and tracking.

While this talk as management methodology agnostic, many of the ideas are tracable directly back to concepts from XP, SCRUM, and even RUP and CMMi. Whether you are following a management methodology or not, the ideas in this talk will be applicable to technical managers.

How many times have you started a new project only to find that several months into it, you have a big ball of code you have to plod through to try to get anything done? How many times have you been the ?new guy? on an established project where it seems like the code grew more like weeds and brambles than a well-tended garden? With a few good structural guidelines and several tools to help analyze the code, we can keep our project from turning into that big ball of mud, and we can salvage a project that is already headed down that path.

This talk will talk about everything from build processes, teamwork, and project structure through versioning, release plans, upgrde strategies, package dependencies, and more. Using real-world scenarios from two projects with 12-15 people working together over a 5-year time span, this presentation will offer advice based on multiple successful deliveries of real software.

Agile software development isn't just about the development team or managers... the customer has an active role too. The customer should be prioritizing the stories in each release, potentially working onsite in constant contact with the development team, and even participating in daily status meetings.

Done well, the customer's presence has a positive influence on the development iteration. Done poorly, the customer detracts from the team's focus. So how do you be the customer of an agile team? How do you teach someone to be that customer?

In this session we will look at an overview of agile methodologies and the role of the customer, customer proxy, and other versions of the "product owner", and their responsibilities in ensuring the success of an agile software development project.

Estimating is regarded as little little more than 'educating guessing', but so much can hang on the quality of those estimates. With good estimates we can set clear expectations for project delivery, but with bad estimates we can run over schedule and over budget, or worse. We often estimate when we know the least about the work that needs to get done - so how can we make the best of what is potentially a bad situation?

In this session we will look at how successful agile teams estimate the scope of work at the beginning of a project, estimate the amount of work that fits into any one iteration, track the work through the iteration, and the 'burn down' through the end of the project. We will look at 'low ceremony' estimation techniques like planning poker, trim down 'high ceremony' techniques like Wideband Delphi, and look at "FET+", an estimation technique originally developed as a foil for a CMMi effort.

With a little effort, a little planning, a little tracking, open communication, and some good metrics, estimation does not have to be a 'crystal ball' activity.