Gil Broza explores agile values, beliefs and principles, and explains how they can be used to drive agile adoption in his book The Agile Mind-set. The book provides ideas, examples, and anecdotes that organizations can use to make a shift to agile.
You can download a sample of the Agile Mind-set to get an impression of the book.
InfoQ interviewed Gil Broza about changing a mind-set, applying agile practices, benefits that you can get from stable teams, why improvement can stall and how to deal with that, and how organizations can check if agile would be a suitable approach for them.
InfoQ: What made you decide to write a book about the agile mind-set?
Gil Broza: For over a decade, I have been witnessing organizations struggle with the shift to Agile. Three situations seem to be ubiquitous:
- “We’re doing everything right, but…” – the results are not quite there, and they can’t explain why.
- “This change is bigger than we thought…” – they introduce Agile practices, which don’t “stick” or deliver the promised results.
- “This is Agile” … “No it’s not!” … “Sure it is!” – confusion is rampant, and people don’t know how to succeed in the new framework.
I’ve also learned that when people search for answers online and in the literature, they’re told “You should operate with an Agile mind-set” – but receive no usable explanation of it. The Agile Manifesto is no help to them, because it’s too brief. I wrote the book to set the record straight on Agile. In particular, I wanted to explain the Agile thinking without attachment to specific practices or frameworks.
InfoQ: Can you share your view of what an agile mind-set is?
Gil: Like any mind-set about work, the Agile one has three elements:
- Values: What you consider most important in the current situation
- Beliefs: What you hold to be true in that type of situation
- Principles: Which standards guide your choices, decisions, and actions
If you have the Agile mind-set, four things are of utmost importance to you: putting people first, adaptation, early and frequent value delivery, and customer collaboration. You hold certain convictions, for example that workers, being human, will make many mistakes, and that the way to mitigate the risk of employing them is to have them collaborate in self-organizing teams. You follow certain principles, such as collaboration, simplicity, preferring effectiveness over efficiency, and deferring decisions to the last responsible moment. If I had to boil down the Agile mind-set to a single sentence, I’d say it’s about delighting the customer through feedback and adaptation.
InfoQ: Is it possible for people to change their mind-set? How about teams? Organizations?
Gil: Evidence of people changing their mind-set is all around us. It’s rarely easy or quick, and often needs support and patience, but it’s possible. Teams and organizations are the same way, because they are made of people. However, being groups, the pull of their culture and habits is stronger.
InfoQ: Do you have examples of situations that you witnessed where teams were using agile practices without having a proper mind-set?
Gil: I see two patterns of this all the time. In the first, teams follow prescription; they equate Agile with a set of practices, and believe that by applying them a certain way, they will be Agile. For example, they report to a daily meeting and answer three questions; they capture their user stories and estimate them in specific ways; or they write automated tests. They do all this without awareness or understanding of the mind-set that gave rise to the practices. In the second pattern, teams bring in practices associated with Agile, but their approach is clearly and deliberately un-agile. For example, they use the daily Scrum as a status meeting, or the product backlog as a project plan. Both patterns yield confusing processes and mediocre results.
InfoQ: In the book you explain that, before adopting an agile paradigm, people should first explore the objectives and values. Can you elaborate on this?
Gil: Not every work situation should yield to Agile. When you have work to do, start by understanding its objectives: what difference will it make? Why is that difference worth making? And then, rather than assume that you’ll use Agile or Scrum or Lean to do the work and accomplish those objectives, identify your values. What’s important to you? What will you uphold, in order to accomplish those objectives? For example, you might like to have clear specifications and commitments, but responding to change, delivering frequently, and collaborating with your customer might be more important; without them, you could doom the project. In such a situation, Agile would be a valid option. In another example, making early commitments and getting the solution right the first time might matter more to you than adaptation and early value delivery, so a plan-driven paradigm such as Waterfall might be more attractive.
InfoQ: What are the benefits that you can get from stable teams?
Gil: Some deliverables cannot or should not be completed by a single person. As long as we continue to employ teams of human beings to deliver results, we can expect their aggregate productivity to be reduced as they learn to work effectively together. It’s an investment we make, but it’s only worth making if the team eventually outperforms the individuals – has positive synergy – and does so over a long enough period. Stable teams can thus maximize our return on investment in them.
Positive synergy is evident when members solve problems together, relying on diversity of thought and experience. It’s also evident when members help stuck colleagues or catch them before going down rabbit holes. A stable team retains more applicable knowledge than unrelated individuals would, so they waste less time relearning. Lastly, a stable team takes less organizational energy to manage than a new team, which means both the members and their leadership can dedicate greater attention to additional valuable outcomes.
InfoQ: The book mentions that "traditional development optimizes for writing code, while agile optimizes for reading and changing it". Can you elaborate what you mean with this?
Gil: In traditional development, people spend time collecting the requirements, and an authorized entity signs off on them. By the time developers write the code to satisfy the spec, the assumption is that the spec is correct: they should not expect any significant changes to come their way. There are also people actively pushing back on changes because of their associated cost. Since programmers legitimately expect to implement the entire spec, they can (and should) optimize their writing process.
Agile practitioners value adaptation so highly, they anticipate change and welcome it. This is evident in the Agile approach to planning. But it’s also in Agile engineering: the act of changing code – possibly quite frequently – must be economical. Changing code starts by reading it, so they pay extra attention to writing code that communicates its intent, logic, and flow. Their programming practices result in malleable code, and they apply safe, economical techniques for adapting code when necessary. And since a team shares delivery responsibility, these statements apply across the Agile team.
InfoQ: What are some of the reasons that make improvements stall in teams. Any suggestion how to deal with them?
Gil: One reason improvement efforts stall or sputter is their abstract nature. They require the considerable mental effort of shifting attention from the present and its pressures to the unknown future and how to make it better. Agile addresses this challenge by expecting teams to reflect and adapt frequently, but it sets no further expectations. Thus, teams have good control over the scope of improvement or change, and can make it practical and applicable for themselves.
The biggest reason for stalled, lukewarm, or haphazard improvement is that the improvers are human. Change hurts, and until it stabilizes, mistakes might feel like failure. Improvement, to some, implies that there are deficiencies; looking for and pointing them out might be a risky proposition. In a business setting, team members may fear consequences from senior managers and stakeholders alike. It takes a respectful, supportive, and safe culture, as well as leadership, to shift people away from these positions and make continuous improvement an actionable principle. As well, rather than just focus on improving output metrics (such as velocity), focus on growing a solid team, and they will take care of improving the outputs.
InfoQ: Do you have suggestions how organizations can check if agile would be a suitable approach for them?
Gil: In my answer to an earlier question, I explained that Agile would be attractive if your values, in a given situation, aligned with the Agile ones. That means that the choice of Agile or some other mind-set is situational. Take a look at the four values and think, long and hard, “Can these be our values? Can we act in ways that reflect them? Do we want to?” This is important, given the values most organizations seem to live by: minimize cost and schedule, make early commitments, get it right the first time, use standardized processes.
As you reflect on the four Agile values, you’ll notice that they are not created equal. The first one – putting people before process – is largely a matter of culture. Will your culture agree with that value? Or will you only embrace adaptation, value delivery, and customer collaboration, but still treat people as countable “resources” and assemble teams based on technical skills and availability? If you expect to do a significant amount of your work in an Agile way, you’ll have to adapt your value system to align with that one. Think about it this way: Some of your work would be Agile, while some would benefit from Waterfall. You can run a Waterfall project successfully in a people-first environment, but you cannot run an Agile project well in a process-first environment.
About the Author
Gil Broza helps software organizations build and lead engaged, solid, high-performance Agile development teams. He guides teams and their leaders in creating effective, humane, and responsible work environments so they truly delight their customers and make a positive impact. He is an “all-rounder,” working at all organizational levels and coaching people in both technical and leadership behaviours. Gil’s recent book, The Agile Mind-set, helps practitioners become truly Agile about their work. His earlier book The Human Side of Agile is the definitive practical guide to leading Agile teams. He is a regular contributor and three-time track chair for the Agile series of conferences, and one of the Agile writers at projectmanagement.com.
