By Paul Tidwell
Vice President of Technology
Every business would love to go faster. This is a universal fact.
Whether building products or delivering software services, there is no greater goal than to deliver a new feature or capability to production -- hopefully one that users absolutely love -- in a timely fashion. These incremental improvements drive conversion, adoption and retention, and keep companies competitive.
Here are six techniques to ensure that your delivery teams operate at peak efficiency.
1. Define a domain language
Effective communication is one of the biggest challenges in any project, and it is almost inevitable when developers and business stakeholders sit down to talk.
Within an organization, the various product teams and branches of the organizational chart often have their own lexicons that are not aligned with one another. To combat this and communicate clearly, it is helpful to agree on a domain language, or common set of terminology. This permits teams to focus more on problem solving the delivers value and less time on ensuring alignment. A shared domain language goes a long way toward confidence that responsible parties know what they are truly responsible for.
Business stakeholders and the implementation team should agree to use the same lexicon for the user stories, acceptance criteria, domain objects, services and supporting documentation. This language is for the internal product team and is frequently decoupled from the client user-facing language often controlled by marketing.
2. Use patterns (design, interaction, and architecture)
Repetition breeds familiarity, and data suggests we more readily process and retain patterns we have seen before. In building solutions, fast-moving teams use a design system and interaction patterns which are clearly defined and documented. The UX team can draw from this pattern library and solve any unique challenge once and only once, and build on those solutions as challenges increase in complexity.
This same approach applies to interaction patterns as well. Interaction designers should define an interaction for a given element and then remain consistent, building upon the framework and extending it when new interactions are required.
A single interaction pattern for a given element also means developers only have to code it once, testers will test it once, and users know what to expect when they interact with it.
Leveraging patterns in software architectures is a long-proven and well-understood practice. The recommendation is to be very intentional about when to apply a pattern. Apply patterns where they make sense and where they effectively solve a problem. Never apply them for the sake of using a pattern or because it is used elsewhere. Limit the number of patterns at play, and make sure the development team understands why they are at play and what problem they solve. Introduce new patterns sparingly. Write DRY, SOLID code is the jargon-rich summary.
3. Automate all the things (unit and e2e tests, deployments, environments)
There is some Zen in writing automation scripts to replace repetitive, manual work while reducing errors and time on task. While performing tasks manually is great to prove out the effectiveness of the task, once you do the task the second time by hand, it is time to start automating. So much collective good comes out of automation, like the freedom to do the other work that is not repetitive, perhaps creating new features or capabilities.
The business stakeholders and execution team will always agree that they prefer creating value over doing the repetitive task, so invest incrementally and early in test automation, deployment automation, infrastructure provisions and scripted environment setup. The value of these grows over time and allows the entire team to deliver high-value work more quickly and consistently. Traditional, manual approaches to end-to-end regression testing can be very expensive and halt a release. The freedom and velocity unleashed by automation of regression testing is obvious, yet so often ignored or overlooked. Investment here pays extensive dividends.
4. Cross-functional team
Building cross-functional teams for skill sharing and collaboration has some obvious benefits in concept, though teams rarely look at how they also enable higher team execution velocity. This velocity is rarely more apparent than when co-located designers and developers have meaningful conversations in real time to solve acute needs and unblock logjams in task execution.
This is different than the recent rise and fall of upfront Big Design, where all the design decisions are made before development begins. Big Design leads to revisiting designs the team assumed to be complete, thus revisiting problem solving on a body of work that was considered done.
Redoing work once it is approved so that development can proceed is wasteful. Teams need to have those discussions as designs emerge and apply the learnings to the next iteration or design.
The same applies for QA in that QA and development should be talking about testability of each step as they build and not deferring QA to later in the project.
To ease how work moves through the pipeline, agree on the artifacts that each resource type needs. Front or back end developer, interaction designers, and quality assurance resources all need very discrete inputs. The team should create contracts between each of those roles to clearly define the artifacts they require to engage on their tasks. This is similar to the done criteria for a user story, in agile terms, but attenuated for a particular role to qualify that a "work item" is truly ready for “production.”
5. Build a backlog -- a real, legitimate, detailed one
Building a backlog is surprisingly difficult, even though it has been a core tenet of agile for over a decade and a half.
Many of you reading this are already thinking that you have a great backlog in place. Think again, and be honest about the quality of your backlog, where it is kept, who has access to it, and how effective your team is at grooming and working from it.
Are you completely satisfied that your backlog is a well-oiled machine that transparently gives the team direction to deliver on the needs of your business? The old saying holds true: nothing worth having comes easy.
The backlog is the key to the future of your project and the solution to so many of the potential problems. Is your team stuck on a dependency? Pull up future stories from the backlog. Wonder when you’ll have an MVP? Look to the backlog.
The challenge is that for the backlog to accurately represent the future, it must have some depth and detail. Those operating with less than two weeks of groomed backlog are limiting the visible project horizon considerably. Providing only user stories is a start, though the real value comes in having fully fleshed-out acceptance criteria that QA, UX, and development understand.
How does this allow you to go fast? The more mature the backlog, the less time planning and grooming take, the more easily you can add and predict the need for resources you don’t have, and the better you can predict and mitigate dependencies. Dependencies may be the single biggest constraint on going fast.
6. Have a full-time Product Owner
Dedicate a full-time Product Owner to support the team. They are the lifeline to the business and are on call to clarify and clear blockers for the team as they build out capabilities. It takes a full-time resource to build a real backlog. All too often as companies try to become agile and employ agile, they take existing resources and dub them Product Owners as an extension of their existing roles. This is not only a great way to burn someone out, but an early indicator of project challenges ahead.
projekt202 is the leader in experience-driven software design and development. We are passionate about improving the experiences that people have with enterprise and consumer digital touchpoints.