Improving Personal Agility

The notion of agility—that is, moving quickly and easily—can conjure up some very good mental associations. We think of cats as being agile, and for the most part, that seems to be a good thing. We also think of some organizations or companies as being agile, especially if they offer products or services in a timely fashion. And when we see athletes, like gymnasts, basketball players, and baseball players, we often notice their agility and marvel at their performances.

In the IT field, we have been using the word agile for a long time now. The Agile Manifesto, written and initially signed by seventeen software developers in 2001, represents a critical moment and an enduring rendering of what agile means in relation to not just software development but also other forms of IT and non-IT work. At the heart of agile, as a method for organizing work, lie four main points:

1. Iteration: Use shorter repetitions of bundles of activities.
2. Small teams: Rely on teams of preferably ten or fewer within iterations or sprints.
3. More inclusive teams: Involve the users, not just the creators, of the thing designed.
4. Concrete outcomes: Rely less on contracts and formal documents and more on outcomes or objects that can be better validated.

Surrounding this core of agile organizations is a coterie of practices that go by many names, like Scrum and Kanban. These practices emphasize different aspects of the four points noted above and highlight the need for timely, close, and corrective collaboration between people. As such, for me at least, they reinforce the human social psychology at play when teams tackle complex endeavors.

Agile methods have been discussed and taught and incorporated into many practices over the past two decades. However, far less attention has been given to the notion of personal agility. Personal agility is a method of structuring one's thoughts in an iterative fashion with at least two parts in each iteration: (1) the mental creation of the thing proposed, and (2) the continual validation of the conceptualization. This personal iteration constantly visualizes the thing being constructed and put into use. The mental simulation helps to identify where the thing can be improved. Managers, coaches, and players in sports have intense focus on personal agility as well as team agility. Athletes undergo extensive and continual training to improve their personal agility. While we expect students in a college or university setting to complete a similar type of mental training in their educational studies, students (and working professionals) do not typically undergo structured practice in improving their mental processes.

Within the cognitive science discipline, for the past few decades, scientists have been researching the role played by mental rehearsal, simulation, and visual imagery in solving problems, coping with stress, and regulating behavior, as well as in optimizing how people can be trained to improve different aspects of cognitive skills through practice. While each of us is born with different mental abilities, most if not all of us can improve these skills. What follows here are my thoughts based on my doctoral training and ongoing study, my continued practice in the IT field over the past 35 years, and perhaps more interestingly, my 30 years as a martial arts instructor—with a portion of that time spent with professional athletes, trying to improve not only their physical skill but also their mental approach to their work.

Structured Mental Iteration

This mental iteration process is a structured one, not completely free-form or ad hoc. The creation process takes an idea, a proposition, or a desired creation and moves it from a dimly described thing to something that can be more easily validated by the person creating it. What can this structured mental process consider? Well, anything from "How am I going to tackle this bit of code to move data from our core enterprise system to our analytic environment?" to "How am I going to create a project plan for implementing our new cloud-based security project?" to "What steps do I need to take to get this project through governance?"

At least three mental tools are needed to manage structured mental iteration:

1. Progressive ideation, in which the idea gets mentally simulated over and over, sometimes over the course of days, months, or even years—with each iteration adding details and increasing the fidelity of the idea.
2. Progressive concretization, in which the idea gets converted from abstract concepts into more concrete ones. This is accomplished by imagining the idea as a physical thing or by simulating actual use of it in a detailed manner. Again, concretization can be done iteratively and progressively.
3. Continual validation, in which one explores the implications of construction and use of the idea proposed. Here the person doing the simulation challenges the idea with potential common-use cases and less common corner cases.^Footnote1

To progressively simulate well, one has to use not only the right tools but also the right medium at the right time to conduct thinking about the idea. The media can include

1. the mind,
2. more than one mind (two to three),
3. a pencil and paper,
4. simple renderings in simple modeling tools,
5. more elaborate renderings in more elaborate modeling tools, and
6. development of a prototype or a runnable instance of an aspect of the solution.

Perhaps the most underutilized method for structuring an idea is to simulate the actual construction and use of the thing in one's mind—in short, to visualize it. For athletes, visualization is a critical tool that causes them to recruit and prime the neural circuits that contribute to performance. By visualizing, athletes are doing a form of both learning and performance priming, which can improve their actual performance. Through continued mental rehearsal, they are becoming familiar with the problem and the performance—ahead of the actual performance. Their minds are learning, more deeply, portions of the performance. Visualization cannot replace physical performance, but it can, and does, enhance performance.

