When the Team Says, “We Don’t Need to Plan.”

When a team does not keep rigor, discipline, and quality in making the work-ready, it doesn’t just impact that team – it impacts all the dependent teams and ultimately the return on investment. *The team names have been changed to protect the learning, but the learning needs to be shared.

The mobile team is a nimble team. Why wouldn’t they be? They’re running with full continuous deployment and the latest technology, so they get to brag – they are Agile, right? In fact, they built their entire backend in Node.JS microservices—a technology no one else in the organization uses. They aren’t like the other teams in other product lines.

Occasionally the team is reminded of this when they have to interact with the other team’s burden with monolithic software that’s older than the newest member of the mobile team. But the mobile team is able to push through this by jumping the line – their Vice President has influence, she’s a rising star.

The team is so confident in their practices, they decided they don’t need to plan anymore.  In fact, they sent the scrum master to release planning with some gibberish features and continued to code – because in their mindset, planning isn’t coding, and coding is what experimenting requires. Hasn’t everyone read the Lean Startup?

When the Product Owner arrived with a high-value feature for marketing initiative with a date, the team was proud to pivot and work on that feature. The team normally doesn’t commit to dates, but this time overconfidence allowed them to assure marketing that this was possible and encouraged the marketing team to build the campaign and buy the ad space.

With an impending set of features, the team made a unanimous decision to run like a start-up, and they willingly worked late into the night. This set of features was much larger than any other features that had been previously experienced – but in the team’s mind, it would be the same. It was decided to plan a week at a time and flow it through the Kanban. Having rarely planned previously, these conversations were ad-hoc and chaotic, and that fact reminded the team why they didn’t plan.

At the first week of planning, they realized the need to access the critical data feed for the monolith, but not being sure what it was – they punted it to the next planning period to discuss. It was forecasted, it could be figured out on the fly, so it was punted two more planning meetings.

In the fourth and last perceived period of planning, the contract from the monolithic system was finalized.  The information from a specific green screen would need to be accessible via a REST call.  The conclusion was that it had to be simple, it was just an API endpoint.  Something that could be done in Node.JS in a few hours. In anticipation, the contract was stubbed out the endpoint for testing – all that had to be done was for the monolithic team to write one simple REST call. The team pushed the entire codebase to production, toggled off of course, and verified it worked. They were ready to launch, an entire month before the marketing push.

All that remained was asking the monolithic team to write a simple API.  They’d be done in a few days, and they’d all be proud of this work. Because they had nothing else to do, as a team – they climbed the stairs up to the monolith team space and spoke with monolith Product Owner laying out the contract. The Product Owner understood the ask—it was clear—and then stated, “Unfortunately, it would be ready in 6 months, if made a priority”.

This is when the shouting began. The mobile team Product Owner started to explain how important this feature was, the campaign, the media buy, and how the entire team had worked heroically on the work, and this wasn’t going to stop them. 

The Product Owner of the monolith responded with empathy, but stated – “We’re integrating into a new ERP system, and that work is the highest priority, it’s on the CIO’s bonus plan. Plus, we are tightly coupled with the vendor, and they release once a quarter.  The next quarter of work was tied up with ERP migration, and the next opportunity is six months away, and any work the mobile team needs to be completed must flow through governance to ensure it aligns to the global strategy.”

The mobile team left in anger. The marketing initiative would not be scrubbed. All of those extra hours heroically working into the night. Nothing will stop the marketing features.

Like normal, this should be escalated to the Vice President who can fix anything, she has influence. Oddly, the team was excited to tell their Vice President with influence about what the outdated monolith team did to them, and the company. Surely, she’d be able to fix it, she had done this before, why would now be different? The team decided to swing by the VP’s office.

The mobile team Product Owner said, “Once again – the other teams are too slow to keep us with us, and we can’t do these awesome things that are important to the organization.” The Vice President responded wanting to help, took the details, and committed to the team that this would be resolved after her one-on-one with the CIO that afternoon. One small detail that was absent from the conversation with the type of work: the ERP.

In the one-on-one, the VP brought up the challenge with the high priority marketing features. Clearly, understanding the importance of the work, the CIO asked what could be done do to help? The VP asked, “Can you prioritize this work with the monolith team so that we can meet the date?” The CIO responded, “The monolith team that’s working on the ERP transition, that I committed delivering the COO and CFO last year?” The VP replied quietly, “Yes”. The CIO responded with, “Now I need to call the CMO.”

The rest of the details of this story are not important, but the learning is. The System of Delivery will only move as fast as your slowest dependency, and you should plan 2x-3x on your horizon to mitigate and schedule out of those. The governance model must be used to set priorities across product lines to prevent this waste. And if those dependencies become an organizational bottleneck – subjugate to it and remediate it.