It's been over than an year and half since I started to work on an Agile project as a BA. Before this experience I only heard the word "Agile" a few times... But things are changing. Those days the "Agile", at least the idea of it, is becoming more popular. Many companies are starting to follow the Agile principles while others pretend to, hiding behind the name of the method and applying waterfall logics. From my point of view, my functional point of view, the Agile method is an incredibly powerful way of thinking. It's not a simple recipe to apply, it's not a one way path to follow and it's not (not really) an organizational structure. Agile is a bunch of principles, nothing more than that. Said that, and as you may have understood, Agile is not an easy way to success. A company that declares its self "Agile" is not automatically successful nor delivers by default high quality products.
Agile as a reduction of complexity
Functionally speaking being Agile is a powerful way to approach problems. I truly cannot imagine a better way to deal with complex scenarios rather than using the natural step by step fragmentation. Agile analysis is similar to a mathematical problem: analyze the entire request and start to decompose the problem in little pieces to begin with. Implementation of suboptimal solutions gradually lead to the resolution of the big picture (similarly to a puzzle).
Agile is an approach, it's not the solution itself. Foundations rely on:
- Continuous delivery;
- Shaping the products upon real customer feedbacks.
This way the value is gradually increased and it's far more easy to adjust the direction if something is not going as expected. From the BA point of view it means that the first solution may change many times during the iterations, due to customers, due to new requirements or (unfortunately) due to inadequate initial analysis. The change itself is a good sign of growth of course, but this leads to an important assumption of Agile: the importance of what we can call "flexibility".
Agile strong assumptions
Declare that a company is Agile is simple. Write down some principles in some brochures, say to the customer that the program approach is to continuously adapt the solution to the requirements and, magically, the company is Agile.
It doesn't work like that... Agile is stressful, incredibly fast and dangerous for the company, if not well managed. Let's go in deep on what we called "flexibility".
Agile, as we said, is mainly based on continuous delivery. Deliver continuously and quickly mean that every two or three weeks some piece of product is done and ready for the customer. This approach needs fast analysis, very quick implementation and an incredibly robust quality assurance upon what has been newly created, as well as the impacts on the product that was already in place. So, Agile (if really applied) becomes not only a motto but needs an entire organization change, plus cross functional teams.
This is one of the biggest Agile assumptions in my opinion: cross functional and self organized teams.
Having cross functional teams is not so easy and letting them to self organize is even more difficult. It's not a simple matter of organization strategy: create the right environment and such conditions involve organization culture and more deeply the willing of individual members. Martin Fowler once wrote an article on this topic, it's what he calls the "Agile Fluency".
... [Highest level of Agile Fluency] not only requires shifting organizational culture to focus on the whole system, it also requires working at the bleeding edge of Agile practice and potentially inventing new ways of applying systems thinking to Agile. It’s not for the faint of heart. People in all parts of the enterprise have to adopt new mindsets, change their familiar behaviors, and learn to value new practices.
Another huge assumption is the customer involvement. Continuous delivery loses much of its meaning if the product delivered doesn't match the expectation of the customer. Having frequent sessions of feedback, user tests and all other kind of constructive discussions between teams and customers is an imperative need. This aspect is frequently overlooked by many and not always related to customer availability. The temptation of designing solutions inside the teams without sharing and debating them with the customer is high. In addition to that, more than often, the final user is not identified in the customer but it's some one hiding behind the customer, this additional layer increases the level of complexity.
The strong customer involvement and self organized teams are the two hugest impediment in a true implementation of Agile principles in many companies. There's not a recipe to solve the problem magically. Usually the more the company is small and more the self organized teams are easily to manage, but this is a personal assumption. In general we can summarize saying that Agile is actually a mindset, not a structured method.
Agile as a mindset
Reaching a significant level of agility it's a difficult goal to achieve. There're many steps to do and merely replicate ceremonies (as standup, "sprint", retro...) doesn't mean you're more Agile. Many companies nowadays are selling their self as Agile just because they do standup meeting. It's a big lie. Agile is a deep sort of mindset: it's the concept of continuos improvement applied the the entire company reality, from products to organization and culture. Moreover it's not an internal virtuous cycle but it has to shared across organization units and with the customers.
Agile is a powerful mindset and I think that nowadays it's becoming part of many management strategies. The ideas behind the Agile principles could easily become a disruptive competitive advantage in many markets and, although I've been immersed in this "methodology" for more than a year, there is still much to discover.