The same process is valuable for anyone who brings thoughts to life. Spending adequate time in structured mental iteration (ideation, concretization, and validation) can enhance follow-on design and the actual construction and use of the thing simulated. By progressively simulating using a structured approach, creators can improve their understanding of the thing in question by using a medium—the mind—that can work more quickly and with less delay than any other. In short, using the mind carefully enhances the use of other media (pencil and paper, small teams, renderings, prototyping). This mental simulation reduces IT rework since it tends to push rework to much earlier in the overall construction process and to the least expensive part of the process. This structured mental simulation is progressive, meaning that it is not done just once, but continuously, becoming a form of mental rehearsal where with each rehearsal, the idea improves.

When I discuss structured mental iteration with colleagues, one of the first reactions I get is, "This makes my brain hurt!" It does, and it should. When simulating in your mind, you are forcing your neurons to learn new associations and new pathways, and that requires effort. About one-fifth of our caloric budget is dedicated to the central nervous system; thinking deep, hard thoughts does burn more calories. But with repeated practice, the mental effort reduces significantly. In fact, scientists measure expertise in a mental task not by how much energy experts use in the mental task but, rather, by how little energy they use. Experts require far less energy than novices. The purpose of mental simulation is to move yourself from novice to expert performance more quickly than would happen by waiting for the next meeting or interaction with colleagues.^Footnote2

A benefit of mental simulation is that you can exercise your simulation in all sorts of places and times that you would not otherwise use productively. I have long used train trips, car rides, and times before and after sleep to mentally simulate a proposition. Each day I pick up the simulation where I left off, and then I go into more detail, more scenarios. I am not alone in doing this. Some call this daydreaming or getting lost in your thoughts, both of which often have negative associations, which is unfortunate. Much of our mental life is occupied with these forms of small obsessions that, if better managed, would give us better mental lives.

The other benefit of mental simulation is that it can occur months or years ahead of the need for the thing being proposed. Most of the time, what looks like sudden changes thrust upon us (e.g., new technology systems and new functionalities that must be deployed) have a point of origin that precedes the actual work by months or years. Good strategic planning can call out those areas well ahead of time, giving ambitious practitioners a good head start in becoming expert in the things that may need to be designed. Expertise can grow in two ways: by learning new skills; or more importantly, by simulating those skills in the mind ahead of actual use and again during and after implementation.

Choosing the Right Medium

As noted above, structured mental iteration can be greatly aided by the timely and clever use of the right medium. One is a colleague's brain—that is, using more than one mind. When one is simulating a concept mentally, quickly bouncing an idea off a colleague can be helpful. Today's collaboration and communication tools are excellent for just this. The collaborations need not be synchronous. A little bit of asynchrony goes a long way. What is required is an organizational culture and structure that facilities point-to-point and just-in-time collaborations to support mental simulations. When enabled, individuals can rapidly improve the fidelity of their simulations.

The perhaps simplest medium is one I often prefer: a pen and paper. Eager practitioners can make a common mistake here. They jump ahead to the rendering and modeling and prototyping. They use fonts, colors, shapes, diagrams, and other gadgets. This premature elaboration creates a kind of distraction that can pull the mind away from the critical elements of the simulation and into unneeded trivia. It takes time that should be spent mastering the difficult piece within the simulation. (At one point in my CIO career, I forbade my staff from using anything but Microsoft Notepad to describe a business process. Too many fonts and fancy documents were getting in the way of clear thought.)

At this point in a simulation, the circle of minds can expand to include more than just the one colleague for bouncing off ideas. Simulations can be done in teams. One person takes the first stab, a second adds to the simulation (usually concretized in a simple office tool like a spreadsheet or a word-processing document), and the cycle commences. This is similar to artistic creations in which artists contribute in an iterative fashion to the completion of the piece. Again, it is best to use the simplest of tools so as not to get pulled into a tool-induced attention deficit disorder.

With each iteration of the simulation, a portion of the simulation—perhaps at least half of it—is focused on answering the following questions:

