BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Interview with Tiago Garcez about Why Agile?

Interview with Tiago Garcez about Why Agile?

“Would you recommend Agile in every situation?” The answer from Tiago Garcez on this question is “Yes!”. But, as Tiago explained in his talk at the Agile Tour Brussels conference, people are unsure what agile means and what an organization can do to become agile.

Last year, InfoQ published the article bridging the management gap where Tiago wrote about reaching a tipping point where organizations would unshackle themselves from the limitations of command and control. Recently, Tiago talked at Agile Tour about why agile is better suited to the challenges that companies are facing, the value that agile can deliver, and how you can start an agile transition.

InfoQ: Tiago, thanks for doing this interview with InfoQ. Can you introduce yourself to our readers?

Tiago: I'm an Agile coach at Agilar. Originally from Brazil, I have worked for the last 13 years in IT projects and change management in both the United States and Europe. After spending the first 7 of those years as a business analyst and project manager, and experiencing first hand the frustrations that came from working in waterfall environments, I was thankfully introduced to Agile in 2007 and have spent the last 6 years supporting teams and organizations in their transition towards Agile.

InfoQ: In your presentation at the Agile Tour Brussels you stated the question "would you recommend agile in every situation?". Why this question?

Tiago: Whenever I talk to IT people outside of the Agile community, one of the questions I get asked most frequently is "would you recommend Scrum in every situation?" At first I didn't get the motivation underlying for the question. It seemed weird to me, because I never actually heard anybody recommending Scrum for every situation. But after probing to understand the reason behind the question, I would typically find out that the person had either first hand experience with a "cookbook" implementation of Scrum (the one where you're just told to work in Sprints, do stand-ups every morning and write down your tasks on a taskboard somewhere) or had heard horror stories from somebody who did. Not surprisingly these stories are usually coupled with another pattern - a manager, director or consultant who told them they had to work in Scrum "because it will make them faster / more productive". No wonder people start calling it a fad!

So after getting asked that question many times, I eventually came up with the answer I use nowadays which is "no, I would not recommend Scrum in every situation, but I think that's the wrong question." Naturally, this leads them to ask me about what is the right question, to which I'll say "would I recommend Agile in every situation?" And the answer to that is a resounding "yes!"

And here is where the conversation really takes off, because at that point they will tell me that they're not sure what Agile really means. What practices does Agile recommend? What is Agile, actually? Is it just the manifesto everybody has seen online? How can an organization actually become Agile?

And this I enjoy, because now we're finally down to the interesting questions!

InfoQ: You talked about teams and why they are important. Can you elaborate on that?

Tiago: Back in the manufacturing economy, the basic building block of an organization was the individual. You would hire somebody for their ability to produce. They would join your organization's production process, and apply their individual skills to add some value to your product or service. It's a pattern that guided our entire society in the 20th century, from education to our economy. You passed your exams in school as an individual, you were trained to improve your individual skill set and your salary (and bonus, if you were entitled to any) was based on your individual performance. Indeed, companies were sure that their success depended on having the most talented individuals. It is this pattern that gave rise to the "hero syndrome" I talked about in my presentation, where an organization's success was (mistakenly) linked to an individual's ability.

The knowledge economy has finally exposed this fallacy because innovation has now become key for sustainable organizational success. It was always important, but in the manufacturing economy the "innovation cycle time" was just much longer, so organizations didn't feel the pressure quite to the extent that they feel today.

It's not that the individual is no longer important, of course they are. But hiring talented individuals does not make your company great. The key ingredient to innovation and competitive advantage in the knowledge economy are teams, especially cross-functional ones. The complexity of the problems we're addressing plays a part in this, but it's not the only reason. A vibrant team culture in an organization is the best way to establish a sustainable culture, which brings success not only in the short-term, but also the long-term. That is the great downside of the "hero culture" we usually ignore - what happens when the hero is gone? (assuming you can even find a "hero" to begin with…)

This is why I say that teams are the basic building block of an organization in the 21st century. This is true for every section of an organization, from sales, to support and, of course, even management. Organizational leaders ignore this message at their own risk.

