Agile Banking – Why?

Being a banker, that was something. But the future looks bleak for traditional banks. There are many reasons for this: Social networks, low interest rate policies and government regulation are a few of them, they say FAZ . In addition to a low interest rate policy, cryptocurrencies such as Bitcoin are also a threat to traditional banks. The increasing state regulation also threatens the business models of many banks.
N26 has received a banking license and is now much more than a new type of FinTech hype startup. It showed the banks how simple an account can be and how modern. Despite massive security gaps, the startup is growing inexorably.
The danger also comes from startups. Says so T3N : This should motivate other startups to apply for a banking license and thus break away from the established players. Even if not every fintech will receive a banking license – the requirements for this are still high, the effort high – it is becoming apparent that the disruption is slowly moving. Banks, be careful. Especially now.

Agile banking – how?

But how can established companies also produce these innovations? Christoph Schmiedinger says in Boris Gloger’s blog : VMany of the ideas that start-ups use to be more flexible can actually be easily applied in large companies – after all, it’s the year 2016. Methods such as design thinking and rapid prototyping are widespread today and should be part of the repertoire of every product development department.
Another success factor is the digital transformation. That’s what he says GFT blog : Financial institutions apparently need a suitable technological foundation for their journey into digital transformation: agile development methodologies, continuous integration and DevOps. In short, they need systems that are able to process information in real time so that the right decisions can be made for the right customer in the right time window. But they also need a new culture to deal with their customers: a completely revised approach to the role of bank branches in terms of prioritizing the user experience.

Conclusion: the agile bank is coming

In summary, it can be seen that banks are facing upheaval due to low interest rates, new customer requests, startups and government regulations. This is supposed to go through agile methods , Lean Startup, Design Thinking and the targeted use of technology can be managed. The aim must be to create more speed on the one hand and to adapt to the new framework on the other.

So agile banking is already an issue and agile banking is coming. There is itself too Christoph Schmiedinger sure and writes: I think the journey to becoming a more agile bank is worth it. With the help of agile values and methods such as Scrum and Kanban, when used correctly, many of the hoped-for advantages – in particular proximity to the customer, shorter time-to-market and more flexible release planning – can be achieved. Also in GFT blog is from a “ cultural change that extends to changing the vision and mission of banks “spoken to serve the 21st century customer. So these profound changes call for a more agile bank.
There are currently numerous digital labs and established banks are definitely not just watching. ING Diba and Co. have also been offering great banking products and new innovative pilot projects for a long time. So it remains exciting to see how agile banking will prevail and how the question between security awareness and constant trying can be solved. Read on for more mine Article on agile finance . Are you still or at an established bank or have you already switched?
[yop_poll id=”27″] [werbung] [fotolia]

Der Beitrag Agile Banking – the agile bank erschien zuerst auf agile Companies.

A management discipline that, as agile requirements engineering, is always in demand wherever complex systems are developed in processes that are strongly based on division of labor.

One of the main tasks of requirements engineering is first of all to use the representation to determine the respective requirements profile – also known as requirements analysis. These determined requirements are also documented. In this context, agile requirements engineering requires that knowledge be actively imparted to the team. When checking and coordinating the requirements, the RE must plausibly and conclusively prove the correctness of the requirements. As the last core activity, Chris Rupp and the SOPHISTs (2014, p. 14) describe the administration of requirements. Parts of the risk management are therefore also assigned to this aspect.

Ramesh et al. (2010, p. 456) state that in times when technologies change quickly and develop further, requirements are becoming more and more complex and clear time problems prevail, agile RE practices are in demand. More frequent tests and reviews, constant personal communication with the developers, and extreme prioritization result in complex challenges to which no answers can currently be found.

These provide an alternative to an initial approach for integrating RE in Scrum. The principle can be integrated before, during or after the sprint. In this way, the problem of uncertainty can be closely observed during development and a more precise, more up-to-date statement can be made about the feasibility of the objective. This provides the possibility of prompt, targeted adaptation of the requirements. A precise application is currently not yet to be found in the literature and is currently being evaluated in case studies.

The history of requirements engineering

Requirements engineering is still a very young discipline and was first seriously mentioned in 1993 at the ICRE conference. With the emergence of UML, it was used for the first time in feature-driven development and later in IBM’s Rational Unified Process. The IREB has been working on the professionalization of requirements engineering since 2006 and since 2013 there have been many publications on the subject of agile requirements engineering.