1. Specifically and precisely, what steps would someone take to create this?
2. What are the subcomponents of the thing? Are they described sufficiently? What is missing?
3. After mentally simulating the aspect of the thing created, what are the implications of the thing on other parts of the proposition?
4. How might the thing fail?

Half of the simulation iteration should be spent on numbers 3 and 4, the validation aspects. This is harder to do early on, but with iterative concretization, validation becomes easier. Making things concrete facilitates validation. When an idea is made concrete, the mind more easily recalls the idea, associates it with prior knowledge, and importantly, identifies where the idea may have faults.

At this point in the simulation iteration process, the chief objective is that many other users and many other questions are necessary. I challenge this perspective. If the right person is doing the simulation, this person and a small number of other people typically have sufficient background knowledge to give the simulation a fair run. The simulation will be sparse at first, but with an early start and adequate time, these people can enrich the simulation with just-in-time answers to questions from the right people who have knowledge relevant to the problem. The challenge I give teams is to answer the following question, "Is this the first time any human has solved this problem?" Very rarely will the answer be yes. Far more common is that the knowledge for how to properly conduct and enrich the simulation is simply not accessible to the individual or the organization.

What teams need, then, is access to the other people who may have already solved this problem or something similar to it. Researching through the internet is an exceedingly good way to find answers to questions, perhaps an even better way than using consultants. But to support progressive simulation, people need to have the time (and the desire) to be curious. Through good strategic and project planning, IT leaders should find ways to let teams use the calendar and their own work time to advantage. The inability to generate rich mental simulations is directly related to the lack of time felt by so many people. When you cannot properly simulate a better future state, you are forced into a series of suboptimal improvements. Setting aside time lets you incrementally build a future state with the express purpose of creating more time for more simulations.

Concretizing: Making the Simulation Real

When one or two people are participating in a progressive simulation, they need to constantly pretend, imagine, or visualize that the thing being proposed is running in the imagined future world and with imagined users interacting with the thing created. The mental visualization or simulation needs to have high fidelity, which means it should have enough detail and mental richness that it is approximating its future physical form. As the simulation becomes more concrete, documented in simple tools or even partially prototyped, more minds can be brought in to enrich the visualization. But the visualization first needs enough specificity and concreteness to give the illusion that it is real, even if it is not. Why? For a simple reason: documented fiction is much more powerful than undocumented fiction.

And why is this? When another person more knowledgeable of a specific aspect of the proposition looks at a concrete simulation, that person will more quickly find flaws in the simulation. It is mentally easier to point out where a design is flawed than to discern where a design may be missing something. Rather than leave the design or simulation blank, the creator of the idea can fill in the missing piece with a best guess, even if it is in error. This quick identification of errors through concretization improves validation as well. The less abstract the idea is, the easier it will be for people to validate the idea. I have often deliberately seeded my early simulations or designs with made-up stuff because asking an expert to respond to flaws is easier and quicker for the expert than looking more comprehensively through the design and identifying missing elements. I have also discovered that much of my fiction was closer to reality than I initially thought.

The main goal for performing simulation is to take an idea and mentally construct it, first in abstract terms (e.g., in order to get data into our data lake, we are going to need different data movement tools) and then in more concrete ones (e.g., we will need to read JSON from streaming services, parse the JSON quickly, and place it in regions of our data lake). Finally, the idea should be mentally constructed at the level of granularity for actual implementation (e.g., we need to take this fragment of a JSON string using our data movement tool, separate the components of the JSON, and place them in the following specific location in our data lake). Often very skilled IT workers will stop the simulation at a level that is too abstract. Instead, each iteration of the simulation should continually pull the idea down to bare-knuckle reality.

This may seem to be separating logical from physical design, but that is not what is going on here. The mental process is always aiming the simulation at physical design (and/or prototypes) where the distinction between logical and physical design is no longer as useful. We are starting designs with as much concreteness as we can right away, using abstraction as an early-stage throw-away scaffolding to get us to a more concrete representation, just like scaffolding that helps in the construction of a building. In some cases, people can do logical design at the same level of specificity and granularity as physical design, and as a result, the simulation effortlessly passes into construction.

Even the most complex of systems can be improved in this progressive concretization approach, which is very similar to what civil engineers do with their building designs. In IT designs, we often let the plasticity of the tools and the ease of last-minute changes during construction be an excuse to allow shoddy thinking earlier in the process. By contrast, the goal of moving rapidly to concreteness in progressive simulation promotes richer validation.

