If we use the term “velocity” alone, we could not be as “Agile” as we — or business — might want us to be. Nowadays we are experimenting in a hotter market with specific business needs. Many projects have failed just because the product owner did not understand the basic principles of Scrum or, when he or she did happen to understand them, simply did not care anything about them. Undoubtedly one of the biggest challenges encountered during Agile adoption is the needed change for incorporating new processes in the environment, including partners, customers, employees, and the product deliverables.
“If you are an ‘Agile Team,’ doesn’t that mean the project will be finished in less than a month?” said the product owner to the team. Sometimes the word “Agile” confuses people, because it is as distant from “faster” as Earth is to Pluto. Thinking about business processes, if we just use the word “Agile” as “earlier,” maybe we could apply it in more ways, such as having to do with feedback, results, expectations, etc. However, an “earlier result” does not necessarily mean a “fast” or “fastest” result (or feedback, or anything else). The relationship between the product owner and the team must be adapted daily. This fact is important because the team has the knowledge to turn the business ideas into powerful resources, which of course gives business a competitive advantage. Playing the conciliating role, the ScrumMaster should be able to understand the expectations and provide constructive feedback for both sides, but this is certainly not a simple task.
“You can’t tell us how to do it, even if you have technical skill,” said the team to the product owner. Collaborative work is a kind of day-by-day construction. If the team needs help, why won’t they try different perspectives? If the members, including the product owner, are all in it together, any suggestion should be welcome in the task of building incredible products. If the team cannot get together as a team, possible solutions may be missed simply because of poor exploration of ideas. Meanwhile, if other teams are working together and they succeed with different results, they may have exponential success in building their projects.
Velocity is a measure of distance over time, but business needs are more complicated for this measurement, because they must relate to real market time. We have seen this before — revolutionary products with low cost and high aggregate value can destroy even the most stable global product markets. To increase the speed for acceptable business terms, we have to learn how the products are valuable to their context, and this is another challenge.
Agile techniques must follow business environments and global tendencies. Scrum works fine around motivated people, and exceptional technology skills embrace the framework’s principles, but we cannot ignore the concerns of business needs. Some concepts are more important than what we call velocity. Envisioning a product means more than “faster” … it is “beyond.”
Marcos A. Paixao
Published @ ScrumAlliance.org