Continued from Part 1: The Origins of Agile

The Agile Manifesto—while it had a tremendous impact on the digital workplace—doesn't apply to all of the disciplines that exist in the industry today.

There are so many specializations and job titles in the digital world today, and every single one of them can make concrete contributions to a digital product. Today, software engineers do not make working products on their own; their work has little meaning to a user without the work of people who design those products and populate those products with media: artists, content managers, editors, designers, and other users…to name a few.

What was true of software engineers in 2001 is true of most professionals today: we are using software to make our contributions, which will be stored digitally and consumed digitally—either by our colleagues, by consumers, or both. Back then, it usually required expertise in software engineering to make a seemingly trivial change to a digital product. Now, because layers upon layers of new technology have lowered the barriers to entry, we’re all invited to the party.

Inclusive agile

So—in this world where we all have a hand in creating experiences—what makes a digital project successful? Are there common themes we can extract from teams that deliver exceptional work and enjoy doing it? What are our guiding principles in this world where everyone is an engineer, and no one job title or discipline holds the keys to creating something awesome? The Manifesto of Inclusive Agile is an attempt to distill not the processes, but the philosophies of work that underlie the most successful, fulfilling digital experience creation.

Share your thoughts freely and contextually

At the time the Agile Manifesto took shape, only one person could edit a file at a time, chat solutions were rudimentary, and video conferencing wasn’t really a thing. You often had to physically visit a colleague’s desk or schedule an in-person meeting to collaborate efficiently. Processes had become rigid to prevent mistakes, often at the expense of valuable ad hoc communication.

Agile processes like scrum sought to overcome unwieldy tools and processes by increasing individuals’ autonomy to have the interactions they saw fit to have. Daily stand-up meetings would surface issues, and team members could break out into smaller groups to discuss those issues, make decisions, and come up with solutions in near real time. This openness mitigated the pitfalls of clunky technology and provided a check on inflexible dedication to process.

Cloud tools slowly conquered the issues with concurrent editing, and today’s tools are enablers of openness rather than impediments to it. Jira, becoming popular in the early-mid aughts, provided a central, web-based source of truth for requirements and the work to be done. In the late aughts, Google Docs revolutionized document editing: the whole team could safely edit the same document at the same time! By 2020, virtually every type of tool used to create digital experiences had a cloud-based option that enabled concurrent editing, commenting, and notifications. Chat solutions, led by Slack, integrated with the other cloud tools and supercharged our interactions. 

Today’s best-of-breed software allows us to have the right interactions in the right contexts…if we use the tools to their potential. Slack’s thread feature allows those conversations to take place independently, and in a way that allows interested parties to self-select. And by communicating in threads instead of, say, direct messages, we leave a record for the whole channel on how an issue was resolved, or what decision was made. The entire team can benefit from a conversation between two people that happens in the right place—even if most of the team were sleeping when it took place. Whether it be a Slack thread, suggested edits on a Google Doc, code feedback in GitLab, or a comment thread on a design in Figma, each allows us to communicate openly and contextually.

Show progress and get feedback, early and often

The authors of the Agile Manifesto were right to value working software over comprehensive documentation, and we still should. Because it is impossible to imagine the evolution of every requirement at the beginning of a project. That’s why comprehensive documentation isn’t so valuable. Working software—not to be confused with finished software—allows engineers to get feedback on their work early and often, and we don’t want them to wait until they think the software is finished to get this feedback. The same principle applies to the other disciplines: frequent delivery increases efficiency by allowing feedback to be collected before effort is wasted.

Instead of wasting time trying to map out every detail of how an idea will develop, we agree on the parameters of what a project is meant to accomplish, and we cross-reference the level of ambition and complexity with past projects to make an educated guess at an appropriate timeline and budget. Any prediction of the future, after all, is a guess. But, by confirming a shared understanding of the intent of a project and doing our best to guess the investment required, we create fertile ground for ideas to evolve and sensible investment parameters against which to track progress. 

Since we don’t know exactly how each idea will develop, we need feedback every step of the way. In order to get feedback, we need to show our work early and often. Feedback may uncover your mistakes. It may highlight a difference in assumptions between team members that needs to be hashed out. Or it can simply make the handoff of your deliverable go more smoothly. Feedback can also be wrong, and that’s OK! After discussing feedback, the team can reach a point of shared understanding…at least until the next review session.

