If you are a professional working for a company that has a lot of application development and project work going on (finance, insurance, retail, or transportation industries to name a few), there is a good chance you have heard the word agile or potentially scrum thrown around a lot. Since the revolution impacts you indirectly (in a scrum project you would be called a “chicken” read here for the pig and chicken story related to agile). There is a good chance no one has sat down and explained agile to you. Well if that is the case, this blog is what you need.
First off, agile is a way of working. It is not a practice, methodology or framework. It is a way of working that is based on a core set of values and off those values are direct principles an agile practitioner adheres to. Here are the two primary sources to learn the values and the principles, for the values go to Agile Manifesto and for the principles go to Agile Manifesto Principles. From the value and principles, practices are developed. Some of these practices include things like self-organization, iterative work, the retrospective, agile planning, story point estimating, velocity and burn-down, defining done and pair programming. From there, practices are worked together and wrapped around a workflow and developed into flavors of agile. The flavors of agile are growing into mainstream work like marketing, product development, and human resources. Some of the more common flavors of agile include scrum, SAFe (scaled agile framework), extreme programming, scrum development, lean start-up, and the new flavor called business agility.
To put this all together, we will take scrum. It is a flavor of agile used to plan, develop and deliver software that meets the needs of users and does so efficiently and effectively (aka saving time and money). It ties back to the core agile values and principles and utilizes practices put together that espouse those values and principles like the daily scrum, utilizing a scrum master and product owner function, working in sprints (2 to 4 week work cycles) and after each sprint doing a retrospective (reviewing success and failure of the work cycle just completed). In the end, each flavor of agile must tie back to the core agile values and principles and practices used must also espouse those same values and principles.
Now to help support your foundational knowledge of agile as a way of working, it is important to break out some of the “core” principles that can be found in all flavors of agile. They represent a mind shift from traditional management and leadership constructs.
Lastly, there are two practices/principles that are at the bedrock of agile. Without these two, it is impossible to be agile. One is self-organization and the other is pushing decision making to where the work is done (autonomy). They are two sides of the same coin, but it is important to distinguish them apart from one another.
With self-organization it is about working as a team and allowing the team to decide how it works. In typical organizational structures, there is a top-down approach to management. The manager tells you what to do, and the workers do it the way the manager wants it. A great book that illustrates the failures of this approach is Zapp! The Lighting of Empowerment. The top-down structure basically allows the workers to give up decision-making and responsibility to the manager. In doing what they are told, they do not have to be accountable for the outcome. With self-organization, the team makes decisions related to output and work and the manager coaches and supports the team, provides goals and offers the team context (vision) to what they are working on.
This brings us to the other side of the coin, and that is decision-making aka autonomy. Agile insists that the team and each member of the team take responsibility for what they are doing and how they are doing it. Also, each member holds themselves accountable for their output. This is illustrated in the daily stand up where each team members says what they did yesterday, what they are going to do today and if there are any issues or things they need help with. In a high-performance agile team, the group quickly spots the weak links who struggle with this level of autonomy and responsibility and the team is responsible to deal with the situation with coaching and support from leadership.
So why separate them out, they sound like basically the same thing. Because in majority of cases where agile fails, the failure isn’t that the organization didn’t try to self-organize, it is that the organization couldn’t push autonomy and decision making to the self-organized team. It was self-organized in name only and management continue to make decisions. Without decision making at the level of work, you lose the sense of ownership and responsibility which reduces productivity and quality.
In the end, to understand agile you must look at it as a way of working, with a very thin user guide. It mandates the practitioner takes responsibility for themselves and their work, it relishes things being done, it requires drastic management and leadership changes and it requires constant learning and practice. People call it lightweight, but it is better to look at it is open source, in that there is a core foundation but things can be built off that core foundation if they adhere to that core foundation. In the case of agile, the core foundation is its values and principles.
Post by David Mantica.
Your details have been submitted and we will be in touch.
Your details have been submitted and we will be in touch.