Ship It! - 5.16 We're on a "Death March" Project

First, create a new project schedule. Use The List, and put time estimates on each item. Be sure these are realistic time estimates, not Death March estimates. Work with your tech lead to get the priorities correct and in line with management. Second, with the time estimates on The List, put together a time line for the project. Publicize this schedule. Put it on your white board or your web site. Often schedule makers create time lines simply because they don’t understand the work involved. Help them understand. Once you have a better idea of how much work you can reasonably accomplish, show the time line to your manager. Tell them you think the project is in trouble. Management may not be happy with your predictions, but happiness isn’t the goal. Try to show them that if the schedule doesn’t match reality, the schedule can’t be met (although in some situations, it may be decided to keep the bad schedule for other reasons). Now at this point, you’ve got two choices: move the date or drop the features. If you decide to move the date, keep an active copy of The List so that nobody can add features without adjusting the time line again.

Ship It! - 5.15 We're Junior Developers, With No Mentor

First, get your team lead or manager to start holding daily meetings with your team. Second, introduce code reviews, and make sure you or one of the other seniors attend each review.

Ship It! - 5.14 There's No Automated Testing

The biggest complaint that people have about automated tests is that maintaining them is too much trouble. Before you start writing and committing tests, be sure that you have a CI system in place. Set it up to run the tests every time the code changes. If you have test code that you’ve been running manually, port it to the CI system. Write your tests using mock client testing to get the maximum return for each test. It’s too late for you to write a unit test for every method in your code. Mock client tests are more efficient because a single test exercises a lot of code. Identify the tests to write using defect-driven testing This will let you add tests where they can do the most good. Only add a test if there is an active bug there right now. This means that any test you add will address the most current issues in your code, and you’ll get the maximum possible benefit out of every test.

Tip 39: Test where the bugs are

Getting people to use sound engineering practices even for silly old test code is important.  Brittle tests are more likely to get turned off -- which helps nobody.

Ship It! - 5.13 The New Practice Didn't Help

When Not to Introduce a Practice
Don’t try to introduce a new practice or process if there isn’t a problem that needs fixing. Never introduce a change because it’s “the right thing to do.” Instead, identify the actual problems in your shop, and then figure out how to fix them.

Tip 34: Only fix what needs fixing

Tip 35: Disruptive "best practices" aren't!

And of course, make sure the practice or process you’re considering will actually improve things. If it won’t make things run faster and more efficiently, your team won’t (and shouldn’t!) adopt it.

How to Introduce a New Practice
There are two main things you’ve got to do: demonstrate and persuade. You’ve got to get buy-in from several groups of people. First and foremost are the people who will actually be practicing the new practice, namely, your team. If they aren’t excited about it, it won’t matter if anyone else is.

Tip 36: Innovate from the bottom up

Show them the process or tool; don’t just tell them about it. In particular, show them how well it works, especially in comparison with the old way of doing things. The key is to prove that this new-fangled idea is everything you say it is.

Tip 37: Show, don't just tell

Tip 38: Cultivate management buy-in

I've personally done the show-don't-tell tactic and it works.

Ship It! - 5.12 Can't Get "Buy-In" on Essential Points

Sell the new practice or process to the team; don’t just dictate policy. Don’t just preach it; demonstrate it. People respond to a working example more often than to a lecture, no matter how good the concept. Make it easy for your team to change. Give them extra time to come up to speed on the new practice. Get them books or training if they need it. And choose the right time to introduce the new practice or process. Show your team how these practices benefit them personally.

I always had more respect for the lead-by-example type of person.

Ship It! - 5.11 Team Doesn't Work Well Together

• If you don’t already have them, start daily meetings or get your manager to do so.
• Have team members review each other’s code before commits.
• Meet once a week for lunch.

Ship It! - 5.10 Your Manager Is Unhappy

How do you keep your manager happy? It comes down to one word: communication.  Make sure your manager always understands what you are doing and why.

• Use The List and get your manager to review it
• Keep your manager up-to-date with your progress 

Tip 32: Publicize what you're doing and why

Ship It! - 5.9 You've Got a Rogue Developer

This particular problem can be solved only by the manager.

A Manager can:
• Use daily meetings to correct a rogue developer’s course.
• Hold the rogue developer to the tasks on The List.
• Use code reviews and automatic code change notifications to track
  a rogue developer’s work.
