In recent years, ‘Agile’ and ‘Scrum’ development processes have become widespread. These development methodologies have gained popularity in response to frustration and difficulties experienced with medium and large engineering projects, and in particular, software projects.
Even if you don’t have the resources to implement a formal Agile / Scrum process, there are some important takeaways that are relevant and useful in even the smallest projects. We have adhered to these ideas and methods for decades, long before the current popularity of the Agile methods.
Break up a project into small ‘bite-sized’ pieces
There are a few reasons why it is good to break up a project into smaller pieces:
- It is easier to make an accurate estimate of a small effort than a big effort. This point seems obvious but is often ignored. If you break up a project into tasks or sub-projects, each of which might consume a week or so, or maybe less, your overall estimate of the resources and time needed to complete the overall project will be more accurate.
- It will be easier to identify tasks that can be worked on in parallel, if you have resources available ( i.e. engineers ) to work on them
- It will be easier to identify dependencies between the various sub-tasks, which will impact the ability to work on different sub-tasks in parallel
- It will be easier to identify priorities and required sequential ordering of the sub-tasks
- It is easier to identify and provide deliverables on a short incremental time frame
- It is easier to track progress
- Problems can be detected faster, allowing adjustments to be made to the overall project sooner rather than later
Update the task list on an on-going basis
As a project is running, it is inevitable that new information comes to light. It is unlikely, except in the simplest of projects, that everything that comes up will be anticipated at the start of the project. It is important to identify and keep track of new issues and tasks that should be dealt with, as they come up, in order to have an accurate estimate of what lies ahead.
Work on the riskiest or least understood sub tasks first
In a typical real time system, embedded software, or any software project, there is a ripple or domino effect from one component of the project to the next. When designing a system with many parts, there are always ‘assumptions’ made about how a specific component of the larger system will work. If these assumptions prove to be incorrect, then the ramifications can ripple through the rest of the system. In the worst case, it can require a large change to many other components of the system. Therefore, it is best to work out the details of the sub-component that you are most unsure about, first. That way, you will minimize the effort spent to re-engineer other parts of the overall embedded system that were based on an incorrect assumption.
Try to provide one or more ‘deliverables’ every week
As a contract engineering services firm, we know that we are being paid by our customers to deliver value to them each week. Deliverables can take the form of software written, tested, and committed, specifications for something to be developed, bugs diagnosed and fixed, etc. We have made a point of providing weekly status reports to our customers for all projects, in order to make clear exactly what we have delivered during the prior work week.
But in a more general sense, by ensuring that something is being delivered in a relatively short incremental time frame, you get rapid feedback and it is easier to see if the project is on track, if it is making forward progress, and if your overall estimates are in line with reality. Conversely, if the deliverables are scheduled out for longer periods of time, then it will be that much longer until you realize something is wrong and you can take corrective action.
Communicate as often as needed
While a daily team meeting may not be required, it is nevertheless good to keep all interested parties appraised of issues and problems when they come up. It is important for engineering team members to let the relevant other people know when they are being blocked from making progress by something not under their control. Additionally important is to have a direct communication channel open so that engineers can have questions answered rapidly. Instant messaging systems, such as Skype, are especially helpful in this regard.
Summary
The ideas presented above are meant as general guidelines. A large amount of individual judgment goes into deciding how best to break up a large project, what are the appropriate deliverables and time frames, how often to have meetings, etc. But however these ideas are adapted to a specific situation, they should prove to be useful.
Please contact us and let us know how we can help you with your embedded software or real time systems projects.