For this to work, management must create and protect a safe environment for feedback, and set the expectation that no one is exempt from giving or receiving it. Care must be taken to ensure that feedback flows politely and professionally. Free-flowing feedback assures that each delivery of an idea—each metamorphosis of a requirement from a brief, to a proposal, to a prototype, to a Figma design, to a release candidate—is a more considered, more articulated version of the idea, culminating in the developed product.

Invest yourself in outcomes beyond your own deliverables

Frequent delivery is great—and it can save us the trouble of trying to consider and document every requirement before we start building—but it doesn’t work if artifacts are created in discipline silos. The Agile Manifesto favors customer collaboration over contract negotiation. Customer collaboration is so effective because it enables frequent feedback from the project owners, reducing or eliminating “back to the drawing board” moments. For everyone to have ownership of success, each member of the team needs to take an interest in their colleagues' work, across disciplines…sort of like each team member is a customer.

For instance, if you spot an issue in someone else’s work—even outside your discipline—you’re on the hook to do something about it. Regardless of your job title, you have to make sure the issue is either addressed right now or captured in a reliable system for future resolution. If you don’t, you’re complicit in reduced overall quality. Perhaps you can fix a typo directly in the copy deck and let the team know in Slack. Or you can leave a comment in Figma. For a live defect, you could create a ticket in GitLab, or—if you don’t have access—you can tag the project manager in the project Slack channel to make sure the right eyes are on the problem.

Welcome new information, even if it means plans have to change

Perhaps no ethos captures the spirit of Agile, indeed of agility, more than “responding to change.” A plan is not a business goal; it is an educated guess at a feasible approach to achieve a business goal. It’s a common mistake to focus so intently on following a plan that one loses sight of the reason a project is happening in the first place.

Imagine, a few weeks into a website development project, the chosen CMS vendor announces that their product will be discontinued in 12 months. The team could continue developing on that platform, sticking to the plan. After all, that would be the fastest path to launching the website. However, the business cost of replatforming again—in less than a year—must be considered. While it certainly isn’t good news, the impending demise of the CMS product is useful information that should be welcomed and discussed—likely leading to a significant change of plans.

There are so many things you can’t plan for. A competitor might launch a similar product before you’ve released yours. Corporate leadership might increase (or decrease) your budget unexpectedly. An executive may deliver non-negotiable feedback late in the game. A successful process has built-in mechanisms to change the plan. There are so many ways plans can change, but here are a few:

• Updating the backlog: adding, removing, changing, and reprioritizing features.
• Adjusting the project plan: updating a Gantt chart to reflect realities and new, better information.
• Delivering faster: finding a way to release a product sooner by focusing on essential features.

One goal of Agile is that, when things change—or when reality differs from our educated guesses—we don’t have to go back to the drawing board. The more prepared we are to change the plan, the less of a show-stopper it is when something unexpected happens. If mechanisms for change are built into our internal processes or written into our contracts, we can keep moving forward.

Being Agile today

The authors of the Agile Manifesto had it right: no amount of documentation and planning up-front is enough to make a project go smoothly. As Robert Burns penned in 1785 (roughly translated from Scots), “the best laid plans of mice and men often go awry.” The goal of Agile is not to give us better plans; the goal of Agile is to achieve better business outcomes and make our jobs more fulfilling. All of us can reach those goals—and call ourselves “agile”—by collaborating intelligently and keeping our eyes on our shared goals.

In twenty years or so, we’ve gone from a world in which the vast majority of people were dependent on the wizardry of a few, to a world in which every single one of us creates digital experiences. As non-programmers became more comfortable interacting with computers, and as the software behind digital experiences (like content management systems) improved, tasks that once required The Programmers could be picked up by other team members. These tasks became new disciplines. “UI designer,” “content strategist,” and “SEO specialist” became common job titles, and tasks like publishing and unpublishing content often required so little technical knowledge nearly anyone could be assigned to them. Meanwhile, The Programmers—having gone from being responsible for user interface design, content entry, SEO, analytics, managing servers, and so much more—were freed up to focus on their specialty: writing code.

The Agile Manifesto was written by software engineers, for software engineers and “the customer.” The Manifesto of Inclusive Agile is for software engineers and the customer…and the UI designer, the strategist, the SEO specialist, the copywriter, the data analyst, the project manager, and everyone else who contributes to a modern digital experience.

Have something to say? Join the conversation on Medium. Interested in working with a team that embodies inclusive agile? Reach out to us using the form below.