Chemistry or Alchemy
That there is a difference between chemistry and alchemy is not something that you would think to question or consider. One is based on scientific principles and rigor and the other on flights of fancy and a healthy measure of fantasy.
The same analogy can be applied to the difference between structural engineering and software engineering. Mechanical and structural engineering, at scale, involves precision and micrometric levels of detail. The material costs of building a physical structure are part of why the placement and dimensions of each component get planned to within fractions of an inch or centimeter before a single board is laid or nail is driven.
Software engineering, the work involved with developing software, is a process of trial and error, refactoring, testing, and incremental improvements. This process continues until your application can stand under the weight of your users and data. Quite often a project will start with a lot of broad concepts grounded in some basics, and only gradually, over time, does it start to take shape into something well-defined.
C.O.G.S.
A key difference between these engineering disciplines was alluded to above; material cost. Software engineering, in most cases, incurs no significant material cost. The real expense is labor. The hour you pay for someone to do the work; time.
Another business based comparison is retail. Retail business involves selling, or more often re-selling, a premade product. In retail, you have to limit losses associated with theft, breakage, spoilage, etc. How this relates to software is in the context of C.O.G.S. (cost of goods sold). The most significant of which, is, again, time. Because, in software, time really is money.
Time Management
First, in order to manage time, you have to be able to track it. We formulate granular estimates against discrete tasks at the beginning of a project and maintain visibility throughout by tracking actual time spent against each of those tasks in real time. This allows for a view of both the forest, the total project budget remaining versus assigned tasks, as well as the trees, how we’re sticking to our estimates as we do the work. Any deviation from an estimate can be quickly identified and mitigated early before it can balloon out of control.
We also use daily and weekly projections for team utilization against budgets and timelines for running projects. This allows us to forecast the contributions of each team member and manage the total budget of a project through each sprint.
Finally, we operate using an Agile process wherein we evaluate each sprint, typically a two-week period, retroactively. Holding a sprint retro meeting gives us insight into how we’re tracking as a team against our goals and make any adjustments or update expectations as necessary.
Task Management
On a task by task basis, we use a couple of internal practices to align actual effort with estimates. First, we espouse a common principle within our team that we call the 50% rule. The 50% rule suggests that if you’ve spent 50% or more of the time allotted to a particular task, but do not feel that you’re at least 50% done with it, you stop, report the discrepancy, and seek guidance to ameliorate whatever technical or logistic challenge has been presented.
Next, team members are asked to evaluate a task before they begin the work. This can mean that the estimate for a particular task is updated or modified to address anything that has changed or if any technical challenges are identified before any time is spent against the original estimate. In doing so we can keep expectations in line with reality rather than find ourselves coming up short once we’re knee-deep.
Constant Communication
Any time we encounter a circumstance where we expect that an estimate will be exceeded, or has been exceeded, we will engage with the Product Owner for remediation. In the instances of a technical feasibility issue, we will seek to resolve this with the Product Owner by deprioritizing a feature and/or offering alternative approaches to a solution. The Agile process for developing software is a creative and collaborative endeavor. Any time we can involve the Product Owner to steer a project to a positive and mutually satisfactory result we will.
This means consistent and active communication. Both within the standard Agile development practices such as backlog grooming and sprint planning, as well as bringing the Product Owner into conversations around User Experience and services or integrations that could lead to time savings.
Reconciliation and Remediation
It can happen to the best of us. You work along with full confidence that you’re tracking against your estimate, and right as you’re about to declare victory you encounter an as yet unidentified technical hurdle. It’s too late now, you’ve exceeded your estimate. What happens next is a reconciliation of expectations and remediation of effort.
The first thing that happens when a team member exceeds an estimate on a task is that further work is stopped on that issue, and it gets a formal review by the lead engineer. If something obvious was missed, or if there’s a straight-forward path to a resolution we can implement, we see if there are other items we’ve come under on and utilize any excess budget remaining. If there’s not an easy path forward, and/or no time left to draw from other completed tasks, we seek to bring the Product Owner into the conversation.
Following up with the Product Owner offers a couple of ways to remediate the issue. First, the Product Owner can deprioritize the feature or issue so we can keep on track with the rest of the backlog. Second, the Product Owner could choose to deprioritize another task or set of tasks to allow some budget lee-way.
Finally, we might seek approval of a change-order to account for the overage, if there’s nothing in the backlog that can be traded for.
Objectives
At the end of it all, whether your digital product is just a simple website or a complex web or mobile application, our goal is to deliver on the promise of your vision. On time, and on budget. If something isn’t possible, we’ll tell you. We employ standards and tactics to help ensure that your vision is brought to life while adhering to your budget.