Why is Agile important? Why one may be doing it wrong?
Shankarnarayan PS
Seasoned Leader | Automotive Embedded Systems | AUTOSAR | Embedded Software | Electronic Systems and Architecture | Volvo Trucks | Mercedes | Technology Leadership and Innovation | Agile methdology
Its often talk of the town. Agile transformation, key players are investing big to get their organizations to the full speed on Agile transformation. Everyone wants to improve their effectiveness, get more out of less and speed up the time to market and at the surface level of the iceberg, agile methodology promises it all.
Agile methodology for sure is the best possible way to make things effective in any organization especially, those involved in engineering their products. It promises to do things in a way that the team is always thinking of customers, take full ownership of what they are doing, remain open and transparent to each other and finally that is always indulged in improving themselves. Sounds great! isn't it? Yes it does but, it comes with a small but strong drawback and that is the reason why many organizations are standing at the intersection of a change wave and asking themselves, is it the right way to do things?
To move further in to the discussion, let us understand what exactly agile means in its raw form.
_Well that is as simple as that. Project management methods mainly in software area over the time turned out to be extremely complicated. Redundant and overhead process activities hurt the efficiency. Unwanted steps in execution took the drivers seat instead of core engineering activities. These redundant activities were of no value to the end customer and business. Get to the repositories of organization and you will be aghast to see how many documents were created for the reason that the process asked for it and that document has never been opened ever after it was created! The idea of a big bang planning and product development instead of incremental approach proved to be disastrous. In such state, startups and small project groups started searching for alternative, a way to move quickly and easily in to the product development. A way to ease the way to reach customers, a way to ease running and adding value to the business. The answer simply was Agile. Agile is a thought process where engineers concentrate on engineering and nothing else.
I have had the first hand experience in our own product development as to how sweet it would feel if your team gets agile. Its a wonderful story that I can keep telling for years to come now. I can write may be a book on that experience but some major points may be I can highlight in this article. First, the team was excited and owned the product development. It was an embedded system built from scratch for one of the major automobile in our org. So, the seed for intrinsic motivation was always there. The team came together and in no time the entire discussions were on how a given feature should shape up. They spent time in constructive discussions and brainstorming, as a team arrived at conclusions without any external force. The big win was that the entire unit, the developers, the verification engineers and requirement engineers all came together. There was no sign of blame game any time in more than two years of our development. They respectfully disagreed when needed and challenged each other only to build a better product. The team though young, actually was matured to somehow understand this essence and they went beyond all horizons to deliver the output. The pandemic pushed them to work from home away from each other. Since we were in embedded world, we were heavily hardware dependent. The innovative ways in which the team managed this was simply brilliant. If at one time, we brought in all possible components from local shops to build the infrastructure at home, in other time, we were running around streets with our HW handing it over to each other at a central point and time slicing our work in a way to support each other. We even have fought with rain gods to safely move around our hardware and ensure we push ourselves to work towards our deliveries. There were at least five issues that were technically very challenging and what was satisfying was that, not a single time, the team came to explain why something cannot be done but rather, they came up every time with ways on how it can be done. They never tried to brush the issues under the carpet, rather they were pro-active in bringing up that challenges and discuss and work on it. There were many areas where requirements were fine tuned and the team spent time on refining it and executing it rather than sit on complaining late changes etc. Having had an opportunity to lead this team was really a great experience. They showed all attributes of agility like Transparency, Customer focus, Adaptability, ownership and regular improvements. However, to get to this state, it took us more than an year. As I said, the intrinsic motivation was ready-made for us and to our advantage, it was a small team that was involved, which eventually got to a level of great agility.
Tough there are many success stories that exists in such really small foot prints, the story changes when we are talking about complex products, bigger and diverse teams and may be a change across an organization. The main challenge that pops up is that agile is not really a new process or framework or any such thing. Agile methodology demands a paradigm shift in how engineers approach realizing a product. It requires a change in mindset, a change in ways of working. The biggest challenge in moving to being agile is not learning new things. It lies in the idea of letting go of those fruitless practices that has been etched in our nerves from a very long time. Agile requires that we first dare to stop doing those things that makes no sense to the customers or to the business. That is where most of the organizations are stuck. They have no clue how to do this. Someway or the other, they keep stuffing the old wine in the new bottle. Fitting yourself in a defined framework, creating the roles defined in the framework and using the tools that is told there doesn't make the organization agile. The true idea of agile is when teams can go with the flow of creating something. When teams dream it and create it.
Becoming truly agile needs a planning in such a way that the teams are kept at the best engagement (as I said, a natural intrinsic motivation is a main ingredient) . The vision of the organization should become visible to all the members in the kind of activities they end up doing. They have to stop dealing with problems that are internally created and start working with solving the real problems in the product that matter to the customer. Teams must not hide behind the processes rather get ahead of it to do what matters the most. If the daily teams stand-up meetings does not bring out the real problems that needs attention, then the team cannot claim to be agile. The stories that are committed should have a strong value to the product and the customer and team should have a strong intrinsic motivation to fulfill the scope. If external forces continue to act to get the output form the team then irrespective of the framework, the team for sure has not moved to being agile. All these sound very exciting when its looked from a "if we do this then..." angle. The story of becoming agile is like watching a movie in which the hero always wins.
领英推荐
Come to the real world, the transformation always is incomplete and is filled with challenges. First of all, the big mistake organizations do is to run in to a big bang change of framework . This will only change the outlook of how something is done and not the essence. People fail to transform in terms of how they think and act. People hold on to things which they don't want to give up due to which, bad practices from older way of working will slowly creep into new world in disguise. The transformation of mindset that is most important does not happen effectively. This results in a half baked change that does not give the desired results.
The next mistake is to adapt a fully defined framework without knowing whether it is best fit for their kind of organization. For example, becoming agile is very important to all organizations but fitting the organization into SAFE or scrum or any other framework? it depends on what kind of business the organization is doing. What is good for a video streaming company need not necessarily be good for an aeronautic company. All these are like changing the dress of a person and claim to have educated him. The real change need to happen from inside, its about how the thinking in the organization can change or rather evolve.
Agility in teams need to evolve. Its something that should work like a slow burning. Preaching too much of agile principle from outside will make it look more and more artificial. Adopting tools and methods that has worked for others, as I said may not work for us. If agility or being agile is expected then the best first step would be a to give a strong vision, set the objectives that motivates that team and then ask them to figure out how much more agility they can show during the execution. More importantly leaders at all levels should be ready to let go of certain believes that they carry. Even if it has worked for them in the past, it may be irrelevant for the future. It has to be let go off. Unwanted documentation, unwanted steps in the product cycle, unwanted templates, unwanted bureaucracy, unwanted hierarchy mechanisms, unwanted meetings, extremely rigid planning, putting the team in pressure box than opening the world for them, expecting immediate results without long term thinking etc. the list of bad practices are endless. If these are not let go off, the desired mindset change would never occur. If I can put it in one line
"Unless we arrive at a state where the team is happy to wake up and come to the workplace because they are together going to create something awesome and they own that creation, we cannot expect to be or call ourselves as agile"
Once they reach above state of mind, I bet they need not be told what to do. They shall unlock their potential and figure out what to do. To get there, management need to show agility first. Becoming agile should not be seen as a one step transformation. It should be seen as evolution and on the way, if something need to be rolled back or redone, one must be ready for it. More importantly, to understand whether agility is truly getting in to the veins periodically becomes extremely important. Agility cannot be taught, one has to create an environment where people naturally turn agile. The first step to it is to let go of practices that have expired.
(I often refrain from quoting an example from entertainment world to the engineering world, but this case, I somehow could not resist. The video below shows how three people come together to compose one of the finest songs I have heard. Sorry if you don't understand the language but I guess most of you can follow what is happening and am sure you identify that great musician on the chair. Video Here)