Requirements engineering in the Scrum process

But what exactly does modern and agile RE look like? As we already know, united Scrum and Agility all in one process. The question therefore arises as to whether one can still speak of RE in the classic sense in this case. If we look at what Scrum actually looks like – Baumgärnter et al (2013, p. 3) provide a nice illustration of this – we quickly notice that from the Position of the “Requirements Engineer” now the Role of the requirements engineer becomes. So this is still an elementary part of the process.

The role of the RE

However, the understanding of the role of RE is changing. The requirements engineer is now also a manager within the process. In addition to his usual tasks, he now plans more than before and constantly switches back and forth between the two roles. Like every role, the RE now has more responsibility and thus more opportunities and opportunities to contribute.

Let’s look up one level and ask ourselves where the requirements engineer can be found in the process. In modern processes, he is often replaced by the product owner, but he still exists in larger projects and organizations. The RE can then be found as a specialist department or individual person parallel to the Product Owner.

Agile requirements engineering in the course of the project

How does it all work in practice? If we look at the course of a project, we see that a large number of requirements engineers are usually needed at the beginning, and that their need decreases significantly over the course of the project. In the first interviews, however, we noticed that the aim should be to distribute the requirements engineers equally over the course of the project and that the normal procedure is not optimal. The requirements engineers now also appreciate the specification effort, plan larger features at the beginning than epics and therefore ensure the possibility of flexible changes to them. The REs also evaluate the software with the customer right from the start and stay true to this process through to the end. In the course of the observation, I experienced an equal distribution of the discipline of requirements engineering.

Tips for the product owner

Many RE’lers are happy to be made product owners. But this is different to the Product Owner. But what does he do? I have this in Boris Gloger’s blog found a definition:

The role of product owner is perhaps the simplest, and yet one that is completely misunderstood by many. The product owner is Part of the scrum team. He works with the scrum team. This means: He is not a requester who lets the team build something, but an integral part. He has a special view of working together. He wants the Scrum team to only deliver what is valuable – that is, what the customer will buy. For more information, please refer to the Book by Boris Gloger on Scrum watch.
But what can a good product owner do? I have gathered a few examples of the character on various websites and list them here:

• represents the product vision
• makes decisions
• knows business models
• shares experiences
• Strong in communication
• exemplifies agility
• understands the product
• is there for the team
• can say no
• is an entrepreneur

[werbung]

Verwendete Quellen anzeigen

Der Beitrag Agile Requirements Engineering (RE) erschien zuerst auf agile Companies.

Role of controlling

The presentation by Roman et al. (2014, p. 47) clarifies the new role of the agile Controlling. The discipline no longer acts in isolation as a single unit, but acts closely with management. This means that agile controlling in modern, agile companies is not only responsible for precise, customer-oriented reports, but also takes on coordination, moderation and decision-making role that is more oriented towards traditional management than before. Boundaries are softening and the different roles also use methods from other areas.

Hybrid controlling

Summer et. al (2015, p. 42) show in this graphic how so-called hybrid controlling is currently becoming the “state of the art” due to the large variety of methods. With this procedure, every single phase of the project is checked by a Qualitygate. Each team is free in the respective phases to use their own chosen methods for the implementation: The spectrum ranges from Scrum to waterfall. With hybrid controlling, controlling is only responsible for tracking the respective results from the phases.

Agile controlling

With the implementation of Scrum, controlling has accordingly revealed another task. However, the question arises as to how Scrum can be “controlled” at all. The burn-down chart has an answer: Agile controlling will have the task of establishing such charts within management.

Beyond budgeting as agile controlling

The principle of beyond budgeting plays a further role in controlling. It was developed in England in 1998 and is intended to be a counter-application to “instruction and control” in Taylorism. It is defined by 12 principles, which I would like to briefly address here. For more, see the book: Beyond budgeting – incl. Online work aids: target-oriented management and increase performance without budgets. I have the 12 principles on the Page by Haufe found and would like to quote them here:
6 principles deal with the control process in companies:

