Visibility Is Key

In a lean or agile environment, the concept of visible results goes much deeper. Visual controls , such as product roadmaps, scrum rooms with posted backlogs, kanban boards, burndown charts, and interruption or “detour buckets” are more than simple promotion techniques ; they are an integral element of the practice itself, and drive the improvements we seek. The visibility of the work the team has committed to, of feature cards as they move from “in progress” to “done,” and of accelerating velocity of teams as they gain confidence and skill, enables any interested party to see with her own eyes the advancement of agility. Comparisons between projected and actual performance are no longer buried in a complex set of spreadsheets or obscure earned value calculations; the facts are right there in front of the team and its leaders.

Visible results, in an agile context, are not simply celebrations and marketing campaigns; they are tools for exposing broken processes, unmet commitments, inconsistent performance, and centers of excellence. This is not to discount their importance in building momentum. It is, instead, a reminder to the agile coach or consultant that, in our lean, agile domain, visible controls enable us to show, rather than merely tell, the success stories and challenges that the enterprise is experiencing in its agile journey. Visibility is a central ingredient in the transition to agility, and skilled agile consultants use its power to keep the thrust rising against the gravity of culture and tradition.

The migration to visible controls is a top priority of any new engagement I undertake. I’m often confronted, when starting up new agile teams, with an unstructured mess of tasks, project plans, and work streams that are disconnected and unprioritized, with no correlation between capacity and commitment. Tasks, roles, and responsibilities are hidden and undecipherable. Team members are overcommitted and beaten down. Dependencies are either unknown or uncommunicated, and heroic efforts, like working all night and every weekend, are common. The basic task of explaining to me what they’re working on, and why, seems insurmountable.

In this scenario, my first action is to encourage the team to “throw it up on the wall.” If I can get the team to simply enumerate the tasks or features it has committed to deliver, even if they’re not formed as stories or features, to then categorize them roughly by customer, or project, or whatever grouping makes sense to the team, we’ve now got the foundation for the rest of our initial transition. Teams can learn, in a single backlog generation session, that their chaotic, overwhelming mess can, in fact, be sorted into something that is visible and structured. It will not, of course, look anything like a proper scrum backlog, but it is the beginning round in an evolution that can then take them to prioritization, to effort-based sizing, to release and sprint planning, and to individual and team commitments.

A “show up and throw up” session, which typically creates a wall filled with undifferentiated tasks, projects, and features, can now be used as the basis for some grooming sessions that give agile aspirants the opportunity to learn by doing, rather than by lecture, and to show them how quickly simple visibility can have an impact. My first question when confronting an unstructured backlog with a new team is, “How can we sort and prioritize these?” Unfortunately, I frequently encounter teams whose work is so atomized that each member only sees his little piece, and the team has no visibility into the connection points, let alone the project vision. Including a product owner at this stage is critical. In many environments, only the business representative understands the vision of the overall product, and the manner in which the pieces integrate into a whole.

Every Picture Tells a Story

Categorization schemes can vary all over the map, but I’m primarily interested in how they fulfill a vision or roadmap. If time or feature commitments have been made to the business customer, the product owner can begin to articulate to the team how the pieces fit. A skilled product owner, whether her official title is Sales Executive, Delivery Manager, or Business Technology Liaison, should be able to help teams understand not only what’s been committed but why. It seems like working backward, in the sense that agile teams will usually start with a vision, then create a roadmap, and build a backlog from there. In teams that are new to agile, however, it’s unlikely that the agile advisor will walk into a greenfield. Even if we select a pilot project, my experience is that the project selected often comes with preconceptions, precommitments, and historical baggage that require untangling before a real agile effort can begin.

We start with the understanding that the concept of visible results has two meanings in agile: the visibility of success , in order to build enterprise momentum, and the visibility of the actual results of our work, so that accountability, status, progress, and value delivery are all evident in simple, readable form available to any interested party. The celebration and promotion of success lends credibility across the enterprise, but the visibility of backlogs , burndowns, “detour buckets” (lists of interruptions or other detours that impede the team’s progress), obstacles, and other visual controls, are the mechanism of change. Agile is reality-based, and when the reality is visible to all, hiding places and broken processes become, well, visible, and subject to improvement. When the plan and progress are hidden in some spreadsheet or project plan that is available and decipherable only to a select few, we’re back in the world of a product priesthood, with supplicants begging for information about the status of their work.

In sophisticated lean manufacturing enterprises, like Toyota, the number of visual controls can become overwhelming. Lean manufacturing facilities make visual charts for everything from “job by job tracking” to “priority-based hourly status charts” to “visual control for progression of work through an office process.” When manufacturing intricate products with life-or-death implications, this granular tracking of everything from parts to documents makes sense.¹

