An agile approach can change organizations. Most ideas of this approach can be applied not just to IT, but to all business areas. Is this valid for agile values and principles which refer to software and projects too? Let’s find out.
Change, they say, is the only constant. At nearly twenty years old, the Agile Manifesto describes the values and principles for team collaboration in software development. It has been a guide that puts people at the forefront in order to design better products, get timely customer feedback, and escape the aberrations of conventional project procedures – basically, projects that don’t get done and cost a lot of money.
While the manifesto has served us well over the years, in today’s environment of rapid and sometimes disruptive changes, we would do well to add a few tweaks, to:
- make executable and tested software solutions available incrementally
- extend them, bit by bit
- try them out in practice and learn from them
- understand failures as a means to an end, to become better
Implementing the agile principles naturally impacted the involved teams, which learned new ways of working through the changed cooperation with IT. Many of the applied principles are also applicable to other business areas. Not only IT, but other departments and even the entire organization can become agile to better focus on the customer in the competitive environment.
When we speak of ‘Business Agility’ (the application of agile elements in the business context), there are many ways of doing this – such as, by:
- visualizing open tasks
- performing daily standups
- learning by means of retrospectives
- planning a marketing activity incrementally
The agile values and principles are transferable to other business areas, but not like a direct one-on-one swap on all business activities. The agile manifesto is focused on software development and on product development, which does not apply to all business activities. Although many project-like projects carried out in the organizational structure can be implemented by agile procedures, many activities have to be carried out regularly and repeatedly. Formulations such as “working software is the primary measure of progress” are not applicable there. Should only a part of the agile principles apply to business departments? That would be a pity, because each sentence embodies a certain idea that we do not want to do without.
Thus, we have to re-formulate some of them, generalize them so that they can be used in different contexts. Here is a proposal to cover the possible aspects, by following the original ideas (the tweaks we have made are in bold):
The Agile Values
Instead of working software, I have chosen working solutions, because this term covers the delivery of short term, regular, but also long-term results, as well as their necessary adjustments. Instead of contract negotiations, I have taken the formal approach, co-operation has more value than nitpicking regulations. Project plans exist till only a limited extent in a regular operation, but often, the pattern of always having done something like this scores over following only set plans and habits.
The Agile Principles
Not every department is part of a core process, an activity that is different for each customer. For some people, it is probably not always so clear that they work for internal customers, so I think it is important to replace the customer with our customers – in order to focus on who that actually is. What do they deliver to their customers? In most cases, they are probably services that should be valuable and not unnecessary.
Changing requirements probably happen everywhere, and internal customers are not in competition. So, it’s enough to point out the customer’s advantage. I have replaced working software with solutions that are to be delivered early and are the most important measure of progress.
To work together daily is, of course recommended, but if you look at all experts with their different contact persons, close co-operation probably fits better. Not all work is organized in teams, so organizations should learn and be built around motivated people. Therefore, the best solutions and results are achieved by self-organized teams.
In general, all participants should be able to maintain a constant pace indefinitely. Technical expertise and good design can generally be transformed into excellence and quality of results, to live up to the idea behind the principle.
Would you like to adopt my proposal, with any other formulations that could better meet your company requirements? Then do it, experiment with it, learn from it! Discuss with your colleagues about what Business Agility means for you, according to the motto “Inspect & Adapt”.
Conclusion
Agile values and principles can be transferred to all business areas. Although the functional and content-related range of several departments is very different, the ideas can still be applied. Thinking about what they mean for your own area of responsibility and how they can be appropriately defined could be a suitable introduction to business agility.
References:
https://www.nagarro.com/en/insights-events/filter?tag=agile-methodology
https://www.nagarro.com/en/blog/agile-manifesto-achieving-business-agility
https://busagilitymanifesto.org/
https://startsmallscalefast.com/agile-business-manifesto/