• Targets formulated relative to internal or external competition should be self-adjusting and have a performance-enhancing effect.
• Early detection and rolling forecasts should enable constant adjustments of strategy and investment decisions to changed environmental conditions.
• A rolling strategy development and implementation process is intended to promote the strategic coordination of corporate activities. In particular, the balanced scorecard is being propagated as an instrument.
• A flexible allocation of resources should be achieved through the specification of a discount rate by the head office and autonomous decentralized decisions about the investment projects.
• Decentralized units should basically control themselves. The head office only intervenes on a subsidiary basis if the decentralized managers cannot solve a problem or ask for help from top management (“Management by Exception”).
• Relative, team-based compensation that compares the success of the business unit with other units is intended to encourage teamwork and collaboration.

Another 6 principles deal with the organizational framework and corporate culture:

• Leadership through shared values and clear management guidelines should enable quick, decentralized decisions within defined limits.
• Autonomous profit centers should create more entrepreneurship in the company.
• Internal markets for coordinating the profit centers should replace coordination with plans and enable faster reactions.
• Information available everywhere and immediately (“real time”) should lead to the greatest possible transparency and distributed control.
• Freedom of action and decentralized responsibility for results should enable and enforce the performance of decentralized actors.
• A “Coach & Support” leadership style is intended to support the managers in this.

Der Beitrag Agile controlling, scrum and beyond budgeting erschien zuerst auf agile Companies.

Role of controlling

The presentation by Roman et al. (2014, p. 47) clarifies the new role of the agile Controlling. The discipline no longer acts in isolation as a single unit, but acts closely with management. This means that agile controlling in modern, agile companies is not only responsible for precise, customer-oriented reports, but also takes on coordination, moderation and decision-making role that is more oriented towards traditional management than before. Boundaries are softening and the different roles also use methods from other areas.

Hybrid controlling

Summer et. al (2015, p. 42) show in this graphic how so-called hybrid controlling is currently becoming the “state of the art” due to the large variety of methods. With this procedure, every single phase of the project is checked by a Qualitygate. Each team is free in the respective phases to use their own chosen methods for the implementation: The spectrum ranges from Scrum to waterfall. With hybrid controlling, controlling is only responsible for tracking the respective results from the phases.

Agile controlling

With the implementation of Scrum, controlling has accordingly revealed another task. However, the question arises as to how Scrum can be “controlled” at all. The burn-down chart has an answer: Agile controlling will have the task of establishing such charts within management.

Beyond budgeting as agile controlling

The principle of beyond budgeting plays a further role in controlling. It was developed in England in 1998 and is intended to be a counter-application to “instruction and control” in Taylorism. It is defined by 12 principles, which I would like to briefly address here. For more, see the book: Beyond budgeting – incl. Online work aids: target-oriented management and increase performance without budgets. I have the 12 principles on the Page by Haufe found and would like to quote them here:
6 principles deal with the control process in companies:

• Targets formulated relative to internal or external competition should be self-adjusting and have a performance-enhancing effect.
• Early detection and rolling forecasts should enable constant adjustments of strategy and investment decisions to changed environmental conditions.
• A rolling strategy development and implementation process is intended to promote the strategic coordination of corporate activities. In particular, the balanced scorecard is being propagated as an instrument.
• A flexible allocation of resources should be achieved through the specification of a discount rate by the head office and autonomous decentralized decisions about the investment projects.
• Decentralized units should basically control themselves. The head office only intervenes on a subsidiary basis if the decentralized managers cannot solve a problem or ask for help from top management (“Management by Exception”).
• Relative, team-based compensation that compares the success of the business unit with other units is intended to encourage teamwork and collaboration.

Another 6 principles deal with the organizational framework and corporate culture:

• Leadership through shared values and clear management guidelines should enable quick, decentralized decisions within defined limits.
• Autonomous profit centers should create more entrepreneurship in the company.
• Internal markets for coordinating the profit centers should replace coordination with plans and enable faster reactions.
• Information available everywhere and immediately (“real time”) should lead to the greatest possible transparency and distributed control.
• Freedom of action and decentralized responsibility for results should enable and enforce the performance of decentralized actors.
• A “Coach & Support” leadership style is intended to support the managers in this.

Der Beitrag Agile controlling, scrum and beyond budgeting erschien zuerst auf agile Companies.

Baumgartner et al. (2013, p. 3) show in the figure above that Scrum one process for all roles Are defined. In the picture you can see how this one process combines the roles of the project manager, requirements engineer and tester. “Test” as a discipline no longer exists in isolation from Scrum. Rather, like the other roles, the tester becomes part of the overall agile process.

