Agile Doesn't Just Mean Fast

Agile means sustainable, high quality, and value-driven output.

Unfortunately, there are those who think all Agile is about is ensuring that your delivery is fast. I have even heard comments in my experience that fast is good, even if you must compromise on quality. And that Scrum is not so good, or at least it is not the framework of choice, because of the "scope freeze" that happens during the iteration or Sprint and hence there is a waiting period during the Spring before any more items can be picked up by the team. That is, even if your Sprint duration is as short as one week. So they tend to think Kanban is better suited for them, not realizing that it is actually the same thing. Whether you are running Scrum or Kanban, you will always have to wait until the team is free before they can pick up something new to work on. Some also see no point in prioritization, especially when in environments where the demand for changes or support is very high and therefore there is no time for prioritization and the team must work on all items as soon as they come their way. I am afraid that these misconceptions have given Agile and Scrum a bad rep and Agile teams find themselves reprimanded, although indirectly, for sticking to the scope of the Sprint Backlog and are thus labeled as slow. I, therefore, thought it would be worthwhile if I discussed three characteristics of Agile: sustainability, high-quality output, and value-driven development.

First, sustainability in being agile is an intrinsic characteristic of the team. As mentioned in the Scrum Guide (by Ken Schwaber and Jeff Sutherland), Scrum aims at building a high performing, sustainable team. Obviously, part of being a high performing team requires speed, but what about sustainable? Scrum and Agile were built on the idea that if we focus only on being fast, then the team will experience what is known as burn out. And when that happens, that very team will stop being high a performing one. Take that quest for fast delivery over the top, and watch the adverse effects it shall have on the personal lives of members of a team. So it is obvious that those who only think a team needs to be fast, and who miss the importance of sustainability, do not realize the kind of impact that is being brought about due to their limited way of thinking. And it is not long before a team which is driven by the notion of just being fast begins to produce low-quality output.

Which brings me to another key aspect of being agile, which is the focus on quality. Do we compromise quality in an attempt to be fast? I was told that that is OK in Agile. I do not agree. That is not OK in Agile. In Agile projects, we focus on the triple constraints which are scope, schedule, and quality. While the first two are variable, the third, quality, is non-negotiable. If you are pressed for time and cannot deliver all of your scope by the end of a Sprint, you deliver less scope, not less quality. Those who have missed this idea, which is at the core of Agile, I am afraid have missed the point of Agile altogether. Focusing on speed alone creates a culture of carelessness among the team, who start coding faster and, with that, begin introducing bugs into the system. Therefore, the faster you code and deliver, the more testing you need to do as well.

Lastly, value-driven implies prioritization. Those who do not see the importance of prioritizing the team's workload, i.e. the product backlog, are usually the same who claim that the team is not fast enough (in my experience). And hence the unrealistic expectation becomes apparent that the team must deliver all the requirements as they come to them. Then I think it is fair to say that these same people, not only see prioritization as being unnecessary, but they also do not wish to acknowledge that every team has a finite capacity of work they can take on. For the team to be able to digest work as soon as it comes their way is, of course, impractical. Let us agree that every team does have a capacity because they cannot work on anything and everything at the same time. Once this basic principle is understood, then it becomes clear that since the team has a certain capacity, then their workload has to be prioritized and planned. This is true regardless of the methodology or work style one is adopting and hence does not apply to Agile or Scrum alone. Therefore, the idea that being agile is about delivering value to the customer anytime is not correct. They call it being flexible by having the ability to pick up and work on something immediately, not realizing that context switching at this undesirable pace causes the team to lose focus and creates unnecessary waste and overhead. One has to prioritize. And prioritization is about delivering the highest value to the customer first. Once that is understood, that is when you have to learn to say no to stakeholders. Not no, as in they shall never get those requirements. Rather, they will not get it when they ask for it simply because the team is working on another set of higher priority requests of theirs. This notion that the team should be able to do everything at anytime, I found to be especially common in environments where communication is poor. And I do not mean communication between Agile team members, but that which should be happening amongst stakeholders whose requirements are represented in the product backlog waiting to be picked up by the team. In such environments, such communication needs to be managed in a way that ensures that all stakeholders are on the same page with regard to what the team is working on.

Therefore, let us stop with this idea that being agile is only about fast delivery. I would argue that being agile is about early delivery and those two are not the same thing. While the reason is obvious why there are calls for fast delivery, early delivery has requirements of its own that are just as important to the success of the project. Early delivery is done so the team can learn through feedback received after releasing to the customer and is used to make adjustments to the product still being developed. Releasing early is also to determine what the next highest value item shall be that the team needs to work on and deliver. Another reason is to benefit the customer’s business with the newly built feature early on, helping to ensure market competitiveness, and not have them wait until the product is entirely finished.

Promoting the idea of Agile being fast and not stressing the importance of the other core principles that I have mentioned causes the team to only think about delivering fast. Such thinking shall soon lead to compromise on quality, as the team works overtime with this single goal in mind. Slowly it falls apart, the product suffers, the customer becomes dissatisfied, and then the unavoidable crash occurs. When this happens, usually the development teams are the first ones to take the blame.