• Use CI as a last resort to monitor a rogue developer’s work.

Ship It! - 5.8 Customers Are Unhappy

Get the customer to work alongside you to help define the product while managing their expectations about what’s possible and what’s not. Don’t just get their input at the beginning of the project; keep in touch throughout the development process. So how do you communicate the project status to the customer? One of the best ways is to create a live system that can be used for demonstrations as early as possible, even if the feature set is incomplete. This is true whether the product has a GUI or is a set of application programming interfaces (APIs). Every time your team completes a new feature, add it to the demo program so the customer can see it and give you feedback.

Tip 31: Deliver live demos early and often

How do you communicate with the customer between releases of the demo? Encourage the customer to check The List as often as possible, and keep it up-to-date so they can see it change. Invite the customer into your development world so that they can see your direction and your problems. A customer is more likely to accept a delay if they understand what caused it. Also, encourage them to suggest changes to The List. If they don’t like the way the project is going, they should ask for you to change it. After all, they’re paying the bills. If they frequently communicate their needs and your team continually adjusts the product to meet them, then the end result should make everyone happy.

Ship It! - 5.7 Can't Build the Product Reliably

Solution: understand the build and then script it. Besides increasing reliability, automated builds add a professional finish to your product, ease the transition for new team members, and let you easily use a CI system.

Ship It! - 5.6 It Hurts When I Integrate Code

How do you keep code integration from becoming an ongoing nightmare? The solution is simple: integrate your code more often to reduce collisions and simplify merges. Use a CI system to verify that things still work.
 
Tip 30: Integrate often, and build and test continuously

I used to work with a guy who synced his source area once a month and created headaches for both himself and the whole team.  That is when I learned to do frequent, small integrations.

Ship It! - 5.5 But It Works for Me!

If you can’t reproduce a bug on your own machine, the build machine is your insurance policy. Use it to verify bugs that you can’t reproduce on your workstation. Once you duplicate the bug on the build machine, figure out what’s different on your system. Once you’ve duplicated the bug, craft a test to expose it, and then run the test on the clean box. If you write the test carefully, you can even send it into the field to see if the customer can duplicate your results. Of course, if you can not reproduce the bug on the build machine either, then perhaps the customer has a configuration problem on their own machine. Start asking questions about the environment they’ve set up.

Tip 29: It has to work for everyone

I think it is irresponsible and lazy for developer to give up and say "it works on my machine" but I see it all the time.

Ship It! - 5.4 Tests? We Stopped Using Them

When that happens, it’s time to start again. Perhaps no one was using the tests because they weren’t getting benefit from them. Normally the benefit is immediate and obvious, but there is an upfront cost to get started (or restarted) that you just have to put up with. The other problem you may face comes later in the project’s life. The more tests you add, the more time it takes to run them after a compile. At some point, you may not be able to run all the tests every time. Which tests should you pick to run continuously? Choose those tests that best exercise the code that is being actively developed. When you notice that a test is broken in nightly or weekly builds, move it to the CI test suite so it can be run more frequently.

Tip 28: Continuously test changing code

Until you have a CI environment that builds your product after each code change, you won’t be testing your code often enough. Even a daily build is not sufficient.

I've found that some developers, myself included,  don't use the same care when writing test code that they use when writing production code.  This tends to make the tests brittle and people get pissed when the test code breaks due to some sort of interface change.  It takes some effort but if you can avoid cranking out tests using cut-n-paste then your tests are easier to fix if something changes on you.

Ship It! - 5.3 Features Keep Breaking

What’s the quickest way to fix this problem? Add an automated test suite. A mock client test suite is your best choice to get the product or platform stable as quickly as possible. Mock client tests exercise the most lines of code in the least amount of time.

Tip 27: Mock client tests do the most with the least

Not much to say here other than I know this works, but takes time and effort.

Ship It! - 5.2 Testing Untestable Code

