Being Agile vs Doing Agile

Agile is gaining popularity with many agencies and large corporations as a means to become more efficient in the software development lifecycle and increase client satisfaction. Agile efficiency comes from reducing waste, mitigating risks early on, delivering working software quickly, and adapting to ever-changing requirements at the drop of a dime. It is easy to think that agile is the catch-all answer to many common pain-points that teams experience during the product delivery process, but it is only through proper implementation that organizations truly reap the benefit of the agile methodology. An organization can “do” agile or “be” agile. Understanding the difference between these two concepts will help define what organizations can do to implement agile into their practice. “Doing” agile is actively doing the practices and applying the practices without understanding the principles behind them. The rigidity of the “doing” approach is that the project team never knows when to tailor and adopt the best practices for their needs because they are focused only on the process and tools rather than the people and interactions which are encompassed in the spirit of agile. Strict planning and restrictive contracts are another shortcoming of the ‘doing’ agile mindset. Agile fosters the ability to move in any given direction at any given time in order to provide the utmost value as quickly as possible. In software projects, there can be many unknowns. Strict planning and restrictive contracts are counterintuitive to agile by impeding the collaborative efforts between the project team and client stakeholders. The conversations and interactions between product delivery teams and client help define the unknowns and prioritize the features by impact and value. On the other hand, ‘being’ agile is adopting the right principles and practices and applying them to accommodate changing situations and different clients. The four values of agile, as defined by the Agile Manifesto, focuses on people and interactions over processes and tools, working product over documentation, client collaboration over contract negotiations, and responding and adapting to change over following a plan. It is easy to get caught up in defined processes over empirical processes that are interactive, incremental, change often, and adapt. Despite looking like agile omits structure, it improves effectiveness and reliability by evaluating processes on a case-by-case basis and allowing the teams to take ownership; ownership increases accountability. Additionally, an environment that welcomes change also welcomes creativity and innovation where designers and developers can internalize the needs of the client’s digital product. All in all, adoption of empirical process leads to client satisfaction and superior development - all reasons why organizations switch to agile. Making the transition from ‘doing’ to ‘being’ requires an organization to perform, apply, understand, and internalize the principles and practices of agile over the command and control mindset of the past. If you’re looking for a place to start, become familiar with the Agile Manifesto which is the foundation for the agile methodology. There are 12 principles of agile defined by the Agile Manifesto that are the guiding practices in implementing and executing agile within their organizations. What’s important to remember is that you must be agile in your adoption of agile. Adopt the role of a servant leader to your teams. Embrace adapting and changing. In order to become agile, you must be agile. ----------- Helpful links to start being agile: The Agile Manifesto (Agile Alliance) The 12 Principles of Agile