Gil Broza's book The Agile Mind-Set: Making Agile Processes Work speaks to the challenges faced by people who focus on "doing agile" rather than "being agile." Rote execution of methods can only get you so far, and Broza gives insights into how you move beyond practicing agile by habit into living it.
When I speak to teams about agile software development and Scrum, I often start by discussing the Agile Manifesto . While this might seem like an extreme exercise of going "back to basics," the values expressed in the Agile Manifesto and the associated principles explain agile software development in a clear way that informs everything else about how an agile team works.
Practicing agile software development is harder than it appears, and following an agile method without a good understanding of the principles and values behind it can limit your progress. This is the central message in Gil Broza's book The Agile Mind-Set: Making Agile Processes Work .
There is more to being effective at agile than following a process. As Broza points out:
Getting great at Agile, like becoming great at long-distance running or at a new career or at parenting, involves a deep shift that a sequence of small steps cannot achieve adequately. You need to make a proper commitment: “Do it like you mean it.”
He describes the agile mindset as a consistent system where values, beliefs, and principles align. This is a useful strategy regardless of your method of choice; Broza makes the point that any development approach, including waterfall or lean, is best executed in the context of a consistent mindset.
The book speaks to the challenges faced by people who focus on "doing agile" rather than "being agile." Even those who are familiar with the values often get hung up in process mechanics. You can certainly benefit from following agile practices by rote, but to be successful in agile (or any other method, for that matter), you are better off if you act in a way that's congruent with the values of your process, particularly when faced with challenges or conflicts on your project.
One area where organizations have a hard time transitioning to an agile process is in how they measure the effectiveness of the transition. Broza writes:
The transformation isn’t a start-middle-and-end type of activity. Individuals, teams, and organizations can never be done adopting Agile, just as you can’t become a responsible person once and for all.
The fact that developing and maintaining an agile approach is work that can never be declared “complete” can be frustrating to some. In practice, there are milestones and metrics you can measure to gauge how your team is doing with agile. Just as “inspect and adapt” is an approach to use with your project plan, it is also an approach that you should apply to your agile process.
But if you are using the metrics and milestones as a way to judge without an eye toward improvement, you may be missing the point. An example from the book:
A team might be following every documented Scrum practice, for instance, and still have taken on little of the mind-set. Asking “What’s our velocity?” (and subsequently “Can we increase it?”). Velocity measures a team’s capacity to produce output. It is not a measure of the Agility of their behavior or of the usefulness of their output. It’s not even a good measure of the benefits of Agile.
Measuring velocity with the goal of increasing it in abstract closes the door to a number of possible improvements, such as changing how you define points, or correlating your velocity with customer satisfaction. Things like user experience and quality are what agile teams should be concerned about.
In addition to helping you become agile, having an agile mindset can keep you from falling back into the old, familiar ways of working that you wanted to change. It also helps you