In the representation of Baumgartner et al. (2013, p. 101) we see how the role of the new, agile tester is split equally into the tasks of test manager and tester. Thus, one person or the agile department takes on operational tasks on the one hand – these tasks include the tests themselves, measurements, as well as logging and tracking – and, on the other hand, strategic tasks such as planning, estimating and organizing the tests .

Agile Test – The role of the tester in the team

But where do we currently have to classify the tester in the entire team? Baumgartner et al. 2013, p.112 provide an answer in the diagram below: The tester is in close contact with the development team, which feeds him with information or which the tester gets by monitoring the process. He is also in direct contact with the PO (Product Owner) in order to be able to correctly evaluate the development based on the requirements set by the Product Owner, which in turn are specified by the stakeholders. Testers appreciate the Sprint planning now also reduce the testing effort and thus make an essential contribution to the product. As part of my research, I am reviewing these approaches. In his book, Baumgartner clarifies the relationships between the individual roles within Scrum: The tester checks the development based on the requirements of the PO.
In practice, there is a growing test effort in the course of the respective product development. However, according to Scrum, this growth is actually not beneficial, as the test effort should be constant throughout the process and should not increase towards the end, as can be seen in the figure below. In the first interviews we learn that testers work in advance and prepare the tests, so to speak, and estimate the effort. So the testing effort in the observing teams was still the same over the entire duration of the process. The quality was also very high at the beginning.

Basic principles of Agile Test

For this paragraph I am listing some tips for the agile test which I am going to use Wikipedia have found and summarize here.

• • Quick feedback: 2 weeks or less

• • High level of automation of the test

• • Low overhead in the form of test management

• • Dissolution of test roles (test manager, analyst, etc.)

• • Dissolution of the test levels from the V-model (unit, integration, system …)

• Close cooperation in the team (feature teams, tester also writes code from time to time)

Der Beitrag Agile test and Scrum erschien zuerst auf agile Companies.

Baumgartner et al. (2013, p. 3) show in the figure above that Scrum one process for all roles Are defined. In the picture you can see how this one process combines the roles of the project manager, requirements engineer and tester. “Test” as a discipline no longer exists in isolation from Scrum. Rather, like the other roles, the tester becomes part of the overall agile process.

In the representation of Baumgartner et al. (2013, p. 101) we see how the role of the new, agile tester is split equally into the tasks of test manager and tester. Thus, one person or the agile department takes on operational tasks on the one hand – these tasks include the tests themselves, measurements, as well as logging and tracking – and, on the other hand, strategic tasks such as planning, estimating and organizing the tests .

Agile Test – The role of the tester in the team

But where do we currently have to classify the tester in the entire team? Baumgartner et al. 2013, p.112 provide an answer in the diagram below: The tester is in close contact with the development team, which feeds him with information or which the tester gets by monitoring the process. He is also in direct contact with the PO (Product Owner) in order to be able to correctly evaluate the development based on the requirements set by the Product Owner, which in turn are specified by the stakeholders. Testers appreciate the Sprint planning now also reduce the testing effort and thus make an essential contribution to the product. As part of my research, I am reviewing these approaches. In his book, Baumgartner clarifies the relationships between the individual roles within Scrum: The tester checks the development based on the requirements of the PO.
In practice, there is a growing test effort in the course of the respective product development. However, according to Scrum, this growth is actually not beneficial, as the test effort should be constant throughout the process and should not increase towards the end, as can be seen in the figure below. In the first interviews we learn that testers work in advance and prepare the tests, so to speak, and estimate the effort. So the testing effort in the observing teams was still the same over the entire duration of the process. The quality was also very high at the beginning.

Basic principles of Agile Test

For this paragraph I am listing some tips for the agile test which I am going to use Wikipedia have found and summarize here.

• • Quick feedback: 2 weeks or less

• • High level of automation of the test

• • Low overhead in the form of test management

• • Dissolution of test roles (test manager, analyst, etc.)

• • Dissolution of the test levels from the V-model (unit, integration, system …)

• Close cooperation in the team (feature teams, tester also writes code from time to time)

Der Beitrag Agile test and Scrum erschien zuerst auf agile Companies.

Agile in the Waterfallworld