Tell your manager you want to start test driven refactoring. You want to start adding the simple hooks to your application that make it possible (or feasible) to do good automated testing. First, create (or borrow) a test plan for the product. Keep the plan simple at first. Don’t try to make it perfect on your first attempt. Shoot for a simple pass that exercises basic functionality. Second, write an automated test. Make the test go as far as you can. When you get stuck, what’s the least amount you can add to the product’s code to get the test running? Is it just a return code to an existing API or an “id” tag for an HTML field? Don’t try to fix every problem with your first pass. Don’t try to add “id” tags to every page in your product; shoot for the one page you need to get the test passing. If your test plan hits a roadblock, don’t stop. Remove the part of the test plan you can’t test and move on. Remember that you can also add the hard part to your next test plan.

Tip 26: Use test driven refactoring to clean up untestable code

Ship It! - 5.1 Help! I've Inherited Legacy Code

How to tackle this problem:

• build it - First, figure out how to build it, and then script that build process. After that, it should be easy to automate the builds.
• automate it -Your goal is to automatically build and test the entire product on a clean machine with an absolute minimum of manual
  intervention. Document all the build steps and make this documentation publicly available.
• test it - Figure out what the code does, then begin testing by writing mock client tests for it. Once you have the project building cleanly, you’ll want to confirm that it works. In order to write the tests, you’ll have to learn exactly what the product is supposed to do (no surprise there). Mock client tests are a good starting point: they test the broad functionality of a product because they act just as a product user would.
• test it more - Figure out the product’s innards (things such as structure, flow-of-control, performance, and scalability), and write more tests for it. Unless the product is completely unused, there will be bugs you’ll need to fix (or at least document) or enhancements you’ll have to make. Normally these changes are a pretty scary thing to do to legacy code, because you’re never quite sure what you’re going to affect when you make a code change. But you can do this fearlessly because of the mock client tests you wrote as a safety net; they’ll keep you from breaking things too badly. Write a new test for every bug you fix and for every enhancement you add to the product. The type of test you write will depend on what you’re changing (e.g., a unit test for a low-level internal change, or a mock client test for a new feature). At this point you’re treating the legacy product in the same way you would any other product you support.

Tip 25: Don't change legacy code until you can test it

I find that testing a new code base forces me to understand the system.  I suppose the added benefit of writing tests for known bugs forces me to understand the defect tracking system as well.

Ship It! - 4.8 Selling Tracer Bullets

The primary benefits of TBD are:

• teams can work in parallel
• can see a working system earlier
• momentum, people like to make progress
• testing can begin just after the interfaces are defined
• easier to move people between layers because they have a basic understanding of what each layer is supposed to do

TBD Sequence:

• propose system objects (layers)
• propose interfaces
• connect interfaces
• add functions
• refactor, refine, repeat

Tip 24: You can't steer a boat unless it is moving

The main idea behind Tip 24 is that if your development progress is slow, you won't get timely feedback making it difficult to correct course.

How to Get Started:

• try it out
• discuss the concepts with the team first
• define system objects
• define interfaces between them
• write the interface stubs
• make the stubs talk with each other
• fill in the stubs with functional code

You Are Doing It Right If...

• the entire system is always up and running
• team members understand the system objects as well as "their" objects
• team members feel comfortable helping out wiht other system objects
• you can rewrite large portions of your code base and nothing breaks

I really like the idea of TBD.  I've operated in a similar manner on small projects just to see how stuff would "hang together" and enjoyed the process.  You run across stumbling blocks sooner and it feels good to have a working system that you can demo at a moments notice.  I'm curious to see how it functions on a larger scale.

Ship It! - 4.7 Refactor and Refine

As your teams add real functionality to their stub code, they will discover that one interface needs an extra variable passed in or that another interface was missed entirely. You can add this functionality at any time. When you make these changes, publicize them so that other teams that use the same interfaces won’t be surprised. If need be, just add a new interface with the extra variable instead of pulling one out from under another team. Remember that you never break the builds in a tracer bullet project. Any code that you add should extend the system, not break it.  You will also realize at some point that code you’ve written needs to be thrown out. Maybe the code is too slow or it returns the wrong results. Any one of a thousand things may be wrong with it. Feel free to completely refactor or rewrite code, as long as the interface still works the same way. You can make these changes at any time in a Tracer Bullet Development project. The rule is that you can’t change the interface that the other teams use without consent, but you can change the code behind those routines at will. As long as the interface works the same way, the other teams won’t be aware that you’ve changed the code. Their code should still use your interface the same way, only now it runs faster or returns the correct data.

