Overcoming Paradigms to Become Truly Agile
Truly agile is what you are, and to become agile you need to overcome paradigms, argues Arie van Bennekum, co-author of the agile manifesto and thoughtleader at Wemanity Group. At Spark the Change London 2016 he talked about agile as a metabolism.
Van Bennekum stated that it takes "being agile" and not "doing agile" to achieve success. Overcoming paradigms is essential; people need the right mindset to become agile. Agile is an interaction concept based on the values and principles of the agile manifesto. Technology facilitates agile working, but tools don’t make you agile, van Bennekum claims. Agile is not something that you just implement; it’s a change to increase the adaptability of the organization.
Several people have shared their views on becoming and being agile. In her article on an organization development approach to agile adoption,Vijaya Devi states:
One of the myths about Agile is that people and organizations tend to believe that by practicing a set of activities, such as Daily scrum, sprint cycles, and retrospectives, they become Agile. On the contrary, organizations which want to become truly Agile need to change their mindset.
In the article Ten Ways to Successfully Fail Your Agility, Oren Kdoshim and Ilan Kirschenbaum explain what it takes to become agile:
Becoming agile is hard work. It requires continuous practice, breaking old habits, and adopting a new mindset, to name a few challenges. It means tweaking the culture, and that requires investing a lot of energy in the organisation.
In an interview with Mario E. Moreira, InfoQ asked him about the business benefits of being agile:
The primary business benefit of being Agile is that you begin to truly understand what customer value looks like. You will become hyper-focused on understanding what is of value to the customer and using smaller increments to build, validate, and improve the product so that what you delivery will be directly aligned with what the customer finds as valuable. If you achieve this (directly aligning what you build with what the customer finds as valuable), the company will ultimately make more money. This may be Agile’s dirty little secret.
Belinda Waldock explains during the InfoQ interview on her book "Being Agile in Business" how being agile helps people anticipate change and navigate uncertainty:
Agile helps to see trends and patterns in our work and our environment so we can begin to understand the rhythm and flow and be able to anticipate what may happen in the future. A lot of the pain that goes with change and uncertainty can be addressed in a team using agile by helping to communicate and share information and insights. There are some things we cannot anticipate but using agile we can build in slack to plan for these uncertainties.
InfoQ spoke with Arie van Bennekum about the main changes he has seen in the software industry related to agile, why people find it difficult to accept shifted paradigms, successful implementation of the agile values and principles and adoption of servant leadership, increasing organizational wide collaboration, and what organizations can do to foster an agile mindset.
InfoQ: You are one of the signatories of the manifesto for agile software development. What are the main changes that you have seen in the software industry related to agile?
Arie van Bennekum: First of all there is the eagerness of taking responsibility. At the moment, wherever I go, every organization has somewhere Agile initiatives. We all know the big stories and often forget about the spark. This spark is often initiated by people at the operational level in projects. It is awesome to see that bit by bit more people in the teams are eager to take responsibility.
Second, there is the general awareness that we need a shorter time to market. More and more organizations change to shorter delivery cycles. After all, in the time before writing the Agile Manifesto most of us were trying to solve that problem. Running over time and budget is unfortunately still the case but the awareness is one step in the right direction.
InfoQ: Why do people find it difficult to accept the shifted paradigms in the way they work as teams or manage teams?
Van Bennekum: To be honest, I am not a therapist but you can see patterns. We have been too long in situations with individual silo work. The funny thing is, during a football game we can all see people are multidisciplined and they can step in for each other working towards one shared team objective.
The moment we are at work we hide into silos. The silos are, as far as I can see, a result of traditional management which started over a century ago based on the idea that the manager knows and decides all. The silo is safe (it's clear what you have to do), can bring you status and work has clear process (paper and signatures) to either enter the silo or to leave the silo.
Teamwork- where we act as a team having a set of things to do serving one shared objective, in which we decide on the spot who in the team will take on what- has simply not been the way we work. Crossing that bridge and starting to work like that is something we sometimes try, but at the moment something goes wrong and in a standard reflex we will hide again in our silo, old patterns, documents, handovers, etc. This is why I used the word "metabolism"...
InfoQ: Can you give examples from organizations that succeeded in implementing the agile values and principles? What did they do to make it work for them?
Van Bennekum: I can give you examples but I do not know if they are all ok with having this revealed in public so I wont give specific names. But let me say it by using three case studies from Agile Transformations at various organizations such as a large retailer, a mid size energy provider and a large technology company.
Overcoming the paradigms is essential. Management paradigms, development paradigms, paradigms in responsibilities, etc. In order to be able to do it, you need to have three things in place.
First of all, for Agile working vertical commitment is crucial. Aspects like transparency, discipline in the rituals, visualization, prioritization, etc., not only need support from the management; management has to role model this as well. Especially coming from old hierarchy cultures, people tend to copy management behavior. This is why we (in combination with other activities of course) have to pay special attention to management at all levels during our transformations when we coach teams and individuals.
Second is the safety of the environment; people have to feel safe enough to make mistakes. Learning means trying, developing, mistakes, etc. and that takes time. The standard reflex is to fall into old patterns. The moment you don’t have time to make mistakes and management does not support you, this reflex will be supported and change becomes impossible.
The third one we like to apply, unless the organization is in a heavy crisis, is the fact that we start with the company as it is. We keep people in their own safe environment and start changing during the development waves. Lessons learned especially help to change- just pushing change into teams and the organization does not really make it sustainable.
InfoQ: What makes the adoption of servant leadership successful?
Van Bennekum: Proof.... Managers need proof (most of the time). Case studies, references, visits, especially in similar processional domains help to overcome things like "not invented here" and "good idea but this does not work for us". By the way, this not just for managers. Most people want proof in their own professional domain and even then you will hear quite a few "yes but" quotes...
InfoQ: Breaking down walls between parts of an organization can be challenging. Any tips on how this can be done to increase organizational wide collaboration?
Van Bennekum: Heartbeats are essential. Any stakeholder who has a say somewhere in the traditional sequence of the development process (whatever you develop) needs to be involved. In combination with my answer to the previous question, I can sketch it like this.
As mentioned we will keep the organization as is. We change the interaction during projects or other forms of the development. We will take out the sequence and work in multi disciplined teams with all stakeholders. Stakeholders are still positioned in some department but assigned to a team with the mandate to decide, accept or change when needed with regards to their domain. Think about developers but also architects, legal departments, corporate marketing communication or anything else as long as they are stakeholders somewhere in the development process.
The moment to bring all mandated stakeholders together (so that they get information at the source) is the heartbeat. From early moments where we create the product backlog and design principles all the way to final delivery heartbeats (preferably on a weekly basis) are the success factor.
InfoQ: Any final advice on what organizations can do to foster an agile mindset?
Van Bennekum: Too often I hear people say things like "that does not work for us". The thing is, Agile working makes you responsive. You need responsiveness in the dynamics of today’s and tomorrow's world; it is inevitable. Never accept "that does not work for us" regarding Agile. Always work together to find a way how you can make it work.
Agile -- much ado about nothing
There are years of industry validated organizational studies, leadership practices & research. "Agile Manifesto" is based on none of that.
If stakeholders don't champion, Agile labels them unresponsive.
If developers balk, Agile labels them "not team players"
If asked for evidence or domain competence, Agile labels them resistant to change
But Agile is always beyond reproach :)!
#1. Allow people to fail -- there is no method to estimate of kind/cost of failures to be incurred/budgeted -- on which ROI are we allowing these failures
#2. Allow organizations to fail fast -- who compensates shareholders? how much loss should be expected?
#3. Unsubstantiated generic claims -- "Need responsiveness in the dynamics of today's & tmrw's world; it is inevitable" -- inevitable based on what?
#4. Privatize profits, externalize costs -- Agile practitioners claim all success is due to Agile but when there are failures it's always client/project/team or xyz. Never fault of Agile itself.
#5. Ask for domain evidence or relevance -- Agile practictioners are immediately defensive. Because there is no behavioral or business origin of "Agile Manifesto" -- a bunch of folks cook up a process, label it Agile and expect everyone to follow blindly! Text book definition of cult behavior.
Software industry did thrive before Agile Manifesto and will continue to do so, long after it is cured of Agile hangover.