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. In this blog post, I share what I see as some of the key lessons from our journey.
In the United States, many drivers of commercial vehicles fall under federal Hours of Service rules that limit the amount of time drivers can drive, and require the drivers to keep log books of their activities so as to be able to demonstrate compliance against the limits. These rules are intended to make our roads safer by reducing driving while fatigued. For more than 20 years, use of electronic logs has been optional, and most drivers have used paper logs. Starting December 18, 2017, use of electronic logs, along with a new set of regulations for ELDs is mandatory.
As a business, our challenge was to update our existing electronic logging system to comply with the new ELD rules, and to self-certify our system early enough to provide our customers and partners assurance that purchasing our system would be a wise decision.
Getting Started in the Face of Uncertainty
After the new rules were finalized in December 2015, we updated our analysis of impacts to our system and went through an initial round of estimating. The initial estimates were not too alarming. We were in the tail end of a large functional update to our system, so we went on to complete and roll out that update. We then structured a team around the ELD work (with other teams handling general enhancements / maintenance and partner integrations), and got started.
Getting started was difficult, as the initial estimate team had not been trained in agile estimation and planning methods, but we were conducting the project in an agile manner. Thus, we did not start with a full backlog of the work to accomplish. What we did do, was start breaking the work down into user stories and vertical slices, looking for ways we could make progress even though the big picture was still unclear. We also incorporated some infrastructure updates and technical debt reduction into this initial work, so that we would be well positioned to run more smoothly over time.
In my view, this "getting started in the face of uncertainty" turned out to have a number of advantages:
- We were able to make valuable progress and establish a team velocity - this became important later, as we did get to the big picture view.
- We were able to maintain and evolve a "done-ness" definition that ensured that completed stories were done-done and that our per-release regression testing was against a high quality baseline.
- We did not get stuck in "analysis paralysis," waiting for a complete analysis before making progress, instead we talked through the issues that would be our major impediments (issues we would have to tackle in order to make progress) and we developed a successful cross-team working relationship that allowed the other teams to also deliver value.
- AGILE TAKEAWAYS -
- Useful progress can be made, and learning can be gained, by getting started - even if the big picture is not clear.
- When estimating and planning a large project, experienced agilists can help guide a team to create an effective agile plan.
Getting to the Big Picture
We made several months of valuable progress... but the big picture still eluded us. Leadership had set a target release date, but we could not see whether our rate of progress would get us there or not. We had many choices as to the levels of non-essential functionality we would include along the way - but how ruthless did we need to be in focusing on the essentials? It was time to get to the big picture.
We decided to conduct a two-day planning workshop, which was heavily organized and facilitated, in order to get us to that big picture. Key elements of this workshop included:
Participation from business, engineering, and customer service.
A story writing activity, where we mapped the ELD rules to user stories, and also captured user stories for useful enhancements that we wanted to fold into the product along the way. (pictured above)
A prioritization activity, where we ranked user stories by the value they would deliver.
An estimation activity, where we assigned story point estimates to each story. (pictured below)
A release planning activity, where we partitioned the work into likely releases: what can we deliver early to provide value?
An analysis and next steps activity, where we drew conclusions and decided on next steps.
The planning workshop gave us a big picture view of the work left to do... about 200 user stories and how long it would take to do everything we wanted... about 3 years! This was not a good answer, because we didn't have 3 years. But it was a useful answer. The radical transparency of looking at the work and the likely rate of progress gave us what we needed so that we could start making hard decisions. That user interface overhaul that would polish the user experience and fix some bugs? Off the table. A revamp of the test automation system? Off the table. A focus on what would give us a compliant and usable product? Razor sharp.
The planning workshop gave us a clear alignment and sense of "we're in this together" across the engineering, business, and customer service teams. This alignment was sustained throughout the project. We also got a business-level appreciation for the effort, complexity, and sheer magnitude of the work ahead. (A stack of 200 story cards tells its own story). This helped start a basis for a build-up chart that would show us visually our progress against the remaining work. Through the workshop, we also received a shared understanding that our plan was probably 80% of what was needed, and that there would be additional discovery along the way.
- AGILE TAKEAWAYS -
- Involving cross-functional participants in a planning workshop builds alignment.
- A "good enough" plan (what's all the work we can think of?) is valuable, and can be created in a short period of time.
- Even an initial estimated backlog and build-up can help provide critical focus on what is important/valuable - helping drive even hard decisions about much-cherished features of lesser value.
- An established team with an established velocity for the work being done provides realistic information about the rate of subsequent work.
- Using "already estimated and done" stories as reference points helps calibrate estimation activities such as the Team Estimation Game.
- Facilitation matters: planning and conducting this workshop according to learning from Agile Coaching Institute's "The Agile Facilitator" helped ensure that our two days were focused, productive, and valuable.
- Face-to-face participation was extremely valuable; as you can see in the photographs, we made use of wall space and table space to make sure that all of the information was visible all of the time.
- Leadership response to transparency is critical and very telling. Our leadership response was a healthy one of "what can we all do to meet this challenge?" and not one of denial or "shoot the messenger."
Strategically, however, we were wrestling with a number of overlapping and competing objectives, including:
- The product must be ready in time for customers to meet regulatory compliance dates.
- We want the product at a compliant state much earlier, as this means we can join the list of registered providers, and so more customers can feel comfortable choosing our solution before the compliance date.
- We want the product at a compliance state early so that our integration partners can complete their integration and also register their systems; we want to deliver select features early to aid partner integration.
- We want to complete a series of functional enhancements that help our product and our partners' products serve a larger customer base.
- We don't have unlimited investment funds to scale the teams doing the work.
Our agile approach and big picture planning did not resolve this strategic dilemma for us. However, it did provide us with data to help us make decisions to balance these objectives.
It's Too Big. What Do We Do Now?
With the critical information of size / build-up from our planning workshop, the engineering / product team went through a planning refinement exercise. This exercise had two key focal points: Make the Work Smaller and Go Faster.
Making the Work Smaller: This was a detailed "scrub" of the backlog that we had generated. For each story, we considered:
- What part of this is essential, and what part is optional? Where can we draw a line between creating something compliant and convenient vs. fully streamlined and very polished? Can we define what's in our MVP vs. post-MVP "make it better later?"
- What similarity or shared infrastructure exists when we look at other user stories? Are there any orderings or groupings that would help streamline the work?
- What questions do we have (that lead to large estimates due to uncertainty or risk)? What clarification work can we do early that will help reduce that risk and uncertainty?
Go Faster: This was a detailed look at our experience as a team so far and our technical practices. While our retrospectives had been revealing impediments and opportunities, we took this opportunity to take a fresh look. We chose a number of improvement actions, and speculated on the range of possible velocity improvements that we might get out of these. We came out of this activity with:
- A refined backlog, partitioned into value-providing releases up to an MVP (launchable product) along with a list of key enhancements that we could take on after that launch.
- A set of improvement actions, including recommendations to leadership for actions that were outside the team's authority.
- A speculative velocity range (here's how fast we might go).
- A speculative build-up chart, showing possible completion dates; if we met our velocity aspirations, we would be later than we wanted but still in the game.
- A team mindset of challenging every backlog item and every acceptance criteria: What do we really need to do here? What can we not do, or do later?
From this basis, we dove back into the work, and started on implementing the improvement actions. What we learned over time is that our "improved velocity" speculations were optimistic. In our best sprints over the remainder of the project, we managed to hit the mid-range of our aspirational velocity, but our consistent average was lower than our low end of speculated improvement. One mistake I made in maintaining our build-up chart was showing the build-up based on the aspirational velocity range for too long, which meant we were making decisions based on optimistic information rather than actual information. We did, in the end, take into account the actual rate of progress and update our stakeholders with a new target date.
- AGILE TAKEAWAYS -
- Advertising a build-up based on aspirational velocity is tempting. Don't succumb. It delays reality-based decision making.
- Having team alignment and mindset around "what's of value" (in this case, balancing compliance, convenience, early partner integration, and time-to-market) helps drive conversations of simplicity and focus. What can we do now that will deliver sufficient value, and improve later?
Was this helpful? What did you learn from these agile takeaways that you can apply in your own projects? Stay tuned for Thursday's post, as I continue sharing insights from our ELD journey!