Tip 23: An encapsulated architecture is a scalable architecture

I'm thinking that the term "scalable" refers to the number of developers that can productively work on a system, not how much additional load it can handle.  If the touch points are well defined you can have one or many developers working on a layer and the other parts of the system won't know or care.

Ship It! - 4.6 Fill In the Stubs with Fuctional Code

You now have an end-to-end working system. Every piece can talk to each other, and all the code compiles and runs. It’s time for you to start making it do real work. Even as good fences make good neighbors, good interfaces make for good team interactions. Each team can now work in complete isolation if necessary and can start to fill in the logic behind each interface. Each of your teams now has a basic framework that they can begin to fill out. You can do whatever you like, as long as you don’t break the existing interfaces. No one can change APIs between layers unless both teams agree.  Don't implement the simple stuff first. Instead, target any area that contains new technology, is inherently difficult, or is core to your product.

Tip 22: Solve the hardest problems first

Use The List to prioritize.  Do not let the system break aka Don't leave Broken Windows. 

It seems to me that in order to prevent breakage of the system, you need to have automated builds and tests in place.  If you have notifications of when people check stuff in, you can probably get an idea of what the "other guys" are doing without requiring lengthy status meetings.

Ship It! - 4.5 Make Your Layers Talk

Now that you have completed your stubs, you’re ready to start making them talk to the other layers in your system. That may not sound important, but you’ll be surprised how many seemingly insignificant details will not work together the way everyone thought they would. Once you start adding callbacks, using different CORBA vendors, and trying to use Java RMI on different network subnets through firewalls and the like, it’s a whole different ballgame from “Hello, World!” As every team puts code into their stubs to access the other layers, they are proving that every technology involved actually can inter-operate. Will the customer run part of the system behind a firewall? Then you should too!

Tip 21: If production uses it, you should too

Be sure that your hollow shell works end to end before you invest time to make it do the real work.

Your project now has the following:

• a complete, documented architecture
• a POC that shows your architecture works.  You can make a client invocation and see it run, end-to-end.
• clear boundaries between teams
• clear demarcations between areas of product functionality
• experience meeting with the teams responsible for adjacent code layers. 

Having all your teams talking with each other is a huge benefit and getting the layers to talk is one way of doing that.


I've experienced first hand the pain that integrating layers that should "just work" can be.  I think the idea of wiring up the layers early is a good one.

Ship It! - 4.4 Write the Interface Stubs

This is the easiest part of the project. Remember to keep everything as simple as possible. The goal of an interface is to be just thin enough to compile and be used. Be sure to finish one pass at all your interfaces before you insert code that adds functionality. Resist the temptation to start coding something easy.

I'm wondering if they advocate Test First development here?  I'm thinking that part of defining a workable interface is defining a testable interface.  Hmmm....

Ship It! - 4.3 Collaborate to Define Interfaces

The teams working on adjacent layers meet, and together they flesh out the interfaces that their layers share. If you know that the client application needs to log in, then you know that a log in call must exist in the web server layer. The teams collaborate and come to an agreement on the method names and signatures. You then code each method but return only canned data. In these meetings, you begin to define how the layers will communicate with each other. Your teams flesh out such details among themselves so that after this meeting (or as many meetings as it takes), everyone involved knows and understands the interface points between each layer. The best architectures aren’t defined by an “architect” in an ivory tower; they are collaborative efforts. Instead of having a guru drive by and drop a completed architecture document in your lap, your team works together, leveraging and increasing everyone’s experience.

Tips:

• Always have a single person lead your meetings. This person always has the floor and must “give permission” before anyone can speak. Having a single person lead the meeting will help prevent the meeting from turning into a shouting match.
• Record notes on a white board throughout the meeting. With the information on a white board, everyone can see what method signatures you’ve agreed on in real time. If you take notes on paper, inevitably someone won’t see what you’ve written.
• Andy Hunt suggests trying using LEGOs or wooden building blocks for the objects in your system. You help the more junior members understand the system and the relationships between the different objects when you give them something tangible to see and touch. Sometimes the intangible nature of our work makes the system components difficult to visualize and understand. Whether you draw objects on the white board or move blocks on the table, have a visual or tactile representation of your system.
• Record the interfaces and publish them. You can use a printed document, a web page, or a wiki, but regardless of what medium you use, you must make the information publicly available. The last place you want to keep secrets is an object’s interface.
• Hold your meetings where you won’t be interrupted. You want to minimize the number of times you have to shift gears and answer questions.

