Many organizations consider that adopting Agile/Scrum is the end. They will read some books or get a consultant to set their process right, and then declare that they are Agile. To make the problem worse, they may also do some role mapping — project manager to Scrum Master or PO. The tech leads and testers will be wondering about what their role could be. . . .
Is this the right approach? Is it really effective?
Most of these organizations/teams later talk about the failure of Agile. I have heard many hypotheses about why this project is special and why Agile thinking won’t work for this project. If we go a little deeper and observe, we will see that they didn’t transform the mind-set of the people involved. They have done an adoption (some process and role change), not a transformation: Now we comply with Scrum, but we don’t understand what Agile is about. It is a proven anti-pattern.
Organizations should give more importance on continuous improvement than adopting a process or practice or tool. Let us look at the Deming Cycle:
This is a widely used model for continuous improvement, formulated by W. Edwards Deming. The Deming cycle reminds us of the importance of sensing and responding to the system. We should build a culture of continuous improvement within the system; that is when we will see the system mature and solve problems on its own.
Most seasoned Agilists will talk about the need for an “Inspect and Adapt” culture within an organization. Agile is not a silver bullet; it can’t be applied as is to multiple projects. An organization should inspect its current state and adapt to situations by respecting Agile values and principles. The key is continuous improvement. Slowly you will sense what is working for you and what is not. Collect feedback as frequently as possible and fine-tune the system in collaboration.
My mentor Laurent Sarrazin used to remind us frequently that “Agile is the means, not the goal.” How true! We should introspect about our intent. If we are trying to make an Agile organization or an Agile team, we should focus on the values and principles of Agile, not the descriptive processes. One should design the best process for his organization/team within the boundaries of Agile because all the frameworks are incomplete.
One should always look for improvement within the system. If we consider that this is the end, and we stop engaging in continuous improvement, complacency will set in and we will be destined for failure. I invite to think about the difference between an Agile Enterprise and Enterprise Agile. Michael Sahota have published an interesting post about this (you can access it here).
In my opinion, the intent is most important. Good intent includes customer collaboration, transparency, empowerment, self-organized and self-driven teams, trust, and open communication. Agile can help you achieve in one or more of these properties, provided the system is designed to inspect and adapt to changing situations. We can also consider different “flavors,” such as Scrumban or Kanban (There are lot of frameworks in the market now). In any case, we should not forget that “Agile is just a bend, not the end. It is the continuous improvement culture/ mindset which create the difference!”