ISE Blog

Getting to ELD: An Agile Journey (Part 2)

On June 30th, 2017, ISE Fleet Services registered a certified compliant ELD (Electronic Logging Device) with the FMCSA (Federal Motor Carrier Safety Administration). Our journey to reach this milestone was long and arduous... and was also a series of lessons in applying an Agile mindset. Read Part 1 of this blog series for greater context of the project and how we got started. For those of you following along, here's what came next for us on this journey...  

Allowing for Discovery

Looking at the earlier build-up chart in my previous post, you'll notice that the target release lines are not horizontal (fixed scope) but have an upward slope, representing an allowance for discovery: what work have we not predicted? A later build-up chart (below) reveals that the actual rate of discovery was significantly
higher... in fact, in some sprints, the target moved almost as fast as the team!


A significant part of our discovery was the many unanticipated impacts to the existing product driven by the data model changes we had adopted to satisfy the new ELD requirements. These were compounded by our backward compatibility approach, which would allow users of our existing products to seamlessly continue to use those products and upgrade to ELD functionality on their own schedule. One thing we did really well was continuously manage the backlog, looking at each new item in the context of where it fit with our goals for each release and the overall project.


  • In a project with any complexity, doing the work teaches us more about what the work is. 
  • It is difficult to predict how much discovery (scope growth) to allow for.
  • Having a goal/purpose for each release eases continuous backlog management, because "where things go" is clearer.

 Technical Debt and Infrastructure Improvement: A Dilemma

On any project there is a tension between spending time "adding functionality," and "improving what we have so we can go faster." Agile technical approaches such as Clean Code promote sustainable development by building in the cleanup and improvement along the way. As we started out on the ELD effort, some of the early work identified was infrastructure improvements to ease maintenance and development over the long term. As the big picture became clear, a sense of time-urgency emerged, tipping the balance towards "adding functionality," and away from "improving what we have so we can go faster."

As a team, we had to make a number of difficult choices: here's a clear improvement that we could make that will help us go faster in the long run, but we think it will slow us down between now and our ELD target release - what shall we do? For the most part, we chose to defer the improvements. It means that we will have some additional work ahead of us (some of which has already been done) for long-term improvement.


  • In striving for sustainable development, context matters. In a time-to-market situation, we may choose to defer some improvements.

  • Keeping an eye out for "what's sustainable" is an important skill and task. For example, if a particular test framework/approach shows early signs of not being sustainable (longer and longer test run times, many intermittent failures), changing approach is much easier before there is an extensive body of tests using the unsustainable approach.

The Final Push

The core ELD team continued to make solid and steady progress. We made two releases with solid deliveries and high quality. The other teams completed significant feature deliveries. Our progress was solid but not enough to meet the target date. With a clear view of reality and the strategic dilemma, we adjusted course:

  • We adjusted release content (again) so that we could meet compliance and partner integration first (prioritizing time to market) and then quickly follow up with additional convenience features - which would be available before end users needed them.

  • We added teams: both the existing product teams that had been working enhancements, maintenance and integration, as well as borrowed teams from our Professional Services business unit.

  • In the last weeks, we asked individuals to put in the extra effort to get us to target, and provided additional support (e.g. dinner brought in a couple of nights a week).

At this point, many of you are thinking that we are tempting Brooks' Law: "adding manpower to a late software project makes it later." Indeed, scaling from one team to five was a challenging task... our challenges included:

  • Supporting team members with limited or no experience in this product / codebase while limiting the impact to work getting done.

  • Keeping the build and core test automation scenarios green and clean.

  • Effectively dividing and coordinating work across five teams.

  • Keeping quality high as multiple teams impacted the "most busy" parts of the codebase.

  • Managing the size of code reviews and merges.

  • Recovering from an accidental wrong-way merge.

Fortunately, the two existing product teams were already integrated into the workflow, and one of the other teams had prior experience with the product codebase. Only one team was at a large disadvantage, and we assigned this team the work that could be made most modular. Could some things have been improved? Of course. But there's a lot that went well. Here are some of the things I observed:

  • Cross-team code reviews, especially for code from the less-experienced teams, helped reduce the impact of code changes made without deep knowledge of the product and codebase.

  • A cross-team PO (with technical help from the teams) coordinating the assignment of work to the teams so as to reduce overlap and collisions and make good use of teams' specific areas of expertise.

  • Team members who stepped up to jump on broken builds and tests and get us back to "green" helped ensure a smooth flow across all the teams.

  • A deep level of quality ownership, where team members detected and helped troubleshoot bugs introduced by other teams.

  • Visible commitment, support and appreciation from leadership, fostering the sense of "we're all in this together."

  • A lot of cross-team communication, enabling increased understanding and reducing the number of blind alleys and bugs introduced.

  • Fast responses to cross-team communication channels (Slack) helped reduce broken build time and delays due to the need for information.

Did Brooks' Law apply in our case? Yes. While we made our certification target, we certainly expended a larger effort getting there (an efficiency-for-time tradeoff) and left ourselves with significant cleanup, much of which only became apparent after initial certification.


  • Adding teams adds complexity (surprise!)
  • Taking the time to have user story conversations takes on extra importance when adding teams or team members who do not have experience with the specific domain or product.
  • Having an appropriate planning horizon is important to project success. Agile projects can often plan only the "next release." Faced with a certain set of knowns (new regulations, compliance dates) and goals (time-to-market), we needed to keep enough planned to see the big picture. We still deferred much of the user story refinement (keeping user stories as "placeholders for conversations" until the time neared to bring them into sprints), but we had to invest enough effort in backlog grooming and story estimation so that the build-up chart reflected "good enough" knowledge to enable decisions - such as when to bring on extra teams.
  • Fostering a shared goal and sense of "we're in this together" helps enable cross-team coordination. Seeing the big picture and being able to reach out across team boundaries to understand how a team's work folds into the larger architecture and codebase makes a big difference when integrating new teams into an ongoing project.

Celebration, and what's next?

On June 30th, 2017, ISE Fleet Services registered a certified compliant ELD (Electronic Logging Device) with the FMCSA (Federal Motor Carrier Safety Administration). Since June, we have worked tirelessly to support our customers and partners, have done much to resolve the cleanup items, and have continued to make improvements and additions. We are proud of what we have created, and of the dedication and teamwork that got us here. As the deadline for the mandate quickly approaches, what's on our mind is... what's the next most valuable thing we can do?

Andrew Smith, Principal Architect

Andrew Smith, Principal Architect

Andrew is a Principal Architect at ISE and leads ISE’s Agile community. He recently earned two new Agile certifications: ICAgile Certified Expert – Agile Coaching (ICE-AC) and ACI Certified Teams Transformation Coach (ACI-CTTC). Andrew is passionate about creating great teams, great software and great customer experiences, and is constantly looking for ways to adapt industry experience and best practices into ISE. In his free time, Andrew enjoys dancing Argentine Tango, public speaking with Toastmasters International, and Yoga.