InfoQ: "The predictive model has come and gone", you mentioned. In many organizations predictions still play an important role, e.g. when deciding to invest in projects or the development of new products. Are there alternatives to prediction?

Tiago: Prediction will always play a role in our society and our economy. I don't believe we can get away from that; it's an inherent human trait. The trouble is when people start ignoring or changing the actual connotation of the word "prediction". At its heart, "prediction" is a mere guess. Nothing more, nothing less.

Similar to the economic concept of "opportunity cost", we make predictions all the time, whenever we make a choice. When an organization decides to start on project A instead of project B, they are guessing that project A will be more important for whatever reason (reducing costs, increasing revenue, etc.).

When you phrase it that way, it becomes easier to start seeing alternatives to the classic prediction models. If a prediction is nothing more than a guess, what would a responsible person do? They would want to make sure that guess is not completely wrong as soon as possible! And there are plenty of alternatives emerging as to how you can do that.

"Lean Startup" is a classic one, where Eric Ries talks about validated learnings and testing out your hypothesis (another fancy word for "guess", by the way) as soon as possible. Don't waste time getting it perfect, find out as quickly as possible and by whatever means necessary, if the direction you're heading is correct or not. And if it's not the correct direction, pivot.

Dave Snowden talks about the power of stories and micro-narratives, and how they can help you validate your predictions. His company has built a way of working where they are capturing micro-stories from actual users on a real-time basis. I don't know the details of this approach yet and still have many questions related to it, but its potential seems significant. If you can capture actual micro stories from users, you don't need to spend time writing user stories with a proxy user (where you are again trying to predict what the actual users will need). In the scenario proposed by Snowden, you develop solutions to resolve actual problems you captured from your users on an almost real-time basis. There’s a video by Dave Snowden where he explains the concept.

InfoQ: I hear a lot about learning from failure, but failure can be expensive and sometimes it's not an option. Are there other ways to learn?

