5 ways to ensure your engineering team delivers

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.

Problem statement

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.

So 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.

A better approach

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

• Requirements gathering: Most requirements or user stories start with a discussion with the business. These conversations take place to flesh out what is required. These requirements can be documented in any manner (user story or a more detailed specification) as long it is captured and easy to understand. We won't get into the religious discussions around whether a requirements spec or a user story is better, as I believe there is room for each of these methods depending on what you are trying to achieve, but that is more of a story for a different post. 
• Analysis or thinking time: A critical element that is often overlooked especially in a rush to become Agile is the analysis time that all business analysts require to really get into the task at hand. This time allows the analyst to come at the problem from many different angles, having time to think of questions or things that the business haven't thought of, which can then be confirmed with the company to improve the quality of the requirements. 
• Project inceptions: Once the analyst has gathered the requirements and had some time for analysis, the next step is to have an inception for the project. Inceptions are events which can run for a couple of days or a couple of weeks depending on the size of the project in question, they provide an opportunity for the team that is responsible for delivering the project to get together to discuss the project in question. Its a time for communication for both the engineers, analysts and business folks to come together to discuss what's required, ensuring everyone is on the same page. Here nuance can be teased out of words and technical challenges can be tackled at least on whiteboards or paper until the delivery team is comfortable that they understand the who, what, how and how long of the project.
• Store in the backlog: Requirements when confirmed with the business should be stored in a product backlog. The requirements should be sorted in business priority order to make it easy for the engineering team to understand the most essential items for the business. This will become important in point two. The product backlog is a living document and is accessible to both engineering and the business. 

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.

Delivery timing
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
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

• Team involvement: The team is involved in setting the delivery schedule. Tap into the team's knowledge of the systems, technical and domain expertise. Never make any delivery decisions without consulting the team and getting their input and more importantly, buy-in to the schedule.
• Holidays and leave: Are always factored into decision in terms of delivery schedule. Always make sure you have visibility on peoples leave plans and take these into account. Don't try to squeeze a release in just before someone goes on leave. The resulting release will always be rushed and prone to errors. 
• Done is done: The delivery schedule leaves enough time to execute the team's definition of done. This needs to be non-negotiable. Forcing the team to take shortcuts to make a delivery deadline is short-sighted and counter-intuitive. 
• Project inception: Talked about in step one the inception process is an excellent way for the team to get comfortable with the requirements to be delivered and tease out all the functional and non-functional aspects of the work. Especially for a more substantial piece of work, an inception process is a must.
• Delivery Phasing: Phasing delivery over several smaller drops to deliver value to the business sooner is a great way to mitigate the risk of delivery overruns. The team can advise on what they can do and when. 
• Scope changes: All changes to scope need to have an impact on the delivery schedule. If the scope increases then the delivery schedule is pushed out. Decreasing scope can also reduce the delivery timeframe, however, if the team has already invested effort to the item that has been dropped from the scope, the time savings will be reduced.

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
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 showcase
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

• Delivery in sprints: Break up the teams work using user stories and sprints to break the more significant tasks into smaller chunks which can be delivered every two weeks. The regular drumbeat of the sprint (planning, execution, retro) keeps the team focused on delivery and getting the small wins. 
• Show off: Get the team to show off their great work during their product showcase events. Invite the business key stakeholders to keep them engaged. Use the showcase to validate we are on the right track.
• Celebrate wins: When the team achieves a milestone or successful showcase, mark it with a celebration. This can be a quick drink at the end of the day or bringing in a cake the next day or even a simple acknowledgement of a job well done.

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.

Communication
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. 

Technical 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

• Technical direction: Tech leads should have responsibility for technical (coding language, software design, dev workflows, etc.) leadership, along with oversight of development staff. 
• Scoping and requirements: Tech leads should be involved in scoping and review of requirements to provide their guidance and spot any potential issues before they impact the delivery schedule.
• Mentoring and guidance: Tech leads should be actively encouraged to mentor and guide junior members of the team. A lot of this will be informal and organic if encouraged and cultivated by management.
• Code reviews: Code reviews are a core responsibility of the tech lead. The tech lead should be actively monitoring check-ins to the code base, ensuring compliance with coding standards agreed by the development team.
• Technical Debt: Management of technical debt is essential to track and monitor. While not directly related to any release or project, technical debt can quickly derail plans when it reaches the stage of impacting delivery. Tech leads are responsible for managing the technical debt to ensure it is addressed before it becomes a significant problem.

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. 

Shared Playbook
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. 

Stage gates
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

• Development Methodology: Ensure that you document your teams chosen methodology and store on a wiki. Implement the methodology with the team. This can take some time to embed new behaviours, so be patient.  
• Define team rules: An essential element of your methodology should be your team rules and definition of done. Team rules define how the team will work with each other, ensuring everyone works in a way that is inclusive of all personality types.
• Definition of done: The definition of done defines, as the name suggests what the team considers a complete unit of work. This ranges from developed/tested/documented/unit tests created and anything in between. 
• Testing testing testing: Ensure testing and user acceptance testing is a big part of your methodology. Don't skimp on the test resources and ensure your project has a full set of regression test cases defined and preferably automated to increase velocity. 
• Stage gates: Ensure proper stage gates are set up and enforced to ensure the standards the team define are adhered to. Don't release software that hasn't been fulled tested and documented. 

Conclusion

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.