About this Paper
Engineers are not good at dealing with customers,” said Tom Smykowski, a character in the movie “Office Space.”
And while that quote is comical because it’s so obviously ridiculous, there’s no avoiding the fact it touches on one of the many stereotypes software engineers regularly confront. “Engineers aren’t creative” is another common misperception, and probably one of the most frustrating.
Anyone who works closely with software engineers understands it takes a big brain to do what they do, even if it’s never really understood exactly what they do or how they do it. But just because you spend the bulk of your time in an obscure world of ones and zeroes, it doesn’t mean you don’t love being empowered to discover uniquely creative ways of solving complex problems.
You simply want a firm grasp on the problems you’re tasked with solving and to be allowed to solve them your way.
But when your team is mired in a poor product delivery system, you and your team likely spend too much of your limited bandwidth deciphering unclear requirements or seeking further explanation of insufficiently described problem statements.
In today’s increasingly complex product delivery workflows, smoothly handing-off work from one life cycle stage to the next requires clear cross-team communication. But handoff difficulties too often become bottlenecks that stall your productivity, especially within delivery environments where teams are siloed and communication lacks efficiency and transparency.
You need complete visibility into the requirements document as it shifts and into every phase of the product roadmap, as well as real-time insight into the related activities of all delivery team members. When that’s the reality, you become a creative problem solver, empowered not only to develop innovative solutions to the challenges your product’s tasked with overcoming, but also to feel passionate about your work while doing it.
You need complete visibility into a shifting requirements document and every phase of the product roadmap.
Although the challenges mentioned thus far relate specifically to just a few of the many tasks typically required of a software engineer, together they speak in broader terms about a fundamentally flawed product delivery system.
Fixing it requires an entirely new mode of communication, which demands a comprehensive solution to some of the most common challenges:
A “task” mindset with no context
When problem statements fail to provide a thorough description of what needs to be solved, you become a taskmaster. All too often, you’re “tasked” with a specific request, such as “Change this drop-down menu to a list with radio buttons.” Of course, you can handle that, but why are you being asked to do so? What’s the larger problem? By providing the proper context, such as “The drop-down menu makes the user experience too cumbersome,” you’re enabled to creatively address the bigger picture instead of simply completing a task that’s really just a Band-Aid. To address the challenge, you need complete visibility into what is being built from Day One.
Poorly defined requirements lead to incomplete solutions—a situation that results in unnecessarily reworking the same requirements, definitely not the best use of your time and talent. What you need is a proactive, inclusive system of collaboration that lets you weigh in on the requirements early in the product delivery life cycle.
Today it’s very rare for a development team to work on a greenfield project. Given the reality that virtually every new software release must be developed to operate harmoniously with legacy code, you’re routinely presented with unique challenges—which become major process hindrances when you lack sufficiently supportive documentation. The solution hinges on having access to a central information repository that provides comprehensive insight into what has been documented and decided upon.
Shifting to an “embrace change” mentality
Why do defects continue to be added to the backlog every time a test fails? Because when you’re focused on immediate tasks, with deadlines looming, issues that should be addressed as part of the current iteration get bumped down the priority list. Or requirements change and you (and other engineers whose work is impacted) aren’t made aware. Fixing the situation means implementing a system that not only ensures you’re informed when requirements change, but that also tracks cross-project relationships and displays how new information impacts the entire product team.
FRUSTRATION: A task mentality with no context.
When you have complete visibility into the entire product delivery process, your development team gains crucial efficiencies. Team members are better positioned to know with certainty when each iteration is ready to ship, which results in more accurate scopes of work and delivery timeline estimates.
Like all professionals who take pride in their work, you want the problems you’re tasked with solving to be well defined and clearly articulated before you risk spending significant time developing the wrong solutions.
Even after a product is done, which by definition means “delivered,” you likely expect future changes to delay a product’s true “doneness.” And the surest way to flip your good mood upside down is to hear what you delivered is “almost right,” but that the requirements changed upstream and, “Sorry no one gave you a heads up.”
Far too often those who need to know first are the last to find out.
TIP: Insist on being heard during the requirements definition phase
When product completion is a moving target, shifting in the winds of change with no timely status updates delivered to those actually doing the work, it’s virtually impossible for any software engineer to know with certainty when a product will ship.
In such a development environment, how can you estimate delivery timeframes with any real confidence you’ll actually meet your deadlines?
So make it clear that the engineering team wants to be included from the start—to gain an early understanding of the customer’s challenges and to begin brainstorming innovative yet realistic solutions. With such early involvement, you gain insight into the problems that need to be solved well before the team begins coding, allowing you to contribute in more meaningful ways toward achieving the product’s ultimate goals.
When effective collaboration becomes an expected component of the product delivery process, with all parties empowered to participate at the beginning, big-picture context gives you the visibility needed to make logical, accurate assumptions. Downstream software changes are not only anticipated, but also communicated to you in real time and openly documented.
But contrary to popular belief, fostering healthy collaboration does not equal scheduling another time-draining, weekly all-hands meeting. It means insisting that team wide involvement occurs from the get-go, with a system in place that allows you to quantify how such proactive, collective participation in the development process saves the entire organization precious time later in the life cycle.
Convincing leadership that the engineering team’s Day One participation will dramatically improve the overall process is part of laying the groundwork for a completely new mind-set; one that embraces a fresh approach to vigorous, comprehensive collaboration.
What’s needed next is a tool that helps make this new world a reality; a product delivery solution that not only empowers every engineer to become a fully engaged participant, but also that gives your entire team confidence they’re integral components of a collectively focused unit that delivers truly innovative products.
FRUSTRATION: Endless Rework
Your engineering team’s in a perpetual state of iterate, iterate, iterate. Things run smoothly for a while, with releases being pushed on time and on budget. But with each successful release the pressure builds to do more, faster. And with no system of timely, open communication in place,
a wrench is sure to be thrown into your
Though not ideal, it’s almost expected that when product delivery teams are focused on their distinct tasks, pushing full-speed ahead on parallel tracks, communication glitches happen from time to time. But if communication breakdown becomes a systemic issue, that’s when you, as a software engineer, end up wasting time developing iterations that no longer jibe with the bigger picture.
Lacking timely, open communication in place, a wrench is sure to be thrown into your well-oiled machine.
TIP: Make open communication part of your delivery-process DNA
In an iterative development process, rework is inevitable and beneficial up to a point. A major advantage of an iterative system is that it allows mistakes and experimentation, early enough in the cycle to provide ample time to properly implement corrective actions.
But when requirements aren’t accurately described, or changes aren’t communicated proactively, you will be reworking problems you thought you already solved.
Say you’re building a solution described by its requirements as “needing to link fields in an online entry form to a particular set of database subdirectories.” So that’s what you do, knowing that based on the requirements such functionality is integral to additional downstream iterations.
But after your team releases the solution, you learn during QA testing that the requirements changed and because your iteration includes the “wrong” functionality, that iteration and your subsequent releases must all be reworked to address the requirements, of which you were never made aware!
Such a scenario describes a costly, frustrating, waste of time. You’ve been disheartened by what could have been easily avoided. Any business that makes a habit of performing crucial tasks with such inefficiency risks not only burning through its development budget, but also burning out its engineers.
How can you stop constantly spinning your wheels in a frustrating cycle of react, repair, rework, repeat?
How can you discover more daily bandwidth so your creative problem-solving talents can improve the entire product delivery process?
With the right product delivery solution, you’re no longer caught off-guard after the fact because you’re constantly tapped into the flow of communication among the entire delivery team. Such visibility enables real-time discussions that serve to clarify shifting requirements and foster decision-making based on collective collaboration.
FRUSTRATION: Legacy Code
Those who develop software using an iterative process understand the importance of stakeholders providing useful information in a timely fashion throughout the product delivery cycle. But far too often you’re left to blindly guess how new releases should interact with legacy code.
Even in a perfect world, developing iterations that play nicely with legacy code can be a lot like fitting a square peg into a round hole. With no legacy documentation to use as a frame of reference, trying to predict how a broken interaction between an iteration and legacy code might cause a far-reaching ripple effect turns what should be simple releases into exercises in frustration.
TIP: Document And share everything
To software engineers, unpredictability is a four-letter word. Any legacy code component that lacks clearly articulated documentation regarding the ways in which it must sync with new iterations forces trial-by-error bug discovery via building, testing and rebuilding—not the ideal recipe for expediting quality product releases.
Simply stated, you need to know how the legacy code works and what specific features it enables before you begin a new iteration.
Unfortunately when you’re embroiled in a flawed product delivery process, your suggestion to fix it by implementing a new system of more effective collaboration will likely be viewed as overly simplistic, if not completely unrealistic.
There’s just too much pressure to accelerate product delivery for you to invest the time required to tackle fundamental process improvements.
However, quickening the pace of product delivery without the proper system of documentation and collaborative decision-making breeds an environment in which innovation becomes elusive.
All of which highlights the need for an organization’s leadership to explore adopting a specialized product delivery platform that serves all stakeholders equally.
Developing iterations that play nicely with legacy code can be a lot like fitting a square peg into a round hole.
The solution must provide complete visibility into the delivery team’s current state of affairs in terms of decisions made to date, with quick, easy access to the documentation that logically lays out a new course of action. It must also integrate seamlessly with the other tools you use regularly to ensure critical data flows smoothly between applications.
Ultimately, you need a solution that’s built to provide immediate and measurable collaboration efficiencies.
With the right solution in place, a new, more innovative method of transparent collaboration becomes the norm. As a result, your entire team realizes game-changing productivity enhancements that not only foster creativity, but spur innovation.
FRUSTRATION: Shifting to an “embrace change” mentality.
The drive to win applies considerable pressure on the entire product delivery team to introduce new, innovative products, faster. But accelerating a product’s time-to-market is a slippery slope when the quickened pace risks adversely impact architectural integrity and subsequent build quality.
TIP: Circle back with all stakeholders and close the loops.
Often, getting a product release “exactly right” takes a back seat to getting it “basically right” for the sake of expediency. Agile software engineers know they can navigate defects immediately, and repair during subsequent iterations.
But what if those downstream fixes continue to pile up as the pace of delivery accelerates? At some point, unaddressed technical debt becomes a major burden, particularly when the repeatedly disregarded issues are architectural in nature.
Ignored too long, the mounting technical debt begins to affect the pace of product delivery the entire team worked so hard to accelerate, which ultimately risks causing a highly undesirable result: unhappy customers.
When that endpoint occurs, it becomes abundantly clear that the sting of delivering poor quality lingers much longer than the satisfaction gained from meeting the schedule.
So what’s the answer?
Convince management the pace of delivery needs to slow down? Good luck with that.
Hire more software engineers? Not a bad idea in general, but assuming good ones are even available, bringing aboard additional headcount won’t fix a fundamentally flawed system.
With a specialized product delivery solution developed to include the tools you need to stay agile, technical-debt fixes become integrated with a more streamlined development cycle.
The mounting technical debt begins to affect the pace of product delivery the entire team worked so hard to accelerate.
Product delivery is often accomplished with an ecosystem of integrated solutions, optimized to functional roles but integrated through data and collaboration
But beyond that, you need a platform that frames a structured system of collaboration, one that enables all stakeholders—business analysts, QA and UX teams, and your engineering resources—to be aware of each other’s activities early in the development life cycle so as to promote a more cohesive workflow in an iterative loop.
Once again, it’s clear that the problems you encounter when pressured to innovate faster, be they technical, systemic, or human in nature, can all be solved with a better system of all-in collaboration; one designed specifically for teams of creative minds collectively focused on building great products.
While it won’t necessarily be easy, it’s easier than you might think. And you can be your organization’s change agent.
Show your leadership how a system of better-structured collaboration will focus the entire product delivery team on meeting the most critical business objectives. Demonstrate your commitment by engaging all stakeholders business wide and clearly articulating your perception of how changes will impact your delivery process, both upstream and down.