Tiago: I disagree with the phrase "failure is not an option". It might be useful as a motivation tool, but at its core, that phrase is deeply rooted in the predictive planning world. Failure is always option - it's just that sometimes we don't even want to imagine what would happen if it actually did happen (i.e. when you have to prepare your country to host the World Cup, when you're building mission critical software for a hospital, etc.)

When you phrase it correctly ("failure is always an option") alternatives already start to emerge. Safe-to-fail, for example, is one of the terms that you hear a lot these days. The thinking there is simple, make sure before you start any initiative where there are considerable risk, that you use controlled experiments where you know what success and failure look like, so that you can evaluate potential solutions or ways forward. Such an approach keeps failure from being expensive or mission critical, while still providing opportunities to learn (if you structured the experiments in a coherent way).

But your actual question was whether there are other ways to learn (besides failure) and the answer there would have to be "yes". Experience is what provides learning opportunities, and experience can come in many forms. So why is failure prized? I think the answer here is related to one of the XP values: courage. If you never fail, you aren't pushing the boundaries. And the logical conclusion to this line of thinking is obvious - if you want to innovate, you need to be willing to fail.

I heard a good line about this at the Agile Tour, by the way, a quote from Mario Andretti: "if everything seems under control, you're just not going fast enough".

Also, fear of failure will make an organization fragile. This is a really big topic, so for the sake of brevity I'll just refer people to (Nassim Nicholas) Taleb's work here in his new book "Anti-Fragile" (2012). But at a very high-level, trying to make yourself failure-proof is an exercise in futility. Not only is that ultimately impossible, but it means that when failure does occur, your organization will suffer catastrophical consequences because you're just not equipped to deal with it.

InfoQ: Many organizations are currently focusing on reducing costs. Can agile help them to do that?

Tiago: One of the points I stressed on my talk at the Agile Tour was precisely that at the core of Agile is a recognition of the inherent asymmetry between cost and value. Cost has a limit, you cannot reduce it past that limit. Value, on the other hand, has no limit. You can keep continuously improving it.

Now, even though Agile is clearly focused on improving the value side of the equation, it is also great at exposing waste. So indirectly, yes, Agile can help organizations reduce unnecessary costs.

The trouble is that many organizations are not really able to understand their value stream. They don't know how to measure value and therefore have little idea how to measure its improvement. Measuring cost reduction, on the other hand, requires little more than elementary mathematics skills.

My advice for companies who want to work on the cost-side of the equation is to not do it. Focus instead on value. It's more rewarding and ultimately healthier for your organization. If they insist, I would recommend they spend some time identifying their value stream and then focus on reducing the non-value-adding waste. My guess is they will be surprised by where they find the biggest waste in their value stream.

InfoQ: There are organizations that consider agile to be the holy grail that will solve all their problems. Are they expecting too much?

Tiago: In one word, "yes". Agile is much more about a way of working, a culture, than it is about solutions to specific problems. Agile doesn't guarantee you will build a product people want to buy nor does it guarantee you will resolve all your internal political issues.

When companies choose to "adopt Agile", what they are really doing (if they're serious about it), is embarking on a cultural change initiative. And in many cases, the Agile culture will be in stark contrast to their existing organizational culture, meaning this will not be an easy journey. On the contrary, it will likely be the most difficult thing they ever did.

What does success in this change initiative look like? They will have an organization that is built around cross-functional teams, where value generation is the ultimate currency. People will feel challenged to deliver their best, not because of fear or intimidation, but rather because of intrinsic motivation. You will have an organization that is poised to compete in the knowledge economy, where the pace of change is ever faster and the need to improve and innovate is always present.

That's it. Agile will make you competitive in the knowledge economy. Success is never guaranteed and failure is always an option (anyone who says otherwise is selling you snake oil).

InfoQ: Some organization have implemented agile, but are not getting (sufficient) benefits out of it. What can be causes of that, and what can they do about it.

Tiago: Naturally, the reasons behind this can be manifold, but typically this will be related to the previous question - organizations who are struggling to achieve significant benefits from their Agile adoption are most likely either expecting too much too soon (the holy grail syndrome) or are unwilling to revisit some of their more deeply ingrained cultural characteristics.

The cultural impediment is frequently a problem for extremely political organizations or ones that have predictive planning and command & control embedded into their DNA. If this is indeed the case, I'm not convinced there is much they can do about it.

However, if we assume the situation is not so drastic, I would recommend they ask their people what's going on. Try out an open space or a world cafe format, perhaps, and listen to the ideas, feedback and questions that are coming up. My guess is they will know better than anybody else, what's going on, and why the Agile change initiative is not obtaining the results that were expected.

InfoQ: If an organization wants to become more agile, is there something that you can recommend them to do? And something that they should stop doing?

Tiago: From an organizational perspective, I believe actions that move companies away from local optimums and towards a more holistic view are always beneficial to become more Agile. This includes implementing a culture of cross-functional teams, promoting collaboration across silos or even figuring out what value means for the organization. Actually, I've recently been drawn to the topic of value. It is one of the words most commonly thrown around the industry (Agile or not) - we should prioritize based on business value, we need to deliver value to our customers, etc. But people forget to go through the exercise of thinking what this means in their environment. So I definitely see this as an important step to becoming more Agile, or else you will just get better at delivering crap (the "crap in, crap out" syndrome). Focus on the whole system's ability to deliver value.

As for things I would recommend that they stop doing? Individual performance reviews (especially those that happen only on a yearly basis). It's painful for everybody involved and doesn't really serve a purpose besides telling you that in end your individual performance is still more important than your team's performance. Also, stop with big projects and big budgets. Force your product owners, program office and managers to work with small projects and budgets. In this way your organization starts making a series of small bets on many projects, instead of large bets on a few projects.

About the Interviewee

Tiago Garcez is an Agile coach and partner at Agilar.  He has worked in multiple large-scale Agile transitions, supporting change leaders and teams in their continuous improvement efforts.  Previously, Tiago worked as a Product Owner, Agile Project Manager and Business Analyst.  An active member of the Belgian Agile community, you're likely to bump into him in the Agile events in the area. Or you can follow him on Twitter.

Rate this Article

Adoption
Style

BT