Involving Others in the Simulation

Generally, people fall into two categories in the approach to progressive simulation. People in the first category are "blue-sky thinkers" who have little difficulty dreaming up new (and often irreverent) ideas but who don't always clearly see the implications of their designs. They often simulate their designs in a world that is more perfect than the messy world we actually live in. People in the second category are "scrubbing bubbles" who effortlessly point out the ways the design won't work. For blue-sky thinkers, people in this second category can be painful to engage, like cleaning products that come into contact with your skin and sting a bit. But the scrubbing bubbles well understand the many human and technical constraints and are good at the validation portion that is heart and soul to being agile. They are constraint-based reasoners who can, and frequently do, improve designs.

The trick is not to engage one group over the other but to know the correct order of engagement. It is hard to get a good design out with just constraint-based reasoners, since the simulation process will trigger all sorts of objections and cause a failure to fully consider novel solutions. But it is also hard to bring a concept into reality with just blue-sky thinkers, since the resulting designs will overlook messy organizational or technical details.

In the ideal process, blue-sky thinkers will dream stuff up as detailed as they can and then iteratively include the constraint-based reasoners to further validate the design. This uses each person's unique simulation capabilities at the right point in time. A fancier way of saying this is that failure-mode analysis, deep domain expertise, and risk management thinkers should be brought into the process shortly after the designs have been sufficiently simulated and concretized. Starting with the blue-sky thinkers and then engaging the valuable constraint-based reasoners not only provides better validation early in the design process but also productively utilizes people's different emotional-cognitive abilities.

Involving others in the simulation is a highly gradated transition from a single-mind to a team-based process. If the total team is small enough, knowing where the single-mind process begins and ends might be difficult. But as the simulation progresses into the team-based approach, common agile methodologies can take over. Many practitioners prefer team-based methodologies because they're able to use the quicker, less effortful, and more heuristic processes we all use in social settings. Real-time group problem-solving involves less effort per person than the solitary confinement of a single-mind simulation. Yet it is a mistake to ignore the power of the mental effort involved in single-mind simulation and the knowledge enrichment it causes. Difficult learning does require a pretty hefty personal cognitive effort, but as individuals enrich their simulation progressively, they learn—more deeply and more quickly—details within the problem. In time, they will reason about this problem in more heuristic, less effortful ways, just like any other expert.

How much advance notice should be provided to properly allow for sufficient mental simulation? My own job as a CIO involves planning over longer time horizons. For example, my IT Services team at the University of California San Diego (UCSD) knew six years ago that we were going to be moving from on-premises business solutions to cloud-based applications and platforms. This gave us the chance to explore both big and small solutions incrementally over time, rather than in an overly compressed timeframe. Ideally, and for the more critical aspects requiring high-fidelity simulation, front-line staff should have a one- to two-year notice that certain skills will be required and that certain problems will need to be solved.

Another question involves how to know when things aren't being simulated properly. When ideas are not simulated properly, they are more likely to take longer to create, and once created, they are more likely to have errors or omissions. Over a longer timeframe, the solution has a greater chance of not being easily adaptable to changes. To help address this, the IT Services team at UCSD makes extensive use of Lean Six Sigma (LSS) to improve what we do. Unfortunately, LSS is often incompletely viewed as a methodology for reducing waste in work processes, which can address rework both shortly after construction and long term. But that is not the real goal for LSS. LSS reduces waste in order to increase flow. What is meant by flow? For IT workers, flow specifically refers to the availability of information goods (e.g., data, software, solutions) at or just preceding the point of need by organizations in their competitive markets. Improving flow is the ultimate goal for LSS; hence, we need to find ways to increase flow not just between team members, but inside their minds as well.

In IT work, we frequently have rework—that is, we need to undo something we just did and then redo it the right way and redeploy the solution. On the one hand, if this is done quickly, the rework is a form of agility and learning. On the other hand, if the change or solution had been implemented perfectly the first time and had required no rework, agility overall would have been enhanced. We would not have wasted valuable organizational time. During single-mind simulations, rework by the individual doing the simulation is very desirable. This is how learning occurs, through trial and error. However, in mental simulations involving two or more minds, rework is a form of unnecessary waste.