Tip 20: Architect as a group

I'm thinking that a poor man's CASE tool, aka cheap digital camera, is a nice way to document the group's thinking.  I can't picture in my head, however, how I could use blocks to convey a software architecture.  I must do a bit of digging to see what I can find on the topic.

Ship It! - 4.2 Define Your System Objects

Your first step is to identify the layers into which your application can be divided. You want to be careful not to define lower-level objects. Be sure that each system object you define can stand alone. If you can create an object with clean lines of separation from other parts of the system, then it can be a system object. By keeping these objects as large as you can, your teams will be able to work independently for longer stretches of time. A system object must be large enough to justify a person or team working alone for some length of time. You also must be able to create a clean line between each system object. Think of your server objects as pots and your development teams as cooks. Sure, if the pot is big enough, everyone can stir in the same pot. It’s a lot easier if everyone has their own pot. A different development team works on each layer, and each team assumes that their layer exists on a different computer. This means that all communication between layers is over the network. Prevents "cheating" by accessing the implementation directly and allows for scaling because you can move a layer to a larger machine.

I like the idea of defining layers early but I've become comfortable of thinking in terms of the Port and Adapters architectual model.  Can that be used in TBD? I'm thinking yes because each Port is a layer in TBD.  I do think you might have to temper the "assume each layer is on a different computer" rule.  For example, many systems I've worked on had the persistence layer baked into the core.  One reason is to more easily allow for database transactions to span all the logic it needs to.  I'm not sure it makes sense to place additional complexity into the system to make transactions span processes.  

Ship It! - 4.1 Defining Your Process

This chapter is about a development process based on the Tracer Bullet idea put forth in The Pragmatic Programmer: From Journeyman to Master.  I look forward to exploring their ideas.

The practice of Tracer Bullet Development (TBD) lets you see where things are headed as soon as you start and helps you aim continuously long before you’re done.

A process must answer the following:

• Does it work for you?
• Is it sustainable?

Beware any process or methodology that claims to be the exclusive solution to every problem for all projects. This magic cure-all is just modern snake oil. Embrace a methodology that encourages periodic reevaluation and inclusion of whatever practices work well on your project. Be sure your process is a flexible one—don’t be afraid to change or adjust your process to see if a new, better practice can fit in. If you have a new idea, drop it in for a few weeks. If it works out, great! Make it a permanent addition. Otherwise, revise it or get rid of it. This experimentation is how you’ll find out what fits your shop the best. There are no sacred cows in a good process. Anything that works well can stay; anything that isn’t working must be removed or revised.

Tip 19: The goal is software, not compliance

How Does It Work?
You create an end-to-end working system when you use TBD, but the system components are all hollow objects. You write code for all the big pieces of your system, but the objects aren’t doing any work. Your database access layer returns data, but it’s really returning canned data, not data from a database.

Identify the major parts of your project, and divide your product into blocks of related functionality. For example, you might have blocks called client, web server, and database layer. Define the information that the blocks need to exchange and document the information with method signatures. These areas of layer interactions are called interfaces. Give each block to a different developer, team of developers, or corner of your mind (if you’re working solo). Write just enough code to make everything look as if it works. Think of it as an entire application of Mock Objects. With this thin, skeletal framework in place, you can begin to fill in the real logic inside each block. Finally, and most importantly remember that interfaces will change and evolve throughout the project. Your first shot will always miss the target, so be flexible and adjust your aim at any point. When another team approaches you for new interfaces, or to make changes to existing ones, go ahead and make the change. This is software, after all.

I've done a form of this and we called it "spiking the architecture".  I found it to be useful because you can't anticipate some issues until you starting manipulating code.  I don't think "big bang" development works so TBD might be a useful tool for me.

Ship It! - 3.6 Putting It All Together

This chapter is a summary of stuff we've learned so far.

The List

• publicly available
• prioritized
• on an estimated time line
• living

Tech Lead

• manages project's feature list
• tracks developer's current tasks and status
• helps assign priorities to each feature
• insulates the team from external distractions