In agile we try to “maximize the amount of work not done,” and so we tend toward the least number of visual controls required for the work at hand. If we’re developing software to control automated braking on an automobile, we may have to behave like a manufacturer and track every detail. If we’re building an app that lets users simulate tossing a wad of paper into a trash bin, not so much. The level of visual control should adapt to the project at hand, but it should also reflect the maturity of the team. For beginning agile teams, visual controls that display the product and sprint backlogs, the blockages and impediments, the progress from work-in-progress to completion, and the beginnings of a burndown chart (even if we’re only counting items moved from backlog to done) are essential, but the visibility of a “detour bucket” of interruptions, or the introduction of individual kanban boards for certain members, might also be useful. As always, we inspect and adapt our use of visual controls to the situation at hand.

One of the traps of visual controls , especially in traditional or formal organizations, is more emphasis on the look of the charts than on their utility. I’ve attended countless debates about whether charts should burn up or burn down, for instance, or whether all kanban boards in the organization should have the same columns. This misses the theme completely; visibility is designed to stimulate action, not to look pretty. Charts that demonstrate whether improvement and progress are being made are not ornamental; they expose action or inaction on the migration of culture and behavior. I don’t care if teams burn up or burn down. My question, especially with rookie teams, is whether they are burning at all. Detour buckets have no meaning if no effort is made to lessen and eventually end unscheduled interruptions that impede sprint progress.

In many enterprises that have yet to accept agility, a core problem is the disconnection between capacity and commitment. Sales teams and client managers are incentivized to go out and sell more and more, with ever-rising quotas and associated compensation. This encourages the executive and sales teams to push product or projects out to customers, with no visibility or correlation to the actual capacity to deliver. Sales teams make commitments that have no relationship to the delivery team’s capacity to deliver, and get rewarded for doing so. Because sales and delivery are often siloed, if not actively feuding, delivery objections to unrealistic commitments often sound like mere grousing. Visual controls give product delivery teams the ability to come to the conversation with data. If, for instance, a long-term burndown chart demonstrates that teams have capacity to burn through 200 story points in an iteration, and sales commitments add up to 500 story points in that period, the disconnection becomes visible and data-centered, rather than just some narrative that “we’re always overloaded.” “Complaint without data is whining” is a common management theory, which the adherence to a visual control discipline can disarm.

No Blame, No Shame

Traditional organizations are often prone to using data to chastise and punish, rather than to improve. Beginning agile teams are often reluctant to make their commitments and results visible, in fear that their managers will then use performance against plan as an opportunity to hector and scold rather than as an indicator of process or management failures. In command enterprises, where dissent and “excuses” are discouraged or punished, the tendency to sweep issues under the rug, and to protect managers and blame employees, is ingrained and powerful. Agile consultants need to apply some of the Zen attributes I’ve encouraged, and realize that these inclinations will not disappear overnight. We need to display the agile mind-set to which we hope to guide the enterprise. “No blame, no shame” must be our guiding principle in every interaction, and we must role-model thoughtful root cause analysis, and select appropriate improvement efforts based on the organizational reality. It’s easy, as an immature consultant, to get frustrated with broken processes, punitive managers, and “blaming and shaming” as a management technique. The simple discipline of visual control is the best mechanism for incrementally discovering and exposing counterproductive practices. By taking the emotion and speculation out of the conversation, visual controls (eventually) make it obvious that improvements are necessary, even if they rub leadership the wrong way and discourage comfortable blindness.

With all the preceding warnings, it may sound like visual management is too much of a hassle to be worth doing. Despite all their possibilities for resistance or misuse, visual controls, or, as they are often called in agile, information radiators, are indispensable for true agility. Visual controls that are easily legible, even from afar, that use physical representations, like scrum cards, that use color to indicate different states, and that are as simple as possible to interpret, quickly establish their value. Most project or product teams are accustomed to tiny lines on a project plan, or to an unconnected series of e-mails instructing them to prioritize this task over that, rather than a shared, visual work control system. Managers also value detailed spreadsheets containing hundreds of granular details that are usually privileged information, shared only within the executive suite. When these are replaced by multicolored scrum cards on a wall, it takes some getting used to. As Toyota and hundreds of other lean enterprises have demonstrated, physical tokens on the wall, easily read and interpreted, are much more likely to result in behavior changes and process improvements than are lines on a screen.

You may have noticed that I’ve stayed away from the term metrics. That’s deliberate; metrics is old-school language, bringing up the ghost of punitive performance reviews and unhelpful comparisons between teams and individuals. I prefer the language of visibility, by which we uncover and improve on defects and deficiencies in the process and culture, and celebrate successes that all can see, rather than dry measurements that threaten and divide.

Visualizing the queue of work that has been committed is the first key objective of visual management. Queues are often invisible, residing in a salesperson’s forecast or a “top secret” portfolio management system, until they suddenly become urgent as their due dates approach. Beginning agile teams consistently tell me that their queueing system is “the sales guy sells something, puts it into his forecast, and then runs down with his hair on fire when he realizes the date is near.” Delivery teams will frequently hear through the grapevine that some major project is on the horizon, but they won’t get the details until it’s too late for them to plan and prepare. In other words, the organization’s lack of a disciplined queueing and work control system creates a constant state of emergency for the delivery team.

