BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Interviews Gil Broza on the Agile Mindset

Gil Broza on the Agile Mindset

Bookmarks
   

1. This is Shane Hastie here at Agile 2015 and we’re talking with Gil Broza. Gil, welcome. It’s nice to see you again. You and I know each other pretty well, but I suspect that a fair number of our audience haven’t come across you. Would you very briefly introduce yourself?

Thank you. I help organizations build engaged teams. Quite often, that will be inside of an Agile framework. Otherwise, it has to do with teams that collaborate among themselves and with their customer to do work that matters. So there is a culture change. There are behavioral changes. The change goes all the way through from role to behavior.

   

2. Working with teams. One of the things that I know that you’re passionate about and you’ve written on is the importance of individuals and interaction and the Agile mindset -- you have a new book on that?

Yes. This is hot off the presses. It came out two weeks ago, maybe, and this came about as a result of my observation last year that people are suffering consequences, consequences of using Agile in ways that they didn’t quite expect. They get into trouble because they don’t quite understand the depth and the breadth of the change. They are either for or against Agile for the wrong reasons. And the way their implementations end up is not what they hoped for, but they can’t really explain why that is. So this, I believe, is the missing ingredient, the mindset.

   

3. What’s key to that mindset?

The mindset is all the invisible stuff, all the invisible stuff in how we operate. Our values (what’s important to us), our beliefs (what we think is true), our principles (basically the standards that guide us). All of this is invisible. We use that to design process. We use that to come up with practices, to do our continuous improvement and so on. But if you only have process and practice, if you’re only told, “Hey, go and write something on a sticky note and we’ll have a conversation about it. Don’t worry, it will work out okay” and you’re not aware of the thinking that gave rise to that recommendation then it just doesn’t work.

   

4. What would you say are some of the key elements of having an Agile mindset? And what would you contrast an Agile mindset with?

It starts with the values. I know you have, anybody who’s watching this, you’ve probably read the Agile Manifesto, that’s what it starts with. Four values, the things that we take a stand for. Those are not practices, it’s not reporting, it’s not anything else. It’s the things we take a stand for: customer collaboration, responding to change if it’s worth responding to, basically, anything to do with putting people before process; four values in total.

Then there are the assumptions we make. An Agile practitioner, for instance, assumes that requirements go stale. You sit on requirements too long, they go stale. Most of us have grown up with Waterfall where a foundational assumption is different. We can get stuff out of the customer’s head and it will stay relevant by the time we’re done with it. So this is just one way to see the contrast from Waterfall. There are other beliefs that constitute the Agile mindset. For instance, the belief that if people are competent and we trust them, they’ll do a good job, but at the same time, they will also get stuff wrong. In Waterfall, the solution to that is to manage them. We put a boss on top of the group and we say, “Okay. The boss knows more, has access to more information and resources. The boss has the bigger view. The boss can decide”, whether if that is a functional manager or a project manager. But in Agile, the belief is that you minimize that human risk by putting people in collaborative teams. So, two quite different approaches.

And then there are the principles. For instance, in Agile, we amplify collaboration. We use servant leadership. We go for simplicity. We defer decisions to the last responsible moment. All of these standards that guide our decisions and they’re markedly different from what a lot of people are used to: making decisions early, getting everything in so you can get it right the first time, and so on.

   

5. Coming away from the book but looking at the broader what’s happening in Agile today, we’re 14 years since the Manifesto was written. We’re here in Washington D.C. These are the conference is sold out, 2,200 people, in fact, 2,300 people here. What are you seeing out there?

What I’m seeing is still an infatuation with process, still this desire to get the one right answer. This year and last year, the one right answer seems to be SAFe. So people have scaling problems. I get that. But they are looking for a silver bullet. It used to be that the silver bullet was Scrum for the small team. Now we have the silver bullet for the big team. I think both Scrum and SAFe are very useful in some situations and for some contexts, given the people that you have.

But generally, I find that the whole Agile thinking is still absent, still absent, and instead, everybody still dives head first into just implementation. It’s an implementation mindset as opposed to one that is situational and really principle-driven. I don’t think that has changed. I mean, one indication of that is that this is 2015 and this is the first time since the Manifesto that we have something that defines it, that defines what the Agile thinking is.

Everybody says that you should operate this way but they don’t actually tell you what that is like, and at the same time, you have so many opportunities to just pick up somebody else’s process and run with it, follow what the pretty picture says, and that’s not good enough. It’s not good enough. It might make for a great starting point and you’ll have a honeymoon period, but it won’t necessarily last if you don’t build in the right paradigm. I keep seeing that.

Shane: How would you tackle some of the typical challenges? Let’s pick one; the daily stand-up is not working properly. This is a well-understood Agile technique and it’s one of the most recognized practices.

Yes. The first thing I notice when people complain about the daily stand-up is that they confuse process with purpose. Ask them, “Well, what’s the purpose of the daily stand-up?” They say, “Well, it’s to answer three questions” or “Oh, it’s a status meeting,” right, and it’s neither. The purpose of the daily stand-up is something else. It is to renegotiate our commitments to each other as a team so that we can make sure or maximize the chances of meeting our iteration objectives.

We have a suggested process for this. It is not a mandatory process. We can stand in a circle and answer three questions. I have not found this to work well. Some teams can make it work initially and so on, but no wonder a lot of people get dragged into the daily stand-up kicking and screaming because it’s kind of boring. And you can get status many other ways in Agile. We have visibility and boards and stuff for that.

So I like to shift the conversation to, “Well, why do we recommend this type of practice? Why do we recommend that you actually step away from the keyboards for 10, 15 minutes every day, get together with your team and discuss progress?” Well, we want that because it satisfies our collaboration principle. It satisfies our timebox principle, which is to reach the end of the iteration with meaningful stuff, not just best effort, "Oh, I didn’t finish, big deal." It satisfies the principle of feedback. Also, of continuous improvement because we might discover we need to improve stuff in our plan or in how we execute it. And why do we want those things? Because they help us delight the customer. They help us respond to change. That’s why we do those things.

Now, if you find that the daily stand-up is too frequent, too infrequent, too boring, too useless, whatever it is, I’m okay with scrapping it as long as you put in some other mechanism that satisfies the same intent. Delight the customer, how do you do that? Maybe through another type of feedback loop. Fair enough?

Shane: Going to the underlying principle.

Exactly. Following a practice just because a process says so doesn’t make a whole lot of sense to me. For instance, I rarely get to work with teams who -- they try to make some of the Scrum practices work but their environment doesn’t encourage that. For instance, there was one team I worked with that just -- they could not get an hour with their product owner every two weeks. The guy is a trader. He makes the firm money, an hour means a whole lot of money, but he can give them in five minutes a day.

So forget the review meeting. Just five minutes a day, come ready with questions, they’ll be answered. They don’t need a stand-up meeting either because they all sit together. They talk all the time. They have the visibility mechanisms. Everything is there ready for them. So, convening a special meeting just for that doesn’t make a whole lot of sense for them.

Shane: Adapt to the local context?

Exactly. I have no problem with Scrum, as far as the theory goes, the mindset is there, the practices are there, but it has to be right for your situation. And if you do take it, take it with the mindset, not just the practices and the rituals and the artifacts and all of that, because you can’t justify them otherwise. You have to have a solid line of thinking saying, “Yes. If we do these things, what will in fact make me successful here is why.” The “here is why” is the thing that’s missing.

Shane: Okay. That’s a really, really powerful message for us to end on. Gil, thank you for taking the time to talk to us today.

Thank you.

Shane: Enjoy the rest of the conference.

Thank you.

Nov 10, 2015

BT