Daily Meetings

• keep them short
• require specifics
• list problems, but don't solve them

Code Reviews:

• small amount of code reviewed
• one or two reviewers
• happen frequently
• don't publish code without a review

Code change notifications:

• email and publish notifications
• list the reviewer's name
• list purpose of the code change or addition
• include the diff or file itself, size permitting

Ship It! - 3.5 Send Code Change Notifications

When you edit code, an automatic build system can notice the change and rebuild the project. Your next step is to publish that information so that every member of the team knows what changed. A change notification system pushes this information out to your entire shop, not just your immediate co-workers. The preferred way is to have your changes automatically emailed to each team member. Most automatic build systems will send changes for you (and they’ll usually publish your changes to a web page and RSS feeds as well). Change notifications should go out to your team each time code is checked into the source code management system.  Notifications should include:

• Reviewer’s name.
• Purpose of the code change or addition (for instance, which bug you’ve fixed or which feature you’ve added).
• Difference between the new code and old code (Any major source code management system will generate this report for you.) If you’ve completely rewritten a block of code so large that it would make a diff meaningless, just include the new code. The same applies to new files.

How to Get Started:

• A program that watches your SCM generates notices and sends emails.
• Make sure your team knows about the notifications before they start arriving.

You're Doing Right If...

• Notifications must be regular and trustworthy.
• Don’t send out five-megabyte diffs!

To make this work you would need to customize your SCM a bit.  You'll need something to trigger the CI server when a commit occurs.  You'll also need to put something in that verifies that the requisite data is in the check comment.  One question I have is around the volume of information that could be generated.  Changes to one branch of the code might be okay but what if there are multiple branches?

Ship It! - 3.4 Review All Code

Can be painless if:

• Only review a small amount of code.
• There are one or two reviewers at most.
• Review very frequently, often several times a day.

To avoid MAD (Mighty Awful and Dreaded) reviews, separate your work into the smallest possible pieces and get each one reviewed independently and committed into the source code repository. Then if there’s a problem with any one area, it’s easily isolated. A good rule of thumb, however, is to never work for more than two days without getting a code review. Ideally there will be one review for each feature you add (or for each bug you fix).

Tips:

• Code reviews must involve at least one other developer. 
• Do not make code publicly available without a review. Don’t add your changes to the source code from which your product is built until a review has been done. Part of the comments you include with the code’s check-in should list your reviewer’s name. Then, if there are questions about the reason for the code change and you’re not around, there is a second person who should be able to explain it (at least at a basic level).
• Never use this code review rule as an excuse to not check in your code. If your company has a source code system that holds only production code, then put your code into a private area until it’s ready. This private area might be a separate code repository or another installation of the source code management system. Use whatever tools you need to get the code off your machine so that when your machine dies (as machines are prone to do), your code doesn’t die with it.
• Reviewers maintain the right to reject code that they find unacceptable.  
• If your code can’t be explained at a level the reviewer can understand, then the code must be simplified. As a reviewer, don’t sign off on anything you don’t understand and feel comfortable with. After all, your name is associated with this code as the reviewer.
• Any code changes that are made can’t break any existing automated tests. Don’t waste your co-worker’s time asking for a code review if you haven’t yet run the tests. If you require existing tests to be updated, make the changes to those tests a part of the coding before the review. Any new tests that you are adding should be a part of the review as well. As a reviewer, always reject code changes if you think more tests are necessary.
• Rotate the reviewers you use, but don’t be religious about it.
• Keep code reviews informal.
• When you introduce the code review process, you may need to appoint a few senior team members to be the mandatory reviewers; one of the senior team members must participate in every review at first.

Tip 17: It's okay to say "later"

Your management must require code reviews. If there’s no management buy-in, no one in your shop has any official motivation to participate. In other words, if no one has been told to help you, they probably won’t make time to do it, especially when deadlines are tight.

Tip 18: Always review all code

How to Get Started:

• Be sure everyone understands the type of code review you have planned. Review frequently on smaller blocks of code. Don’t wait for weeks, accumulating hundreds or thousands of lines of changes. No MAD reviews for your team!
• Have one of your senior team members sit in on each code review for the first few weeks or months. This is a great way to share knowledge and get the reviews on a solid foundation.
• Make sure your code reviews are lightweight. It’s better to review too little code than too much. Having two overlapping reviews is better than having one larger one.
• Introduce a code change notification system  at this time. It’s a great complement to your code reviews, and it helps to remind team members who forget to ask for reviews.
• Make sure you have management buy-in before requiring all team members to participate. 

