Many municipal utilities want to become more agile. Why is that? - "Because everyone's doing it now" is certainly not an adequate motive.
Many municipal utilities want to become more agile. Why is that? - "Because everyone's doing it now" is certainly not an adequate motive. On the contrary, there are good reasons for this. Also, possibilities to initially expand rather hierarchical procedures in a few parts of the company with agile elements. There it is also allowed to design existing frameworks like Scrum in a way that they are suitable for your own task. Published in: e|m|w (Energie.Markt.Wettbewerb) Issue 5/2019 (www.emw-online.de) Right at the beginning, one essential question can be asked: "Why is "agility" desirable?" Basically, the answer can be reduced to two points: The requirements resulting from developments in the environment require adaptable organisational models and fast reaction times. In addition, more and more employees expect flat hierarchies as well as more flexibility and personal responsibility in the design of their work processes (see Fig. 1). The solution for those two requirements promises agile methods that do not align processes with rigid hierarchies, but flexibly with the requirements of the project. Market demands Concerning the requirements of the energy transition and in response to the decline in volumes and margins in the electricity and gas business, municipal utility companies are called upon to adopt a more integrated approach and regularly extend their range of services to include non-core business services. One consequence of this is that, in the event of such a development, they will have to compete with suppliers from outside the industry and must therefore be able to keep up in terms of speed and performance. Public utilities with broadband offers, for example, are already being challenged to counteract providers such as Deutsche Telekom, Vodafone/Unity Media, who repeatedly place special offers, with price adjustment processes that do not drag on for months as in the electricity and gas sector. In the future, bundled offers will become established, which will significantly increase the degree of complexity. The availability of new technologies also leads to shorter innovation and product life cycles, e.g. in the field of photovoltaics and storage solutions. Business models are becoming more digital - and customers from other industries have long been used to receiving products, information, feedback, etc. quickly. Requirements of the employees It is also becoming increasingly difficult for municipal utilities to adequately cover their personnel requirements. New employees - often from the Y or Z generations, who bring with them urgently needed know-how in the areas of digitization, data analytics, customer experience, etc. - have a strong desire for free development and independent implementation. They expect their employers not to be patronised or restricted. Their ideas of how to solve tasks satisfactorily thus differ from those of many colleagues who have "always" done so in a clear hierarchical structure. What characterizes agile companies? Agility distinguishes companies whose guiding principles are based on flexibility, adaptation and self-organisation. They are thus able to adapt to the requirements of the environment in order to produce the results desired by the stakeholders and reflected by the team in terms of goals or a vision, even under changed conditions. More and more companies are using "Scrum" as a framework for agile work, an approach that is based on not planning a project strictly from the beginning and formulating comprehensive requirement profiles immediately, but rather on carrying it out step by step in "sprints". Nevertheless, at least one "product vision" must exist (for tasks where this is still missing, e.g. "Design Thinking" is more suitable as an agile framework). These short product development cycles and iterations in Scrum ensure a continuous improvement process. Thus, after each sprint in the "Review", the partial results are assessed by the stakeholders with the possibility of (re)orienting themselves more strongly to customer needs. The "retrospective" focuses on internal issues of cooperation in order to learn as a team for the next round. Essential for agile collaboration is that the responsibility for the result is shifted from management to the employees. The team itself removes obstacles and distributes tasks sensibly among themselves - oriented to the available time and financial framework. The implementation team, which is composed across departments and works free of hierarchies, the efficient meeting structure and the direct involvement of decision-makers and customers ensure short decision-making paths. Of course, progress measurements are also provided for Scrum. Challenges in municipal utilities A municipal utility is typically more traditional and hierarchical in structure. In these, it is often difficult for superiors to hand over responsibility and "just let their teams do their work". In addition, superiors sometimes make very detailed specifications as to "how" a goal is to be achieved, instead of limiting themselves to "what is to be achieved". Many of them also regularly monitor progress and sometimes change the targets in the middle of the process, expecting these adjustments to be implemented more or less unquestioningly ("command and control"). In doing so, they not only deny their employees the opportunity for empowerment, i.e. the chance to represent their interests on the basis of their own competence, autonomy and self-determination, but also overlook the fact that by shifting their competences they can create more freedom for themselves, for example for strategic or management tasks - in future understood in the sense of enabling, encouraging and steering. It is also often the case that managers attend meetings or are on e-mail distribution lists , even if they cannot contribute at all. (How) can hybrid approaches work? Many municipal utilities have recognised that changes in internal cooperation with regard to the market and employees can be useful or even necessary. Strictly speaking, however, the introduction of agile forms of cooperation in a municipal utility company requires a comprehensive re-organisation and the dissolution of hierarchies - even in top management. It is understandable that not every company management is prepared to do this "from now on". If, however, "agility" is used as a supplement to classical structures, so to speak as a secondary organization, and if the strict guidelines of, for example, Scrum as an agile framework are not slavishly adhered to, a hybrid approach can emerge that is individually tailored to the needs of a municipal utility. With initially selected tasks, individual departments can act as "germ cells" and "pilots" from which agile working methods with the integration of other organizational units diffuse throughout the entire company. The disciplinary management will then continue to be carried out by the respective superiors, while the technical management will be transferred to the "product owners". This makes the organization both position- and role-centered. However, role and task are weighted more heavily than the organizational suspension. The Product Owner receives the goals and requirements of a project from the supervisor and represents him and, if necessary, other stakeholders with this knowledge before the implementation team. From this, he formulates a vision, which contains statements about the target group, needs, USP, economic efficiency and challenges, etc. He is responsible for the success of the project - which gives him (and only him) the authority to decide on the "Product Backlog", which lists and prioritizes the requirements necessary to implement the vision. However, he alone is not entitled to decide "how" these are implemented. This is decided by the entire implementation team, which the Product Owner puts together to cover all the skills needed to provide the desired functionality to implement the vision. He himself attends all meetings of the implementation team and can - but does not have to - be a member of it. This is particularly advantageous if he is simultaneously product owner of different teams and therefore responsible for several products. This poses a major challenge: How can it be ensured that such teams, which are usually cross-departmental, have the freedom to work on the task in a self-organized manner and only obligated to the product owner? It is conceivable to introduce an "Agile Board" - not provided for in Scrum - which could, for example, be made up of the heads of different departments of a municipal utility. In this round, we discuss how the company-wide targets, broken down into divisional targets, are implemented (Fig. 2). An example: Through "Sales/Product Management" a product bundle consisting of available electricity and broadband products is to be introduced. This fact is committed in the Agile Board with regard to goals and basic use of resources and a product manager is appointed as product owner. His goal could be: "Within four months, I will launch a product bundle of electricity and broadband on the market, which will help us retain residential customers, increase their value and win new customers, and to whom we can offer additional services in the future. The Product Owner remains in close contact with the client (e.g. the Sales Director), possibly even with the entire Agile Board and the customers, who can also act as stakeholders, when formulating the vision. Everything else is left to the product owner and the implementation team. The team itself estimates the amount of work and, based on this, selects its own tasks from the product backlog for the next sprint. Only in the reviews do stakeholders - and all team members - provide feedback on the respective partial result. However, it is up to the product owner to include this feedback in the product backlog or not. He is likely to do so if he considers it to increase the value of the expected (partial) result for which he is responsible. With the introduction of an agile secondary organization it can be helpful to involve an "agile coach" - also from outside. He can support the individual product owners and implementation teams, e.g. as "Scrum Master", but also accompany the management in dealing with the topic. The Scrum Master ensures that the process is followed and supports the team in removing obstacles. It is also worthwhile to rethink existing meeting and documentation structures outside the agile organization. Especially the Scrum events "Sprint Planning", "Daily Scrum" and the already mentioned reviews and retrospectives can - together with the use of a "Scrum Board" - be a model for a more efficient and transparent design of all reporting structures throughout the company. Conclusion The addition of an agile secondary organisation certainly does not automatically solve all the challenges that a municipal utility faces in terms of flexibility, adaptation and self-organisation. Superior stakeholders, who are constantly changing their objectives today, can continue to do so in the reviews at the latest. Employees who have not yet been able or do not want to work independently will also find it difficult to do so in an agile environment. A prerequisite for success is first and foremost the willingness of all those involved to engage in such a form of cooperation. A straightforward Scrum Master, who also succeeds in persuading superiors to comply with their new role, helps. In addition, creativity is helpful when it comes to solving problems that have not previously arisen in a hierarchical form of cooperation. The "pure form" of Scrum can provide inspiration here, even if it is then used in a modified form. In view of the reasons that have led to the establishment of an agile secondary organization, there will probably be few alternatives but to solve challenges that will certainly arise - then gladly by the teams themselves.