BT

InfoQ Homepage Articles What Exactly is the Agile Mindset?

What Exactly is the Agile Mindset?

Bookmarks

Key takeaways

  • Remembering key themes makes using agile more beneficial; these combine into what many call the agile mindset.
  • Defining the term “agile mindset” is difficult. Many agile practitioners use it without really being able to define it.
  • I propose that the agile mindset includes the following themes: respect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change.
  • Teams can use agile practices without the agile mindset. But it’s the mindset, these themes, that transforms groups into high-performing teams, delivering amazing results for their customers.
  • Identify how to nourish and cultivate the agile mindset.

 

If an executive who doesn’t know the first thing about agile asked you at a company reception to define what it means to have an “agile mindset,” could you do it before he drains the last swallow from his glass and wanders off - and it do clearly enough for it to stick even if it is his second drink? What would you include, and how would you hit home the need for cultivating that mindset? I’ve challenged myself to find that summary, and here share both my journey and the final results.

Through my career as a developer and Scrum Master, I’ve worked with many different teams and organizations, and attended a variety of meetups and conferences. Many times, I heard of the importance of the “agile mindset.” I’ve even used the phrase myself. But when I think about defining it, in a precise and clear manner, I’m stumped. I get it, but not well enough to define it for others. That’s a problem. I’ve worked with teams that understand the process of scrum well enough, and even get some of the agile principles, but the mindset isn’t there yet, so that’s where my training and coaching often needs to be focused. Getting the mindset right is what moves teams to high-performing, a level of performance that Ken Blanchard and Lyssa Adkins both describe with terms such as “optimal productivity,” achieving “astonishing results” and “a team that can do anything.”

To some extent, it seems that the agile mindset should simply be: “The set of attitudes and beliefs supporting an agile work environment, so that teams can become high-performing.” That’s okay. But far from sufficient. It is too vague to provide a map of how to get to that state, or to simply assess the current status and determine targets for improvement.  

One of my mentors challenged me to be ready to define an agile (or scrum) term in 30 seconds or less, without using the word “agile” or other agile terms to define it. He put it this way: “Suppose a new executive has started at your company, and is heading down the elevator with you. She asks you to define something that we in the agile community take for granted. How would you define it?” So, the elevator definition of the agile mindset can’t just be “the set of attitudes supporting an agile work environment.” There needs to be more meat to it, especially if this exec doesn’t really understand agile. Otherwise, I’ll just leave her scratching her head, and wondering what value the agile coach, and agile in general, brings to the company.

Certainly, one could defer to the manifesto and principles. I might be able to summarize all that in 30 seconds. But what about the pillars of agile, according to Jeff Sutherland and Ken Schwaber? What about the scrum values? Alistair Cockburn’s Heart of Agile? Additionally, there are the influential works outside of the agile community describing what makes a great work environment, and why staff are motivated to work in such environments. Dan Pink’s Drive, Carol Dweck’s discussion of the growth mindset, Patrick Lencioni’s fables, the concepts behind leadership styles, and Jurgen Appelo’s books and games on management come to mind.

There are so many possibilities. You couldn’t possibly describe them in a 30-second elevator ride. I could (and sometimes do) talk about such topics for days on end!

I have sometimes consulted at companies making a transition to agile; many in these organizations wonder if it is just jargon, a style du jour, or games and gimmicks. I have therefore wanted to work out a quick way to convey the themes of agile evident across these foundation documents. Just as my mentor had challenged me - what’s a 30-second definition for an agile mindset?

I wrote out the statements from the Manifesto, the Principles, and many of the other concepts described above. Then, I summarized each with a word or phrase. Value, collaboration, learning, change, respect, value, PDCA cycle, collaboration, inspect and adapt…. I noticed some themes that appeared multiple times. This group of ideas, this way of approaching work, is what I can use to define the agile mindset.

I propose the following:

An agile mindset is the set of attitudes supporting an agile working environment. These include respect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change. This mindset is necessary to cultivate high-performing teams, who in turn deliver amazing value for their customers.

