August 14th, 2020
Hello friends. In this article, I will outline five ways to ensure your development team meets their delivery schedule. This article follows on from How to assess a development team, where I described five measures a manager could use to evaluate the overall health of a development team. Delivering software is one of the most important tasks undertaken by the team for obvious reasons, so it is critical they deliver on time and to a high quality. So with that, let us get started.
The Engineering team that develops the software you use are a great bunch of people. They produce great software and are very attentive to their users. They always are keen to understand how they can assist the business, and they never say no to a great idea or to offer help when someone yells out. Sounds great, doesn't it? The only issue here is that they never ever hit any of their delivery schedules. Sometimes the delays are small only a few weeks or a month at the most, however sometimes the delays can stretch for 6 months or more. When the team consistently misses delivery timeframes, it is a pretty good indication that they have some severe issues to address. So let us dig into what could be going wrong here.
There are numerous reasons why teams miss their delivery schedules. I won't cover any that are outside of our control, such as natural disasters and the like. We will only cover those items which are mostly self-inflicted either from the team itself or the business, these include but are not limited to:
The team doesn't fully understand the requirements
It can cause costly rework and delays when essential requirement are misunderstood or missed entirely. If the delivery team doesn't fully understand what is required, it can have a knock-on effect on the remainder of the project. Incorrect assumptions about, the time/resources needed to deliver, the technical considerations of the delivery and the amount of risk involved in making these changes to the software can harm the final delivery schedule.
The team doesn't have input on the delivery schedule
When the delivery team have deadlines thrust upon them with no consultation, it has a demotivating effect, with engagement on meeting the deadline being the first causality. Besides, without the ability to provide input on the delivery schedule, the team is unable to point out any problems which will make that deadline challenging to meet. In short, the delivery schedule that is arbitrarily assigned from up on high is doomed to fail.
The team get sidetracked
Another major issue for delivery is when the delivery team get distracted onto different tasks and loose track of the delivery schedule. Time is the only resource that you cannot buy more, so once it is gone, the team miss their delivery schedule and fall behind. If all the tasks associated with the project are not tracked carefully, the delivery schedule is put into real jeopardy. No matter the amount of heroic all-nighters the team puts in at the last minute.
The team run into technical issues which cause delays
Many software projects have been ruined by technical problems, and this still remains one of the main reasons for software delivery over-runs today. Technical issues can range from performance issues to device compatibility or glitches when the software is under load. Whatever the technical problem they can all harm the delivery schedule. Technical risks should be fully considered by a dedicated person, so the appropriate level of design thinking can take place to ensure these don't hold up the project.
Things always fall between the cracks
No matter what the team does, there are still things that get overlooked and forgotten. Whether this is the user documentation, writing unit tests, load testing or deployment documentation, these forgotten items can delay a delivery project when they have not been completed. How can a missing piece of doco delay a project you ask? If you work in an organisation that has multiple departments responsible for distinct areas, you often need to define the interoperability between them. This usually comes in the form of handover documentation or checklists. If the criteria for handover is not met, eg. End-user documentation updated or penetration testing complete and passed, then the final phase of the project deployment could be held up until this takes place. Regardless of the item, the delivery team must have a formal methodology in place to ensure all the I's are dotted and T's crossed.
OK, so let us get into our 5 ways to ensure our engineering team deliver. Now, of course, there is no silver bullet and projects can still go off track, but by following the below methods will provide a better chance for the team to deliver.
1). Ensure requirements are clearly defined and understood
It is essential to ensure that the requirements (functionality) are clearly defined and understood by the team. Having a set of clearly defined requirements may sound like a basic task, and you would be right. However, two factors complicate this task immensely; these are Detail and Communication.
The devil is in the detail
The old saying is very true that the devil is in the detail. When developing software, this is doubly true, with small items having a significant impact on the end result. If all details have not been fleshed out and captured, it could cause costly rework to correct downstream. The costs of fixing an incorrect specification are much less than fixing a broken piece of software towards the end of a project. A perfect example here would be the omission of a non-functional requirement around response time. A failure to mention that a routine needed to complete in less than 1 second could see the developers taking a different path in development that while being easier to complete could never yield the sub 1-second results the business required. Such a mistake could result in the entire routine being re-written to perform as needed, a very costly mistake indeed.
Communication is what the listener does
This quote was from Mark Horstman (Manager Tools) who originally was inspired by Peter Drucker, the great management consultant who basically invented modern management practice. Fundamentally the person speaking just utters words, while the person listing is the one who perceives them and gives them meaning. This is very true of software requirements. The business can have detailed business requirements, however, if these are misunderstood or misinterpreted by the engineering team, then the wrong requirements will be implemented, and the delivery schedule missed. It is important to remember that software development is very much an international affair with developers hailing from all parts of the globe. It is not safe to assume English is the first language spoken, so it is essential to ensure the requirements and more importantly, the intent of the requirements are understood.
How to get here
2). Set delivery schedule carefully with input from the delivery team
The best way to obtain an accurate estimate of when the project, release or bug fix will be ready is to ask the people that do the work. Of course, we have situations where the business needs to address a critical business need that was totally unexpected, and a key date is an absolute line in the sand. This is especially true of regulatory changes which generally cannot be delayed. However working out the details with the delivery team is still the best way to get a good outcome, with the team being able to advise on delivery timing and phasing to get the project completed on time.
To determine how long the project will take to complete, we need to add together the duration of the time it will take to deliver each individual piece. The delivery timing may be long or short, depending on the amount and type of work to be delivered. The delivery timing may also be impacted by holiday plans and other projects that the team needs to support. The delivery team can advise of all these various factors which would affect the delivery schedule and also use the information gleaned from the project inception to estimate on time to deliver the functionality required. Now depending on the length of the delivery schedule, the business may need certain work items delivered first to keep their required timelines. This is where delivery phasing comes in.
Delivery phasing is where we break up our overall delivery into smaller chunks which we deliver gradually until the full scope has been delivered. Delivery phasing enables the business to get software quicker than usual and complete their acceptance testing and deployments. Delivery phasing is a significant lever to pull if you don't have enough time to complete the full delivery scope, enabling the team to deliver value in an orderly fashion without feeling rushed to meet an impossible deadline.
How to get here
3). Set regular milestones to demonstrate progress
One of the leading killers of delivery schedules is the team getting sidetracked onto different (maybe more interesting) work and leave their project work far too late. It is difficult to make up time at the end of the project when the team should be hardening the code and getting ready for testing and user acceptance. Setting regular milestones or rituals during the project is a great way to ensure the team remains focused on the task at hand. There are a couple of ways we incorporate setting regular milestones into our delivery process: Sprints and Showcase events.
Sprints are an Agile method of delivering software whereby the requirements to be tackled are broken up into small parts called user stories. The user stories are what the team works on during the sprint. Planning is done before the sprint starts, with agreement on what will be completed during the sprint. Sprints are typically two weeks long. However, any duration can be chosen if it doesn't stretch out too long. I usually like working in two-week sprints. The sprint usually has a retrospective at the end. Retrospective (Retro's) allow the team to look back on what worked and what didn't. Retro's don't need to occur for each sprint, but it is good to get together even informally to discuss how the past sprint worked.
Product showcases are rituals designed to allow the team to demonstrate progress. Showcase events are spaced regularly during the project and can involve representatives from the business to show progress and how things will work. It also gives the delivery team a focus point to ensure they remain on task with regular checkpoints providing motivation.
How to get here
4). Have strong technical leadership
Technical leadership (Tech Lead) is an essential aspect of any engineering or software delivery team. Technical leadership guides the overall technical aspects of the software under development. Decisions around languages and frameworks, design and architecture of the software are directed by the technical lead. The tech lead will also guide and mentor junior developers setting the scaffolding around how they will deliver the software, set coding standards and leading the code review process. Tech leads should still be on the tools, but a percentage of their time needs to be allocated for team leadership so as not the overburden. Two critical elements of technical leadership contribute to the success of an engineering team, Communication and Technical skills.
A significant hallmark of any leader is the ability to communicate. Communication is essential for interactions at all levels, whether this is an interaction with the business, their peers or management. Now IT people do have a bit of a bad reputation for being poor communicators, however, to be effective, a tech lead needs excellent communication skills.
This one is self-evident, but an effective tech lead needs to be good technically. Whatever the coding language or architecture being used, your tech lead needs to understand this inside and out. If the company is moving to new technologies, then the tech lead needs to be able to learn these fast and adapt. The tech lead becomes to go-to person when the development manager needs to get the work done.
How to get here
5). Ensure development methodology is followed
Development methodologies are an essential part of how software is delivered. Methodologies describe how the team creates software, detailing all the processes that take place and the expected outputs at the end of each. Every software delivery team uses a development methodology. However, they vary from how these are implemented. Some have a detailed set of documentation on their wiki which describes their methodology, while other teams just talk about how these do things around here. Examples of methodologies include Agile (scrum, kanban, XP, et al.), Waterfall, Hybrid, etc. Development methodologies provide a framework for delivering software, ensuring essential tasks are completed, in addition to critical artefacts being produced. Development methodologies create two crucial elements to the delivery team: A shared playbook and Stage gates.
Development methodologies provide a shared understanding of the development process. Development methodologies cover all aspects of development from how we gather and document requirements, code workflows (code, peer review, branching methods), to testing (progressive, regression, unit and integration) and finally release management and deployment. Having a shared understanding of how to navigate this is important for developers to understand to get their work done.
Development methodologies (can) also enforce stage gates to the development cycle. These stage gates are review points which determine if the process can proceed to the next stage. Good examples here include reviewing requirements during an inception process to ensure we have a complete understanding of the requirements, or indeed the regression testing stage gate to stop buggy code getting out the door.
How to get here
In this article, I have outlined 5 key areas to focus on to ensure your engineering team delivers on time and with a high level of quality. At the end of the day, if you focus on the commonsense application of quality engineering practices outlined in this article, you should be able to achieve a good result and ensure your team delivers.