You're Doing It Right If...

• Do code reviews get an automatic approval? This shouldn’t happen unless everyone on the team is perfect.
• Does every code review have major rewrites? If so, it indicates a problem somewhere: either with the coder, with the reviewer, or with the tech lead (who gave the directions that the coder and reviewer are using).
• Do code reviews happen frequently? If the time between reviews is measured in weeks, you’re waiting too long.
• Are you rotating reviewers?
• Are you learning from the code reviews? If not, start asking more questions during your code reviews.

Wow.  I'm thinking code reviews is an area where there will be much resistance.  Only one of my past shops did code reviews and I can't even remember if it helped quality.  I do remember, however, people getting pissed because they couldn't check in their code in time for a build due to a failed review.  They got angry because the coder disagreed with the reviewer that the code should not be allowed to go in over a "minor" issue.  I'm wondering if automation can be of any help here?  There are tools that can check for silly code style violations, like where the curly braces go, which might lessen the reviewer's load.  There are also tools like FindBugs that can detect threading issues which, again, might lighten the reviewer's load.

One thing I'm wondering about is how to avoid checking in code without a review, especially when working with remote developers?  Do I keep my own branch that gets merged with the trunk every day?  I could check in my proposed change into the branch, have it reviewed and then merge it into the trunk if it passes inspection.  E-mail the files? Are there other techniques?

Ship It! - 3.3 Coordinate and Communicate Every Day

Each team member briefly shares what they are working on and what problems they’ve run into. A good rule of thumb is to spend no more than one to two minutes per person. Remember that this meeting has the entire team tied up, so be mindful of the burn rate; keep it short and to the point.

Tip 16: Use daily meetings for frequent course corrections

How to Get Started:

• Be sure everyone knows the format (which questions you want answered).
• Everyone must answer the questions. There are no passes, and no exceptions.
• At first, be lenient on the time restriction. A lot of new information is exchanged in the beginning, so you must allow communication to flow freely.
• Hold your meetings at the same time and in the same place, every day. Make daily meetings a habit, not a chore to keep track of.
• Post topics that are discussed during daily meetings on a web page  or plog (project log).
• Pick a person to start the meeting, and then move clockwise (or counterclockwise) through the group. Randomly picking one team member after another is more apt to make them feel ambushed. 

You're Doing It Right If...

• Are the meetings useful? If no one in the group is learning anything, the reports might be too terse. If more details are needed in a particular area, push those topics into a side meeting with a smaller group. However, the two-minute rule is a guideline, not a law. You may find thirty seconds is just fine, or you may need three minutes.
• Are meetings consistently held the same time and place every day, or do they fluctuate? Having daily meetings at the same time and place makes it easy to remember. Meetings can move occasionally, but avoid mixing things up frequently.
• If you stopped holding the meetings, would people complain? They should! The team should come to depend on the daily meeting to stay “in the loop.” If the meetings can be dismissed, then they weren’t providing value. The team should rely on the daily meeting as an invaluable resource.

I've never participated in daily meetings but I have worked in environments where people worked in a vacuum.  I'm thinking short, daily meetings is the way to go.

Ship It! - 3.2 A Tech Leads

Your Tech Lead both oversees and carries the technical responsibility for your software project. Having a Tech Lead frees up your manager to handle bureaucratic matters while delegating the technical aspects to someone who’s better equipped. A tech lead does the following:

• Make sure your team’s work priorities are in line with customer needs
• Ensure that your team’s work is properly represented to management
• Insulate your team from non-technical upper management
• Relay technical issues to nontechnical stakeholders
• Present nontechnical concerns to the development team

Tech Lead's Responsibilities include:

• Set direction for team members
• Orchestrate your project’s feature list
• Prioritize your project’s features
• Insulate your team from external distractions

Priorities Defined:

• P1 - Required. These are the features that you absolutely cannot ship without.
• P2 - Very Important. You could ship the product without completing these items, but you probably won’t.
• P3 - Nice to Have. Given time, you will complete them, but these items never delay a ship date.
• P4 - Polish. These items add a finished feel to your product.
• P5 - Fluff. If you have time to add “fluff” features, then you are ahead of schedule and under budget.