In my Master thesis (Lindner 2015, p. 24) I have already researched the initial situation of agile departments and found that an IT department often has to react flexibly to typical waterfall customers and that agility stops after IT. In the current research project a year later, I notice that agility is slowly leaving IT. But IT departments will still have to react flexibly to each customer. So this has to be an important trait of the next level of agility. You can find a whitepaper: Agile team teams in waterfall organizations free to download in my blog.

Antifragility and Resilience

Resilience is defined as the ability to have a high level of resilience. In recent years, resilience has been described as one of the most important characteristics of an IT department. The representation based on Bargstedt et al. (2015, p. 279) shows exactly how B. after a server failure, the system is restored as quickly as possible and you even emerge strengthened from such a failure. This could be done in the form of a retrospective. This collective mindfulness and the possibility to briefly dissolve a current form of organization are the signs of good and healthy resilience.
Taleb (2013, p. 1) shows in his book that everything man-made is fragile and could be permanently redesigned. Events that cannot be planned, ie “black swans”, are an ever-increasing dilemma in IT and demand resilience from all those involved. Because, as is well known, an agile team has to save the world anew every day and often use “magic” to do so.
I also have a really successful one Presentation on Slideshare found. It is currently one of many presentations that the abstract approach of anti-fragility as “Beyond Agile”.

Agile fixed price

Gloger & et al. (2012, p. 32) published their book “The agile fixed price” a framework for drafting contracts for agile software development. This setting of the time and budget for agile projects has been well received by the IT scene. However, the implementation is still difficult, since customers typical of waterfalls are still too happy to specify the software precisely in order to then want to change it again and again. For “Beyond Agile” I would especially like more agile fixed prices.

HR and agile software development

Skilled workers! Specialists are called for everywhere, especially in software development. Because of this, HR will play an important role in HR. The question is not how I find developers for my agile software development, but how I find the real agile software developer. How do I reach this person, where is they and, above all, how do I keep them with me in the company? I already have a detailed article about agile HR written here on the blog, which deepens all points in this paragraph. After agility, one approach will definitely be to offer developers new and exciting career paths such as junior scrum masters and also new challenges for the product owner. The illustration is from Gloger & Häusling (2011, p. 89) .

Hybrid Agile?

Or will Scrum mix with other methods in the near future? Will state-of-the-art hybrid models shape modern companies and the “Beyond Agile” trend? The following concept also comes from my master’s thesis (Lindner 2015, p. 91). All departments are constantly tipping in new requirements. A Requrements Engineer writes user stories and the user stories are processed either by a Kanban team or an agile team. In the case of smaller and unrelated user stories, the Kanban team consistently delivered the best results. The scrum team planned larger projects. The employees could also be exchanged between the two teams as often as desired. We also coordinated larger projects with a steering committee and obtained the necessary resources or budgets in good time. Despite many methods, we had harmony in our IT department.

Beyond Agile?

I have one for this answer Blog article by Boris Gloger found. He’s talking about Scrum 3.0 here. So says Boris: Scrum has evolved. A management framework, an attitude, an approach that can be used to control entire companies. Scrum has become the de facto standard in the agile project management landscape and we know today how cross-functional, multidisciplinary teams can work across continents in software and hardware development.
Boris Gloger also has an answer to the question of what Scrum 3.0 is. He says: Scrum 3.0 no longer includes what was in Scrum 1.0. Today we can no longer tell the old camels, because over the years they have proven to be non-functional. In addition, the possibilities have changed. He formulates some facts about this, of which I would like to present 10 selected ones. He says: Scrum 3.0 knows today

• that there is such a thing as “flow”,
• that you also need the skills to work with Scrum,
• that remote working is no longer evil,
• that of course we want to make fixed prices,
• we focus on improving one thing
• We know that agile scaling will certainly not work with the next models (although it can be sold well), but only succeeds if the architecture allows it and that
• the developers need to have the skills to do all of this.

Der Beitrag Beyond agile and agile software development erschien zuerst auf agile Companies.

In order to establish an agile sales department or agile sales, new processes and flat hierarchies are required

In order to install such an agile department, agile processes have to find their way into sales. For example, sprints as part of SCRUM can bring more momentum to the department, which leads to faster results and better internal communication. A more democratic sales department, in which employees can get more involved, also increases the possibility of discussing interesting sales concepts and ultimately implementing them.

Customer Experience 3.0 and agile sales

