One of the biggest problems struggling development teams have is shipping code. Most projects seem to have the same story of why they are late. Lots of planning and requirements gathering is done ahead of time to set the team up. The project starts off running smoothly and all the metrics are hinting that the project is on track. Confidence is high among the team and the managers are happy. Once you get to close to the 80% mark, then the progress starts to slow down. The last few tickets or a large bug end up taking 4-5x the estimated time. As a result, the deadline is missed. Missed by a mile.
This pattern where the last few issues of a project taking up a large portion of the work effort is common. There is always one bug that needs to be fixed or one feature that is a business owner wants to add. It is easy to find excuses to not ship code. This anomaly, where 20% of the project requires the most amount of effort, is known as the Pareto Principle. Development process like Agile and Lean have sprung up as a direct result of these challenges. Many companies are now familiar with the term MVP to release early and fight off scope creep.
I have found that process, no matter how much or how little, is unable to solve this problem of meeting deadlines. HauteLook uses two Agile methodologies: Scrum and Kanban. We have given multiple presentations on what MVP means. None of it has been as effective as increasing the amount communication among team members. When a team is communicating well they are implicitly working together. They are much more effective at problem solving and cutting through red tape. Communication also increases the sense of ownership over a project amongst the team members. When someone is included in a team discussion they feel like they belong. There is a sense of camaraderie. They are now much more likely to participate in future discussions and take initiative.
You can usually tell the difference between a team that communicates and a team that just goes through the motions by watching the daily stand-up. A team that is not communicating will usually be giving a status report to the scrum master. As each person gives their status update the other team members are zoning out because they are not sure what that person is really talking about. You will notice members of the team checking their phones or staring off into space. A team that communicates will be giving updates to the other team members, not the scrum master. A communicating team is engaged and they are making plans to fix any blockers that come up. There is a sense of urgency.
One of the best ways to facilitate an increase in team communication is to remove process. I first looked to our tools. We use JIRA at HauteLook to track the progress of sprints. It is very easy to add a lot of process to JIRA and think it will increase team efficiency. It is usually just the opposite. Too often process gives people a false sense of security that the process itself is going to solve the problems. Process does not solve problems; people do. When I am leading a team, a ticket is not ready for QA when a JIRA status is changed. A ticket is only ready for QA when the developer contacts the QA people on the team and informs them the ticket is ready. This communication can take place over email, but I encourage a more personal form of communication (in person, phone or instant message). The difference is that when a person changes status they are not expecting any feedback. They place the responsibility on the “process” working. When a person reaches out to another person they are expecting an acknowledgement of some sort. This sort of common interaction among team members creates a positive foundation and allows them to hold each other accountable in a constructive manner.
I double down on intra-team communication when a project is approaching the deadline. It is too easy for some people on the team to feel like they are done with the project when all the issues assigned to them are complete. When someone feels that sense of accomplishment they do not want to have to circle back to work on the project more. That news often comes as a surprise to them and now working on the project feels like an extra burden. By continuing to communicate with every member of the team on what the overall status of the project is they are much less likely to get that false sense of accomplishment. Instead, they are more likely to participate in dragging the project over the finish line and meeting the deadline as a team. Then, and only then, do they feel a real sense of accomplishment.