Tip 15: Let a tech lead

If you aspire to be a Tech Lead, you need to prove you’re ready to handle the additional responsibility. Look over the job requirements, and strive to live up to them. Voluntarily perform as many of the tech lead duties as you can. Don’t wait for the job to fall into your lap; demonstrate that you are trying to earn the position and can handle it well.  Use The List  for your personal work but also keep one for your team. Monitor work in progress while keeping an eye on upcoming projects.  Evaluate your team’s process. Locating the weak spots and finding practices or concepts to address problems will give you a new perspective. Don’t give up if you aren’t promoted to tech lead right away. Continue learning and growing for the next assignment. Not everyone has the temperament for a tech lead role, but working toward it gives you a broader picture of the entire project, which makes you a more productive team member. You become a better developer by thinking about and considering how you’d be a tech lead.

If you’ve just become a tech lead, create a rough road map. Chart where the team currently stands and the direction you want them to go. What problems will you address? What work will you encourage? Make a list of all known problems. Then survey the team to see if they know about additional problems. When you think you’ve arrived at a real list, decide which items you can address and which you can’t. Daily meetings are a great way to keep track of your team’s work without smothering them.

You're Doing It Right If...

• Do you know what every member of your team is working on?
• Can you generate a project status summary in less than five minutes?
• What are the next five to ten features for your product?
• Can you readily list the highest-priority defects for your product?
• What was the most recent problem you cleared up for a team member?
• Would a team member come to you if they needed an important issue resolved?

Ship It! - 3.1 Work from The List

The List is how you set your daily and weekly agendas. You order your work with The List, as does the entire team. When you get swamped, overwhelmed, or scattered, you come back to The List and use it to regain your focus. If you get stuck on a tough problem and you need to step away for a while, The List gives you a readily available set of items to use as filler. This ensures that you’re working on the most important item, rather than the proverbial “squeaky wheel.”  Since all developers are at different skill levels, the tech lead makes exceptions as needed, but generally, no second-priority item can be touched until the first-priority items are complete. The List (as a team tool) gives management and customers something concrete to look at and evaluate the product before the time is invested adding the features.

Tip 14: Work to The List

Getting started with your own copy of The List is easy. First, create a list of every task you are working on (or have pending). Then, with your tech lead, assign a priority to each item. Finally, put a time estimate with each item. Don’t worry about getting the time estimates perfect the first time, you’ll improve over time.

For the team:

• Put every feature that you are adding to your project on a white board
• Assign priorities to each feature. Be sure to include the proper stakeholders (management, customers, etc.) in this process.
• Rewrite all of the features, sorted by priority
• Attach time estimates to each item

Until the current top priority items are completed, no one can work on the lower-priority items. This ensures that all the priority-one items are in progress before any of the priority-two tasks are touched.

The List must be:

• Publicly available
• Prioritized
• On a time line
• Living
• Measurable
• Targeted

How to Get Started:

• For an entire day, write down every task as you work on it (this will be your “finished” list).
• Organize whatever daily task list you do have into a formal copy of The List.
• Ask your tech lead to help you prioritize your work and add rough time estimates.
• Start working on the highest-priority item on The List—no cheating! If some crisis forces a lower-priority item higher, record it.
• Add all new work to The List.
• Move items to your finished list as you complete tasks (this makes surviving status reports and “witch-hunts” much easier).
• Review The List every morning. Update it whenever new work pops up. . . especially the last-minute crisis tasks; you’re likely to forget about those when someone asks you what you on earth you did all last week.

You're Doing It Right If...

• Is every one of your current tasks on The List?
• Does The List accurately portray your current task list?
• Did the tech lead or customer help you to prioritize The List?
• Is The List publicly available (electronically or otherwise)?
• Do you use The List to decide what to work on next?
• Can you update (and publish) The List quickly?

I'm a fan of lists but have never used them in this way.  I can see the benefit of getting my manager to help me prioritize things and it should be able to help keep an entire team on track.  My question is this: what is a good tool for making The List?  Is a wiki with RSS publishing good?  Is a white board good?  Project planning software?