The figure from Goodman (2014, p. 23) shows where customer feedback on the products mainly arrives – namely somewhere, just not with the manufacturer and the company’s sales department. In the end, only 5% of customer feedback is addressed directly to the manufacturer. After all, up to 25% of the feedback reaches the retailer or individual, specific sales channels – but not the sales department. Feedback, which can relate to both the products and sales methods.
It is therefore usually irreplaceable to make the channels so permeable and transparent that the feedback from customers reaches all links in the sales chain to the same extent. This is the only way to act and react in a customer-oriented manner in the sense of agile sales.

Gloger & Margetich (2014, p. 184) show how important such a feedback loop is. Every child knows that word of mouth is essential. And only satisfied customers will report positively on their own, recommend the company’s products and thus indirectly contribute to further sales.

Agile sales: key account manager as an important component

According to Richards & Jones (2009, p. 312), experienced key account managers are another extremely important component. As the central interface between the company and important customers, an experienced key account manager responds to the specific needs of the customer and makes a significant contribution to establishing such a feedback loop. A decisive factor in creating sustainable transparency and thus satisfied customers. The other part is made up of the entire department, which processes this feedback and may have to adapt sales methods accordingly. In addition, as part of the agility in the entire company, the feedback should also leak to development in full in order to be able to react flexibly to desired product changes.

Profile of the key account manager

On the side of the Sales manager I have found a great overview of what a key account manager should be able to do and would like to summarize this here. Because an account manager is more than just a salesperson. He is also a friend and confidante of the customer.

Know your own product

Here the article recommends building up product and industry knowledge. You should know exactly what you are selling and who you are selling it to. This ensures that the customer has the necessary expertise and shows that you are selling “honestly” (you would also buy your own product yourself).

Know the goals of the customers

Here says the article of the Sales manager : It is not enough just to know your own product and company. A successful key account manager knows the goals of his customers and the obstacles that stand in their way. So he understands the customer and thinks along with them. He has also built up a high level of trust and strives for a certain long-term relationship with customers.

Clear and easy communication

Here he says items : When it comes to selling highly technical products, it is important to be able to give clear and simple answers. But this simple and understandable communication is not limited to communication about the product: it is also important to maintain customer relationships apart from sales.

Learn learn learn…

The article says briefly about this: All of the previous points have one thing in common: They require continuous learning. Whether it is knowledge about one’s own product, the industry, customer development or methods of communication: In today’s world, what was just “state of the art” will be out of date tomorrow.

Agile sales need the agile fixed price

Of the agile fixed price is a contract model for suppliers and customers in IT projects that are carried out using agile methods. The contract model stipulates that after an initial test phase, costs and deadlines are set and a procedure for controlling the scope (“scope”) is agreed within a fixed framework Wikipedia .
Overall, the article and many other 6 steps to set such a fixed price so that agile sales can take place.

• In the first step, the rough level is described. This includes the vision and high-level epics. So a rough framework.
• Then an epic representative of the project is selected and specified down to the level of user stories. In the case of a suitable epic, a sufficient number of user stories of different types and with different scope of functions is created, which may be considered reference user stories ( Wikipedia )
• Using the reference user story, other epics can also be determined, and effort and risk can also be determined.
• In the fourth step, the checkpoint phase is defined, which is the test phase for the cooperation, since implementation begins there and the first empirical findings are obtained. A length of between two and five sprints is recommended (with a sprint length of two weeks). At the end of the checkpoint phase, the customer and supplier review the assumptions made at the beginning and decide whether they want to implement the overall project (source Wikipedia )
• In the 5th step, the roles such as PO, Scrum Master etc. are named.
• In contrast to classic fixed-price projects, with agile fixed-price projects, the project is ended when the customer considers the expected benefits from the deliveries already made to have been fulfilled. This can happen before all the agreed functionalities have been delivered. Agreements must be made so that this flexibility is advantageous for customers and suppliers. For example, the supplier can receive a percentage of the price of the remaining volume or can be assured of a new order worth the remaining volume, see above Wikipedia .

Der Beitrag Agile sales and agile sales erschien zuerst auf agile Companies.

AGILE production and new business models

Kaufmann (2015, p. 12) shows an initial trend with regard to agile models: The focus with this approach is not exclusively on intelligently communicating machines, but on a fundamental adaptation or even realignment of the (existing) business models. Above all, adapted products and shorter delivery times are taking a step towards agility. The main focus is on increasing quality and shortening delivery times.

Agility in Industry 4.0