Now, if this executive that you were chatting with wanted more information, you could, perhaps, dive deeper into these qualities or attitudes:

  • Respect - Most teamwork needs to start with respect for your fellow teammates. At the organizational level, respect for colleagues at all levels of the organization, the customer, and the product itself is also key to maintaining an appropriate work environment.
  • Collaboration - With increasingly complex systems being built, and subsequently complex problems being solved, no one person would be able to hold all the necessary information in their head to complete a task. Additionally, working with other parts of the organization in a collaborative way will decrease the number of handoffs necessary to deliver. The facilitation of collaboration, through tools, office space, and behavioral norms, can improve the quality and number of collaborative discussions.
  • Improvement Cycle - No process should be written in stone. There is always room for improvement. An organization supporting such behavior would have a light hold on procedural adherence.
  • Learning Cycle - Allowing individuals to try something new, and yes, possibly fail, gives the staff an opportunity to learn and improve themselves. Individuals should not be dinged for mistakes, but rather supported for taking risks and increasing the group’s knowledge.
  • Pride in Ownership - Even if no one person owns a particular piece of code, pride in what is delivered increases the desire to deliver high-quality work.
  • Focus on Delivering Value - The main point of an agile team is to deliver value to the customer. The team should be able to focus on what is of greatest value at the time, and deliver with the knowledge that others in the organization (managers and scrum masters, for example) are there to help remove any impediments.
  • Ability to Adapt to Change - If the customer calls two hours after a meeting, and wants changes, the organization rolls with it. Any process to manage this change can’t be an impediment to the change.

This mindset is the environment within which agile teams flourish. It isn’t a prerequisite for an agile adoption, nor is it required for a functional agile team. But if this mindset is cultivated and nourished, whether before, during or after agile adoption, the teams (and therefore the company) will experience amazing results - happy employees delivering great value and making customers elated with the results.

I’ve worked with teams where such a mindset is as natural as the air they breathe. At least, that’s how it seemed to me, as a developer on such teams. Looking back, I now realize that there was quite a bit of effort put into developing that mindset. I see in retrospect that the leaders of these teams had a desired state in mind as they worked with us. As the team members went about their days, small words of encouragement and appreciation were used to grow behaviors that exemplified these themes (“Great collaboration, folks! What else?”). Likewise, when behaviors ran counter to this mindset, they were discouraged (“Let’s have just one conversation at a time, please. That way, each person’s input is respected.”). Using this system of successive approximation, the team was rewarded for growth in one set of behaviors – creeping ever closer to the agile mindset – and discouraged in behaviors that didn’t exemplify elements of the mindset.

As an agile coach, I’m still learning how to cultivate and prune appropriately. I’m also learning that simply sharing the vision strengthens it. Drawing attention to the culture (current and future) of the team, changes behavior. In a short exchange with a rather quiet developer, I mentioned that I wanted to make sure that the team culture was such that she felt comfortable expressing her opinion (thus supporting Respect, Collaboration, and potentially Ability to Change). She was a little surprised, noting that she hadn’t worked in a company where culture was consciously managed. However, within days, I noticed that she was indeed talking more, sharing her ideas. I had simply exposed the existing culture, and our plans for it, to her.

What small steps can you take today, to inch closer to an agile mindset? Where can you share your vision of a great working culture? Where can you offer appreciation of behavior that fits the agile mindset?

About the Author

