Short, short deadline sprint rules for success

Imagine this situation, its 24 hours before a very important deadline and your project isn't ready. But you must show some progress to the client, something anything to stop them from stopping the project and turning to someone else. What do you?

I've been caught in this situation several times already this year, and will in all probability caught again, and its not easy or simple to handle. For each project I was a technical lead, and the responsibility to actually do the task by the deadline fell to me.

The following rules helped me:

1. Cash in your relationship chips , you'll need them to motivate your people and make them buy in the effort required of them.


2. Write a task list of all tasks needed to be carried out in order to successfully meet the dead line, and then filter it out to the bare essential. It's time for brutal reality, not Christmas wish list making.


3. Take the core, the most difficult and most important stuff on your self. They made you a technical lead for a reason. Now is time to earn it.


4. Distribute the remaining stuff to each team member according to their capabilities and aptitude.


5. Make sure no one introduces new (or reopens) new defects into the system. Test the core twice before committing. Break heads if necessary. It's not the time to create more work.


6. Do not commit unfinished work. It either is done, or it isn't. Only pure 100% completed and tested changes go into the repository. Make sure everyone is on the level with this.


7. Do standups every four hours in the first twelve hour period, then switch to two hour standups for the remainder of the sprint. Track only completed, not completed progress on the created task list. Look for problems, and replace people who got tired or the tasks assigned to them are to difficult to handle. Pair programming was proven effective in both cases.


8. On achieving all (or the majority) of the planned task code freeze the repository, and label it as such. Do not allow anyone to commit now unless its a critical defect fix you personally authorized. Break heads if necessary.


9. After the code was freezed, test everything on your machine. If everything checks out label the code in the repository as such.


10. Publish the product to the production environment and then check it there once again. If everything checks alright, go home to your family for a head bashing for spending 24 hours on work while your kid won he's first soccer prize (or similar). Be proud of your self for achieving something great and meaningless.

The following rules(principles, steps) work because there is a clear scope of the work to do in a very short amount of time. Everyone is clear on the importance of the work to do and what is the price of failure.

The two most important thins are frequent standups and the written, prioritized task list. Why? Frequent standups remind everyone one the goals and the principles of the work to do. They allow faster knowledge sharing between team members and allow you to get a clear view of the progress achieved thus far, of the problems had and allow you to frequently react to those problems in order to remove the impediments thrown in front of the team.

Remember in the end everything falls to you. You must be the leader, the one that starts first and goes home the last. The one that pushes the code to the production and says is done. At four am there is no one else. Its your responsibility to sleep for two hours and show to work to check if everything is OK with the business people showing the product to the client.

You are the hart and soul of the team. You must show firmness and clarity of vision and command, you must be supportive because without them you are nothing . You are your team, and they are yours for good and for worse.