It is clearly impossible that all things created by a single mind will be perfect. Insisting on this perfection can run counter to agile concepts of teamwork and iteration. But it is equally clear that individuals can improve the fidelity of their designs through improved thought and personal iteration. Both propositions, as contradictory as they are, need to be turned into practice inside our IT organizations.

We do know that when designs are oscillating too long or are oscillating late in a project timeframe,^Footnote3 either something is amiss with a social/team process, or the right individual is not being tasked with fleshing out a design and simulating it appropriately. Conceptualizing single-mind thought as comprising many progressively improving propose/validate cycles aligns it with the basic concepts of agile methodologies. Whereas today's agile methodologies do improve our work, they don't go far enough to reach into the mind of the individual. After all, team performance depends on individual performance, which is where personal agility comes into play.

Is Improved Personal Agility Achievable?

All of this may sound insanely impossible. It is not. In the sports industry, practitioners are now using technology to accelerate personal learning. For example, athletes and their coaches use very high-speed videography with quick feedback/validation cycles—to improve athletes' performance. Applying personal agility methods (albeit, perhaps, without high-speed videography!) can work just as well for those of us in the IT field. After all, we are professional mental athletes and deserve the same attention.

Becoming agile requires improving mental skill through rigorous practice. That improvement must come before the skill is required. In other words, investments in personal agility need to occur before the agile behavior is required—in some cases, years before. Trying to recruit better IT talent is not enough. IT leaders need to work harder to help individuals on our teams improve their mental skill. The best IT workers have already been applying personal agility through progressive simulation and continuous validation, often without knowing they were doing so. For these superstars, the skill is tacit, maybe even innate. Yet just as successful sports coaches improve the talent of all individuals on their teams, IT leaders can bring these practices to everyone on their teams, not just to the innate superstars.

Why hasn't the IT field focused on this more personal aspect of agility? I think there is a general aversion to addressing individuals' mental performance. Managers often think that this is somehow encroaching on staff personal agency and autonomy. The skill sets needed to do this "coaching" are often not found in the typical IT manager or, quite frankly, in managers anywhere. "Social methodologies"—that is, methodologies used to direct employees' behavior through external process manipulations—are more convenient and socially acceptable. By moving people around or hiring new staff, we look like we are adopting improvements. In a sense, we have been trying to do what professional baseball has done by using a form of sabremetrics in which we select talent based on the skills in the résumé (in the case of baseball, performance statistics in the past) and then place staff into positions, rather than applying "betterball" methods in which we actively improve each team member we have in place.^Footnote4

Perhaps IT organizations have been using agile methodologies to coax employees into behavioral compliance so that work can be accomplished better or to give the illusion of success through the natural good feelings that come out of agile team dynamics. As a result, the behavioral compliance with agile methodologies is often not as deep as we would like. More likely, social adoption of agile methodologies is often cognitively easier. Practitioners are more inclined to delay difficult thought and work on easier things first, when for many projects, the exact opposite order is better.

Ultimately, personal agility is a mental discipline that can iteratively bind improved individual thought with improved systems to enhance organizational agility. This solitary mental discipline, when it meets with good use of organizational agile methodologies, can help us further improve what we do.

How would you challenge or validate this idea?  My curious mind is feverishly simulating.

Notes

1. A corner case might be described as "How should I design the solution to handle the categorization of the 12 records out of the 60,000 that the current envisioned solution could easily handle?" Jump back to footnote 1 in the text.↩
2. Marcus E. Raichle and Debra A. Gusnard, "Appraising the Brain's Energy Budget," Proceedings of the National Academy of Sciences of the United States of America 99, no. 16 (August 6, 2002); Longxi Li and Daniel M. Smith, "Neural Efficiency in Athletes: A Systematic Review," Frontiers in Behavioral Neuroscience 15 (August 5, 2021). Jump back to footnote 2 in the text.↩
3. We have some ways of measuring this. See Vince Kellen, "Design Oscillations: Don't 'Spin Your Wheels,'" Cutter Consortium (website), October 2, 2019. Jump back to footnote 3 in the text.↩
4. Tobias Carroll, "Is Betterball the New Moneyball?" InsideHook, June 22, 2019. Jump back to footnote 4 in the text.↩

---

Vince Kellen is Chief Information Officer at the University of California, San Diego.