Susan McIntosh is an agile coach and scrum master. A former teacher and consultant, she has been drawn to agile practices, especially the training and change management that are a part of transformations.  She finds analogies to improving workplace culture in her varied experience in theatre and dance, yoga, programming, and parenting. Susan is an active participant in the agile community in Denver, Colorado. 

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • What exactly is NOT an agile mindset.

    by Jeff Hain /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "respect, collaboration, ..., and the ablity to adapt to change".
    Any micromanaged company could claim to have such a mindset:
    - they respect people (they just ignore them respectfully),
    - they collaborate (they do a lot of meetings),
    - they have improvement and learning cycles (when the old experts retire, eventually the new ones might have better ideas),
    - they have pride in ownership (they congratulate each other when things don't crash too much anymore),
    - they focus on delivering value (the elder experts tell what must be done, so it must have a good value),
    - and they adapt to change (they modify their specifications once a year).



    To my mind, the best definitions are negative ones, i.e. defining what agile is not, like this one from James Coplien in his "Agile Fine-Tuning" talk:
    "Looking at the history of agile [...] we were doing agile in the 1950s and 1960s, and then all this crap came along, and what really agile is, is taking off all this crap that the managers put on, over the years, to try to control us and try to circumvent people.",
    or this one by Adrian Cockroft in his SpringOne 2016 keynote (I assume he talked about what others call not-agile, even though (fortunately!) he didn't use the word):
    "What we found over and over again, was that people were producing a fraction of what they could produce, at most companies, because they would be held back by the process and by stupid rules and by all kinds of things that were just slowing them down."

    Or definitions that just "delegate to reality", like this one from Uncle Bob in his "The future of programming" talk:
    "Agile : The process used by disciplined professionals observed in the wild."

    It's as if every positive definition was bad, which reminds me of the Tao Te Ching (chapter 2) : "In the world each person decides what is good, and it becomes what is bad" (english translation by me, of french translation by Marc de Smedt : "Par le monde chacun décide du bien, et cela devient le mal").
    And if by agile we try to define something that would be the right way to work, and would even itself escape any precise definition while adapting to each context, it's not surprising that people struggle to give it a precise definition.

    If we never have had waterfall-like processes in the first place, we would never have felt the need for such a word, which was primarily coined in opposition to them (as the manifesto puts it : "xxx (the new-but-actually-very-old way) over yyy (the waterfall-rigid-micro-and-over-managed way)"), so I think the term "agile" is better understood as just "not unnecessarily rigid", and that in the long run it should disappear, with people just talking about such or such good practice they figured out (as Adrian Cockroft in his keynote) without systematically trying to label it as "agile".
    Also, this labeling tends to promote the kind of cargo cults "agile" tried to fight in the first place.



    Finally, here are my takes on the "if an executive... what it means to have an agile mindset":

    1) Short version:
    An agile mindset is the mindset you naturally have when you are pragmatic and your mind is free from the management fallacies that plague the industry.

    2) For longer version, add:
    These fallacies are what naturally comes to the mind of unknowledgeable people being put in charge of activities they don't understand, and revolve around worshipping and imposing reassuring yet harmful beliefs and ceremonies, such as:
    - Considering that people with similar diploma must be interchangeable, and therefore must always know all what they need by default, which makes it easy to deal with issues such as learning and forming teams (while there are most often great discrepancies and complementarities between individuals, both psychological and in skills).
    - Asking people to write and estimate everything down in advance, even though the actual work often precisely consists into figuring out and formalizing what must be done, which causes misguidance and over-constraining of the solutions, and a tendency to organize the work in non-iterative manners and without feedback.
    In particular, these fallacies don't account for the facts that:
    - People that do the work, are actually the best placed to know how to do it.
    - People need more to be told why and where to go, that how to get there.
    - The bandwidth through which any person can be managed, is extremely small compared to the bandwidth through which a person can manage itself.
    - Promoting people that have issues with the actual work, to wear suits and tell their former peers and new subordinates how to do the work, will hardly help.

    3) Ironic version:
    An agile mindset is the extraordinary belief that trying to ensure that a sprinter will go fast by asking him to wear hundreds of chronometers and to only contract the muscles he's told to, when he's told to, actually won't help.

  • nice problem to discuss...

    by Seshu Loka /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A nice problem to discuss!

    On your points, I felt the order of things should have been the other way.

    Just the way Jeff Hain has mentioned in his comment, it is a good idea to discuss the objectives of agile, the situations it tried to better. As you mentioned, Agile has been evolving in many forms and in many approaches.. the commonality being the common problems it addresses but not in the solution approaches necessarily.

    It is nice to see that you did not limit your article to just the engineering part of development. I particularly liked your bringing up Jurgen's Mgmt 3.0 thoughts to it. That is where the difference in managing starts. It is not merely a change in thought process for one department or a few people in the organization. Agile is a holistic thought with focus on the customer and calls for the organization as a whole to transform.

    You brought up many important attributes of individuals, but again, the collective behavior of all the individuals working together is the real agile nature of the organization that really counts. And that is in the culture. This is where, Mgmt 3.0 again brings in value.

    Great thought to put up an article on this! Enjoy your work!

    Best!

  • Try mindset as the journey taken by individuals to the definitions from not definitions

    by Rene Clabaugh /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    An executive would want to hear how and why they could support an Agile mindset and agile outcomes.

    Maybe single words with definitions falls flat. Ignoring people in a nice way doesn't begin to tell the story of discouragement caused by power plays, weak egos or various technical arrogance vs listening to discover and acquire value that someone seeks to voice, however tentatively. It doesn't begin to illuminate the risks associated with attempting to change a more arrogant culture with people who let you know that they are in charge (and perhaps afraid to lose out).

    Respect, therefore might be more of an outcome and not the journey. "We proudly display our respect for each other by intently listening to and being influenced by each others views at all levels, particularly for adding value to the product and company."

  • Need more Mindset

    by Tom Flaherty /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The mindset is a breath of fresh air, however since Agile practices are a black hole I still despise Agile. Let just have the mindset without Agile

  • My Take

    by Steve Quintana /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The agile mindset is an understanding that no one (customer, manager, developer, designer, architect, etc.) is perfect. Everything else about agile follows.

  • people that do the work ...

    by phloid domino /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The first post made many good points, but the most essential one was
    "People that do the work, are actually the best placed to know how to do it."

    Most 'process' approaches to software developement (and many other activities) don't understand this fundamental truth, and are based on the opposite assumption, that the people doing the work need to be 'managed',to be told what to do, how to do it and when it should be done.

    The term 'agile' has become so watered down, so co-opted for marketing and the cottage industry of books, trainings and consultants, that it has basically lost all meaning.

    Any process or methodology imposed upon developers is doomed to failure. The most pernicious fraud of all is Scrum, which is the exact opposite of Agile. Point by point, in all it's particulars, Scrum violates every princpile of the Agile manifesto, and is nothing more than a micromanger's wet-dream.

  • Thanks for your comments.

    by Susan McIntosh /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I’m glad that this article has inspired some discussion. Here are a few thoughts that I hope shed some light on my perspective.

    Yes, some agile practices seem heavy on the process side. This may be good for larger organizations, moving from an even heavier process, but certainly not an optimal choice for all organizations. I think it’s also very important to view “out of the box” systems such as scrum as a starting point for groups trying out agile practices. The introduction of the inspect and adapt cycle implies that your methods will look different after a year of experiments and improvements.

    If agile is implemented as “practices only” then I agree that it’s a micromanager’s dream, and an employee’s nightmare. If, however, those practices are used as a scaffold to support a shift in the principles, the whole culture can be moved from an environment of micromanagement and command and control to an environment where decisions are made closer to the customer, and employees are encouraged to choose an appropriate action, based on guiding principles, rather than a rule book.

    It is frustrating that the concept of agile that so many experience is one where one set of prescribed actions are simply substituted for another. I hope that there are enough people who have experienced a true agile environment (self-managing teams, inspecting and adapting to deliver high value to the clients while having fun) to continue to spread that knowledge to other organizations.

    Stay strong. Be agile.

  • My try in less than 30 seconds:

    by juan labrada /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Agile mindset is to believe in Agile values and practices, even if your are not allowed to use them.

  • "Pride in Ownership" change...

    by Juha Turpeinen /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would change the "Pride in Ownership" to "Pride in Delivery" to bring the delivery into the spotlight and to remove any associations to owning code...

    Many thanks for the well thought article!

  • Great Article

    by Helen Paulraj /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well written!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.