Reasons to "Do" Agile: The Waterfall of Scrums

(This article was originally published at Scrum Alliance - Here's the link.)

Since my first encounter with Agile, I have heard a great many things about it. They vary from the initial "It would never work here" to "We do Agile here, and it’s great." Most people who were in the first group back in 2009, when I first experienced Scrum, ended up in the We-Do-Agile group later. Thus, let’s focus on this group for the sake of this discussion.

There are many people who "do" Agile, and they brag about the many advantages this "Agile procedure" or "Agile method" brings. First, let me say that I do not disagree — at all. But let's analyze some of their arguments and practices.
 

Being more Agile means deploying software faster

According to an article I read lately, becoming more Agile means that the teams/companies can deploy software to production faster. Although this is a good thing, and I agree that Agile does provide for a faster delivery of a software increment, it doesn’t take Agile to get faster at deploying software. If you just plan shorter development cycles and set the scope to fit such cycles, you get the same result.

Now, don’t get me wrong here. I am not saying Agile is not needed to increase productivity and aggregate value. On the contrary, I think it is inevitable if a company wants to survive through the next decades (the market won’t get any less complex). However, I think that sometimes people are so eager in becoming Agile that they end up focusing too much on the processes (sprints, ceremonies) and tools (Kanban, Planning Poker?), and they forget about the people and interactions.

It is great that you can deploy software faster, but the key element of an iterative approach and constant inspect-and-adapt applies, before all else, to business value. Being able to deliver the specified product faster is way different from being able adapt the minimum viable product (MVP) until it becomes the required product. To show the difference between the specified product and the required product, let’s analyze the graph below, from the Standish Group Chaos Report (2010):

(Source: The Agile Executive)

Agile is really a scoped Waterfall of Scrums

In my entire work experience, it wasn't uncommon that a team of business analysts (which are, in more Agile companies, called the "technical product owners") gathered the requirements from the business units (a.k.a. the POs) and delivered them to the team. Many, many times, the team also got a deadline with the user stories. So the sprints were sort of like the movie Hunger Games, in which you had to kill all requirements or they might end up killing you. I have even seen POs assigning grades to sprints. If you delivered all user stories, the team would get an A+ (a 10, in Brazilian marks).

The team did deliver software faster, but they were never involved in the business logic behind the stories. Often they even got the architecture defined by another Scrum team (called the Architecture Team). And the managers bragged about having a Scrum of Scrums in the company. I’d call it a Waterfall of Scrums, though. 

Although I am not saying this is wrong (because, after all, it did improve on what they had before), I would not say it is Agile. It takes more than just the Scrum roles and the Scrum ceremonies to have an Agile environment.
 

Be Agile!

The key misconception, in my opinion, is that people are trying to do Agile instead of be Agile. I would dare say that the Scrum framework is not intrinsically Agile. It can be used (as it is, as pointed out in this article) in a non-Agile way. What makes Scrum Agile are the principles on which it lays its foundations.
 

You don’t need Agile to reduce your bug detection expenditures or to improve your time to market

You need Agile to iteratively learn about your product, about the market, and about your customer while delivering the most aggregate value in the shortest possible time. You should be Agile in order to deliver what your customer needs the most (and thus, what they value the most) while they still need it. A Lean product is very different from an unfinished product. An unfinished product won’t solve your problems, whereas a Lean product will have just enough features and functionality to solve your problem.
 

You don’t need Agile to cut IT costs

You use Agile to boost your return on investment as soon as possible. This is why you have the MVP. The MVP is not a database or a user screen. The MVP is perhaps the always-used 7% in the Chaos Report graphic. And the product is not the 100%, but maybe the 20% of the often-/always-used features.

If you’re using Agile to save money, then do it by getting rid of unnecessary features. Features cost money to develop, and if their cost is close to or higher than their financial value to the company (how much money does the company make by having that feature?), then why would you even spend time and money on it?
 

You don’t use Agile to increase the throughput of your IT department

You use Agile so that your IT department and your business units work in tandem (together is just not enough), communicate very well, and come up with the best possible solution to a business need (not requirement), a market scenario, or a pivot on a product.

Your business units don’t dictate what the IT department should do. Rather, they share the business challenges, the market scenario, and the stats. They then create, with IT's help, descriptions (in whichever format you like, not only user stories) of such challenges, which are prioritized by the business unit (through the product owner) and, technically, as well as operationally defined and developed by the team. Together with the PO. Always in tandem. Always transparent. This is being Agile.

In short:

• You don’t use Agile in your IT department. Your company needs to be Agile.
• You don’t use Agile procedures. You live by the Agile principles.
• You don’t do Agile. You are Agile.