Build a reputation of delivering on time. Whether it’s an important part of the culture at your company or not, you should deliver on time. This is almost a personal thing for me – if you commit to something by a certain time, finish it by that time. I’m not going to talk about why delivering on time is important (hopefully, that is obvious), but I will say this – think of it as disrespectful to others who are dependent on you.
The first part of delivering on time is to plan and commit to deliver a reasonable amount of work. You should be able to perform estimations without having to break down a task into Fibonacci hour increments, without defining story points, and without voting and obtaining consensus on these time estimates. My team and I have bypassed the meetings used for time-estimation and tracking steps for years, on several projects (including new projects that we knew little about) and delivered on time, every time. I’ve seen daily stand ups and burndown charts in action and with it I’ve seen teams and projects strictly follow Scrum processes and *still* fail to deliver, repeatedly! If you can’t divine that you’re behind schedule unless you have a burndown chart, the problem is that you don’t understand the project and people well enough. Get to know your team, the project, and the features to be delivered, and you will know with better accuracy your team’s status compared to any burndown chart.
As a team, tackle the most important features first giving priority to those tasks that require cross-team interaction and leave features that are fully in your domain toward the end. You do not want to fail to deliver something because some other team was late. I’ve seen many burndown charts that are on track all the way until the end. Engineers have a weird tendency to please, so they will pick off easy tasks so they can claim progress at every daily standup, but by the end of the sprint, the big task is left unfinished. Also, engineers have a weird tendency to complete the task that’s fully in their domain, that they have full control over, before interacting with the other teams. Do exactly the opposite – attack the big tasks with a lot of cross-team interaction first.
The inevitable happens, the deadline approaches, and you aren’t quite on schedule. What do you do? First, hopefully you’ve instilled a culture of delivering on time within your team. This culture will create diligence and hard work ethics throughout the sprint, rather than just at the end – thus these events should be rare. Second, most engineering work schedules are flexible. Deliver on time by working late and weekends if necessary. Because of the flexible work schedule, let your team know that if you work late for several days, after delivering the product, take Thursday and Friday off and enjoy a 4-day weekend. Don’t demand your employees to work more than 40 hours per week, but do require some flexibility in work hours to ensure on time delivery.
In sum, make delivering on time a priority. Understand the project and what is needed to succeed. This is superior to relying on Scrum-like processes to estimate time and track progress (while I deride Scrum specifics, I am an ardent proponent of Scrum principles). People love the comfort that a rigid process provides (it makes it feel like the team knows what they’re doing) and there is a stigma in the industry for not following Scrum-like processes of time estimation, time tracking, daily progress reports and status updates – do these if they help, but they are not a panacea to quality and delivery. Remember, the important thing is the end result and delivering quality to the customer. Make on-time delivery ingrained as part of your team’s culture. Don’t let down those who are dependent on you. Make delivery a priority and in the end, perhaps not only will you deliver on time, but ahead of time.