Book Review: The Agile Mind-Set: Making Agile Processes Work

[article]
Summary:

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

User Comments

2 comments
Tim Thompson's picture

Maybe the book gets to practical applications, but measuring means always compare an unknown to a known. So how does velocity measure when most of the work done is brand new development? What is the point there to establish a velocity measure that in the end means nothing because the team will not do similar work ever again? Velocity and estimates are great when all we do is CRUD pages with a set amount of fields. Most applications are not that simple minded. Even if a team knows a velocity (means not the velocity) will that make stories get completed faster? A unit of work will take as long as it does to be completed no matter what the velocity or the estimate is.

From my experience focusing on what the business needs is key here. If the business needs feature A and putting that into place takes five weeks then take the five weeks rather than spend endless amounts of time on trying to shoehorn this into an artifical time box. Especially SCRUM adds so much  overhead and process that it typically requires a dedicated SCRUM Master to manage it all. To this day I fail to understand how that is agile and jives with the Agile Manifesto. Kanban is way more agile. The focus there is to limit work in progress so that everyone can work on only a few things in parallel and put the focus on getting stuff done regardless if it takes a day or a month. The biggest benefit of Kanban is that it allows for crafting stories that generate value once they are done. Sure, the team could build the database schema in three weeks and it can be delivered, but without a frontend it generates zero value to the user.

Focus on business needs, delivering value, and limiting process to the minimum.

December 8, 2015 - 9:53am
Steve Berczuk's picture

A couple of points. Point estimates are meant to be based on similar sized stories (units of effort, etc), and while any relative sizing is subjective, some teams do a good job of estimating consistently. Another approach is No Estimates, where you don't estimate. But you still need to put some effort into sizing the work, so your measure of velocity is more like 'stories over time.' I don't agree that Scrum is less agile than Kanban. They address different problems. Many teams have problems with getting to incremental deliverables, and thus incremental feedback. Having said all that, the points the book make are valid for both Scrum practitioners and Kanban practitioners. And in spirit for non-agile method users as well.

December 9, 2015 - 1:53pm

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.