In a modern, agile environment, development teams need to move quickly--but precisely. It’s harder than it seems. But good teams with clear methodologies and project awareness will almost always deliver on time--often exceeding expectations along the way.
Building features: two approaches
“How quickly can you deliver feature X?”
Essentially, this is the question every development team has to continually confront if they want to succeed in a dynamic, cutting-edge industry like auto transport logistics where sophisticated products like driver delivery apps and car hauler load boards are worked on and perfected.
To be honest, it’s usually less of a simple question and more of an unyielding request: "We need feature X in a month!" And, quite often, it's not really next month. Feature X is typically needed yesterday.
There are multiple approaches worth considering when dealing with this type of development request. You can either throw your hands in the air and remind everyone within earshot that there’s no logical way to professionally build out the new feature within the existing timeline, or you can put everything on hold--and I mean everything-- and begin coding right away with single-minded intensity.
Both options have their merits. Sometimes the best bet is to approach things slowly, meticulously to ensure foolproof feature development. In many respects, it’s hard to argue with a methodical, disciplined process that will minimize opportunities for errors and costly rework. Of course, the inevitable delay this approach yields may have market consequences such as missed opportunities to exploit narrow product gaps with competitors. In the digital age, slow and steady doesn’t always win the race.
The ASAP approach has its own pros (and cons). At Ship.Cars, for example. we always strive to solve problems quickly and efficiently for the benefit of the customer. No surprise there. And sometimes, delivering 11th-hour solutions may appear like the best way to accomplish this goal, despite the well-known trappings of haste. Additionally, this unwaveringly swift approach can sometimes make you feel as if you’re in a movie: Heroic developer burns the midnight oil while building complex software solutions that move the plot forward overnight with rushes of adrenaline (and sleeplessness). Of course, the real price is paid later when the team is forced to make multiple adjustments because of issues related to insufficient planning and slapdash execution.
Perhaps it’s a bit unfair to describe these two approaches in the above manner. Most of us with careers in the IT sector have some experience with both. And there is always a reason for trying one or the other, since both attempt to satisfy customer needs. However, it is as important to focus on the drawbacks as it is to focus on the benefits.
So, how do you achieve both--careful planning and speed of execution? It is not impossible. Surprisingly, it isn't even that difficult once you have the right mindset and support from leadership.
At Ship.Cars, we start by defining short development cycles. The reality is that plans change and will always change. This is the nature of any business rooted in advanced technology, and we’re fully aware that we must constantly adapt as we move forward if we want to continue to succeed.
Having short development cycles does not mean that individuals magically produce more code. But it improves everyone's focus on the goals, and brings the satisfaction of delivering something before moving on to the next task. In the meantime, the product development part of the team is busy getting ready for the next cycle—which might be as short as one week.
This flexibility helps us react to the business priorities without descending into chaos. But it goes further. The length of these development cycles is something else that is adaptable. This means that when we plan for subsequent sprints and development cycles, we are flexible about extending timelines, sometimes up to a whole month, if our data demonstrates that the outcome would be worth it. This kind of process optimization is absolutely essential to agile organizations looking to improve speed of execution.
Homework and the larger plan
This brings us to another important aspect of planning: doing your homework. As mentioned previously, we are fully aware that plans may change at a moment’s notice. But quite often that newly requested feature (“feature X”) was already part of a larger plan. By doing significant initial research, the entire development team becomes aware of what will likely be needed for the ensuing months. So while we might play around with the building blocks and move one in front of the other, these individual blocks have already been taken into consideration and exist on two parallel tracks: on a high level as part of the overall architecture; and in greater detail with the specific developers who are going to work on this particular piece.
All of this sounds great in theory but can be difficult to put into practice. This is precisely why at Ship.Cars we don't expect our management team to arrange all of this on their own. Our approach is to find and nurture the mindset that enables the whole team to be flexible. When everyone is aware of both the short-term plans and long-term vision, the occasional change of plans is seen simply as a problem to solve for the next iteration.
Distractions? What distractions?
The final piece of this agile mindset is to avoid distractions. At Ship.Cars, we share information proactively in order to avoid countless, unnecessary meetings that impede swift execution. We tend to stick to established, proven business practices rather than falling for buzzwords and attempting to reinvent everything on the fly. Instead of switching between approaches, we use this time to spread the domain knowledge across the team. This creates the type of stability that allows us to innovate where it actually matters: in the solutions we provide to our customers.
How does all of this work in practice? Let me give you an example. Last month, the Ship.Cars development team received a customer request to be able to autofill carrier information by providing a DOT number. For the end-user, this is simple enough: They would enter the number in the respective field, and everything will populate automatically.
Enter the wise developer
Mention this to a developer and they will tell you there is nothing simple about it. We’re talking about separate products that need to communicate between each other and share this information in a seamless manner. It has to happen at the click of a button, with minimal delay and without being confusing to any user. Thankfully, however, our team had done our homework, and we knew that something like this would be requested sooner or later. We had a plan for that.
First, we discussed the feature at our weekly backlog refinement session, so there was no need to schedule an emergency meeting to push it forward. During the meeting, we compared it to the functionality we already had planned, figured out it could be done by a relatively junior developer with some support from a senior figure, and that some assistance from an adjacent team would be needed. No problem. Since all of our teams are organized the same way, we have the automatic flexibility and open lines of communication to tackle any number of “last-minute” feature builds. Development started on Monday, quality assurance on Thursday, and we were ready to release the Monday after—less than two weeks after the initial request arrived.
Ship.Cars: the next innovation
In many respects, a good developer is like any other professional leveraging nuance, hard work, skill set and lessons from the past to perform at the highest level possible. To go fast, it pays to have already gone deep, which is to say, having applied a certain holistic business intelligence to the larger project beforehand and taken into account a wide range of factors including potential blockers, emerging requests and rapid accelerations. This is what we do at Ship.Cars. This is why we're able to be agile solution providers and meet the needs of our customers while always thirsting for that next innovation.