The way to agile Industry 4.0 is still a long way. Kaufmann (2015, p. 15) clearly shows that this new, agile industry is still in its infancy. In order to drive further development towards fully agile production, constant cyclical reflection must take place: From machine, operating, product and business data, optimized processes must be carried out using forecasts for the piece-specific or consumption-based billing as well as for services that increase product value or additional products (value-added services) . You have to constantly learn which practices work and which don’t.

In order to remain adaptable at this point, the following approaches are recommended:

• • Iterative and incremental development in defined cycles (e.g. 4 weeks)

• • Delivery of a partial product or product increment after each cycle

• • Feedback and correction after each cycle

• • Iterative changes and detailing of the product requirements after each cycle

• • Fixed budget and resources with variable functionality

• Daily coordination of the development team, also with the stakeholders

Lean ISn’t the same as agile

Even if there is a lean production characterized by very flat hierarchies and many principles act agile, is that Lean Production not completely agile in itself.

In order to be able to better serve customer demands, the production philosophy of “Agile Manufacturing” was created. In response to lean production, the focus here is primarily on meeting flexible customer requirements without incurring new costs or having to cut quality. The idea of the virtual company is the father of the thought: relationships with suppliers should be flexibly and quickly geared to the respective market opportunities.

The Warehouse control is considered to be of little relevance in agile manufacturing. The fulfillment of customer wishes and thus customer satisfaction is given more importance than the pure production volume. So that these demands can be met, needs Agile manufacturing a self-sufficient and intelligently collaborative workforce. The structure can then also be described as an “agile company”.

Agile manufacturing

Here says that Gabler Business Lexicon the following: Agile Manufacturing is a manufacturing philosophy that focuses on meeting customer demand through flexible manufacturing practices. Agile manufacturing emerged as a reaction to lean production. It differs in the focus on that Fulfillment of customer requests, without sacrificing quality or additional costs to accept. The idea is based on the concept of the virtual company and aims to build flexible, often short-term relationships with suppliers when market opportunities arise.
To make it clear where this trend is coming from, I recreated a graphic from Slideshare. It shows how agile manufacturing and agile logistics work together effectively. It turns out that a lot of trends have an impact and that production has a long history with many influences around lean, agile and other frameworks.

Scrum and Holacracy in production

On the Production.de portal I found the following: Scrum is the implementation of lean development for project management. The procedure has so far been established primarily in the software industry. A team works step by step across departments on the development of a new product. Due to the complexity of the project, the result cannot be precisely planned in advance. So does Scrum make an agile production?
Scrum in production? Is that possible? That’s what he says items to: Scrum is now being used across the board by all teams throughout production. Small subteams meet daily on a visualization board, they discuss the work packages and the achievement of goals. In doing so, they exchange ideas about what can help them to achieve the goal. The team that takes care of the product transfer from development to production, the Production Engineering team, is now working with Scrum.
Continue to even Holacracy used in production. So Holacray as an example of agile production? The latest example is from the Cinteo company. On his Website says the company : The automotive industry is currently experiencing the most drastic change to date and has to face unprecedented challenges: New mobility requirements, new business models and sources of revenue, new competitors, new regulatory and sustainability requirements, shorter technology cycles and the additional pressure to be able to innovate faster are fundamentally changing what has been happening so far successful value creation and its management. Skills in the areas of digital customer engagement, e-commerce and business model development are critical success factors.
So Holacracy was one way of doing this for the company. So it says on the website: “Holacracy is a third way: It brings structure and discipline to a peer-to-peer workplace. For us this means: effective meeting formats, more autonomy for our employees and a unique decision-making process with constant change and improvement!”
But how does the company implement this? I looked around the website and gathered the following insights: Holacracy is implemented through vision and ideas as well as the inclusion of customer feedback in production. The idea of functional teams, which apparently produce a product end-to-end instead of just looking after a single interface, is also used. Furthermore, many cross-sectional functions were created and KPIs introduced. So much for the information on the website.
[werbung] Verwendete Quellen anzeigen

Der Beitrag Agile production in Industry 4.0 erschien zuerst auf agile Companies.

The modern manager

The figure from Appelo (2010, p. 370) shows the modern, agile manager as a being with many eyes. In order to act successfully, the manager directs his or her own focus on many things at the same time. You not only have to create clear structures that motivate the agile team at all times, but also expand your own skills. By looking at general innovations and developments outside of your own company, agile management must always develop new skills and is therefore always up to date. The numerous eyes give the manager a 360 degree view through which he sees the big picture.