By helping teams institute visual controls, we empower them to begin resisting ad hoc requests, to stay focused on the commitments they’ve made for the current iteration, and to self-manage their work flow. From scrum cards, easy to move and reprioritize, to kanban boards that clearly illustrate the work-in-progress stream, teams have not only made their successes visible, as cards move to the “done” column, but they’ve also been empowered through visibility to make a data-centered case for resisting interruptions and distractions. “Your lack of planning does not make my emergency” is a cute saying I’ve seen on many office coffee cups, but, with information radiators, teams now have the capability to walk their colleagues up to the wall and help them understand why that is true. As usual in this book, I won’t be going into the technical details of how and when to apply visual controls, as any agile consultant should be familiar with the mechanics. For a more detailed breakdown of the granular techniques of visual controls, or information radiators, there are plenty of resources online.²

Every organizational change methodology emphasizes the importance of promotion as a potent method of enhancing momentum. Way back in 1995, John Kotter called the lack of short-term wins, and of their visibility, one of the top ten reasons for failure in organizational change . Importantly, he stresses that we’re not just hoping for successes³; we’re actively making the quest for short-term wins, and promoting them in a structured manner, like a campaign. This makes the quick development of visible controls critical; without data, success promotion is just talk. It also places the burden on agile consultants to be judicious in the selection of projects for pilots or first-time team efforts. Taking on behemoth, previously unsolvable problems the first time through an iteration is probably not wise. Agile advisors should make sure that the work teams take on early in the transition includes some “low-hanging fruit,” some elements that the team can deliver successfully, and that can benefit from an agile approach quickly. Prioritization of backlog items must be judicious, not only driven by the customer’s perceived urgency but also by size, complexity, and visibility. If the team has to work through a multitude of iterations before delivering anything of value, we’re not far from the dreaded “we tried agile; it didn’t work” conversation.

A promotional campaign for organizational change should be structured and planned, and not consist of random acts of visibility. The successes we promote must have meaning to the organization; very few executives or associates will care that we ran regression testing on 49 new builds. If, however, that regression testing led to higher-quality products and delivered to customers faster and with higher satisfaction, that will garner some attention. I’m an advocate of a campaign that builds slowly, as the teams become more adept at agility, since early attempts will include as many failures as they do successes, and our visibility makes those apparent as well. As teams gain confidence and skill, the number and importance of our successes will grow, and the promotion of them will be increasingly persuasive. Persuasiveness is the key; the successes we promote would not just highlight the content of what we built but the importance of the agile practices we used to get there.

It’s great when leaders call out the successes of agile teams and practices, but it’s even better when the team stands up and describes its experience, from initial reluctance and trepidation to acceptance, mastery, and triumph. One of the indicators I like to track is simple team happiness, on a Likert scale. I ask team members to rate their happiness, not just with agile, but with their organizational life, on a whiteboard, with a simple 1-to-5 scale, and track that over time. Making increasing happiness visible is a powerful persuader. Everyone wants to be happier in their work, and every progressive manager should value team satisfaction.⁴

Other promotion techniques include “agile safaris ,” as recommended by Mike Cohn⁵, in which teams that have not yet experienced agile sit in with an agile team and watch them work, and scrum room tours, in which agile teams walk their managers and associates through the scrum room and explain how the visible artifacts help them achieve their objectives. E-mails, newsletters, and banners are far down on my list; they smack of the multiple failed change campaigns that every enterprise has experienced, and become mere background noise to already skeptical associates. In lean and agile, teams don’t want to be lectured or mandated; they want to observe, experience, and learn. They want to be persuaded, not hectored.

The obvious success of lean manufacturing and lean enterprises, with their abundant use of visual controls, illustrates beyond debate that these methods work. I want to emphasize that visual controls are only one element of the lean or agile enterprise. If they don’t stimulate corrective action, they are ornaments, destined to turn dusty and forgotten in some remote corner. The agile consultant has the unenviable job of highlighting the dysfunctions and disconnections that these visual artifacts expose, and guiding teams and leadership to act. The results of visibility are far reaching; they shine a light on, for example, broken sales intake processes, invisible queues of projects, absent or erroneous prioritization schemes, and myriad other flaws in the culture, value stream, and process chain. As noted previously, there are players in every enterprise who make their living hiding in the cracks and aren’t thrilled when those cracks are repaired. The skilled agile consultant doesn’t only encourage teams to use visual controls to track their own work; she also works across the enterprise to help the entire organization recognize and address the problems they reveal. This is a distinction between agile coaching and agile consulting. Practice-focused agile coaches can help bring teams toward agile methods, while agile consultants focus on the holistic picture of the entire enterprise, and have the consulting skill and experience to diplomatically and persuasively propagate the agile and kaizen mind-set throughout the enterprise.

Summary

Visibility and transparency are central to lean philosophy, and drive many of our agile practices. The scrum board, with its categories of visible tasks, the burndown charts that show our progress as we go, the retrospective insights that we collect and post—all of these are visible so that action can be taken in real time and there’s no hiding place for dysfunction. We transition to agile when the hidden dysfunctions bred within our culture, processes, and relationships threaten to overpower our ability to succeed. By bringing failures and issues to the light, we drive improvement. By making success visible, we drive momentum toward agility.