Agile management develops people

To Appelo (2010, p. 155) are three the main tasks of managers to develop people, to protect the employees and to guide them in their personal development within the company. How agile human resource management manages to find agile employees and even do justice to the new role of HR, I already saw in the Article on agile HR treated.

Complexity in management

The figure from Appelo (2010, p. 52) illustrates the complex systems that executives feel exposed to. It is not uncommon for this complexity to lead to lethargy with regard to important decision-making processes. Decisions, if at all, are often not made until the deadline. Modern, agile methods such as self-organization and halocracy can soften the complexity and make the possibility of decision-making more transparent.

Models like holocracy (see my Article on holocracy ) can quickly drift into a kind of anarchy, which is not good for the corporate culture at all. On the other hand, however, they want to move away from old, deadlocked structures and soften those too strict, non-transparent order. So the role of agile management is to rule the chaos and create order within the Holacracy. In other words: Agile management creates a balanced, perfect relationship between anarchy and dictatorship. Tip: read mine too Article on complexity in management .

Agile management against complexity

Most organizations are set up according to a classic hierarchy. According to Appelo, this is not agile and is actually not really lived. That is why Appelo calls for a hierarchy for organization and an informal structure for the network in the company. This means that every single employee in the organization is networked with the others.

Appelo also suggests another agile approach to the solution. So the idea is that organizations fundamentally establish a classic project business. These are supported by internal service providers. These are specialized teams such as a GUI team. These teams have an agile mindset based on offering excellent service to the project teams and supporting them as much as possible. A similar approach was used in the 2. Roundtable on digital companies conceptualized.

Dimensions of agile management

There are now no direct criteria as to what constitutes agile management and what does not. It is clear, however, that certain indicators can be defined. So I already have some in the article “ What is agility? “ Are defined. But also with Heap there are criteria. These are:

• the agile target image
• customer-oriented organizational structure
• iterative process landscapes
• Employee-centered understanding of leadership
• agile personnel and management tools
• the agile corporate culture

So, first of all, a target image should be determined. The question is: What do we all want to achieve in an organization and how can we offer our customers maximum added value? Decisions in agile leadership are also made differently – as Haufe says: For decision-making in organizations, this means that decisions are made where “knowledge and not disciplinary power resides.”
This is usually quite clear with the developers themselves, who are in contact with the customer. In the consulting example, there are consultants who are on site at the customer’s premises. The working method itself is also changing, according to Haufe: The concept of agility includes short, manageable planning and implementation cycles with concrete results (“prototyping”), so that immediate adaptation to changed framework conditions is possible (“inspect and adapt”). Errors become visible at an early stage and can be corrected at an early stage, priorities are regularly questioned and realigned.

Stumbling blocks for agile management

But implementing agile management is not easy and does not always run smoothly. That’s what he says Havard Business Manager In a nutshell: Often times, teams are overwhelmed by the changeover to agile management systems. After all, more freedom also means being open when something is going badly – and accepting criticism from equals when results fall short of expectations. If you want to avoid unnecessary frictional losses, you should therefore define clear rules for cooperation before the transformation – also with regard to vacation, salaries and working hours.
So the magazine cites human worries or loss of status. Employees are often in a certain routine that offers security and believe that the agile change will worsen their position or are generally afraid of the high level of uncertainty of possible self-organization. Agility therefore requires different skills than working in a classic hierarchy. In the end, the magazine summarizes: “Managers who want to change their organization should therefore make sure that their employees meet the necessary requirements.”

Summary

There is no doubt that traditional management is in crisis. In an increasingly complex and changeable world, management principles that have been quite successful in many areas in the last century seem to be reaching their limits. It is becoming more and more obvious that an understanding of leadership based on individual specifications and control no longer works in today’s world – in a time when it is primarily about creative knowledge work, complex tasks and flexible reaction to changes in the market.
The limitation is that Appelo developed its approach in 2010 and it is already very mature. New findings build on his explanations and expand the model with new approaches. In the course of the research it will be shown how these approaches can help companies to transform themselves in a digital world in a sustainable way and to react to the massive speed of technical progress with the help of agility and change.
[werbung] Verwendete Quellen anzeigen

Der Beitrag Agile management erschien zuerst auf agile Companies.