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.

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.

Lean startup

As early as 2011, Eric Ries showed in the illustration above that precise future planning for a product is no longer possible. Rather, today’s times require a quick release of the respective product in order to be able to collect data after the market launch that can flow into the further development of the product. Before the release, on the other hand, you can only make assumptions, which may result in significant additional effort in rework.

Product development

As part of my research, I ask what modern and agile product development looks like today. Have the agile lean startup methods, which Ries first mentioned in his blog in 2008, already found widespread use or companies are still working with specifications and a pronounced advance development.

Business model innovations

Gassmann et al. (2013, p. 6) illustrate how few product innovations manage to establish themselves on the market today. It is easy to read from the book that Industry 4.0 models for companies can be the key to sustainable, successful innovations.

Agile product development: incremental and iterative

The principles behind more agile Product developments are as increments and iterations. But what exactly does that mean?
She says about iterations Scrum Academy : In an iterative process, improvements are made gradually. If a team determines that a system is not yet finished or not good enough in some areas, it improves these points step by step until the product is satisfactory. With each iteration, adding more details improves the software. The Scrum Academy names sculptures as an example, in which the sculptor first roughly works on the head and body and then slowly works on the details.
On the subject of increments, the Scrum Academy says: In an incremental process, software is developed and delivered in individual parts. Each of these parts – or increments – represents its own complete functionality. The size of the respective increments is completely irrelevant. Furthermore, the Scrum Academy complements the example of the sculptor: A sculptor who works incrementally will concentrate on part of his work until it is completed. These can be small increments (first the nose, then the eyes, then the mouth, etc.) or large increments (head, torso, legs, arms).
[werbung] Verwendete Quellen anzeigen

Der Beitrag Agile product development and agile research erschien zuerst auf agile Companies.

In the digital age, however, the good old checking account and the general business model of the established banks are facing several new battles. For example: Deposit vs. Blockchain – Creative FinTechs can be a kind of interface between the New World and the Old World and make finance, you hardly dare to pronounce it – agile.

Established banks in crisis

Not only numerous studies and reports suggest: The major German banks are once again in a crisis that is much larger than one thinks. Deutsche Bank, Commerzbank and Co not only suffer from the tough equity capital regulations and the ECB’s low interest rate policy, but they simply lack a promising future concept. Because after the last crises, the confidence of Otto normal bank customers has reached an unprecedented low.
FinTechs start right here and want to offer financial services for the future. It is not just payments and transfers that are two of the numerous areas in which FinTech companies are on the rise. Another line of business is personal finance management. In this area, for example, algorithm-controlled asset management options are being developed. In summary, it can be said that, instead of investing traditionally, FinTech start-ups, more than the established banks, “experiment” with new technologies and also have other investment portfolios. This means that FinTechs are far more agile when it comes to adapting to rapid economic changes than the big banks will ever be. Nevertheless: FinTechs are not revolutionizing the monetary system, even if new payment and investment options make it easier to deal with “money” – whatever this may look like in the future.

Agile FinTech startups on the rise

According to a ranking by the consulting company KPMG, the service providers Lufax (China), Zhongan (China), Oscar (USA), Qudian (China) and Ant Financial (China), a company from the online network, are now among the 5 best FinTechs in the world Dealer Alibaba. With a clear focus on online payment, Ant Financial also offers additional financial services for small and micro companies as well as for private individuals. In addition to the payment service, the range of services also includes asset management, individual credit checks, reporting and services from private banking and cloud computing.

Agile finance and the digital transformation

Although FinTechs overtake the long-established banks with new types of financial products and services, FinTechs cannot do without them either. Because: Even a successful fintech like Weltsparen simply has a fixed-term deposit with international banks as its business model. If they fail to cope with their fundamental crisis, the FinTechs will also plunge into a first profound crisis at some point. In addition, it is easy for banks to copy the services of the best and most popular FinTechs and implement them in their own model. Thanks to the gigantic reach in marketing, the banks could catch up again.

Big banks catching up

In addition, the big banks have much greater resources to invest in technologies that can actually revolutionize banking, while the existing start-up financial service providers are mainly entangled in a network that makes them dependent on international banks. According to a current report by Manager-Magazin, Deutsche Bank describes the blockchain as “one of the first really disruptive ideas from the fintech sector”. Even the former JPMorgan manager Blythe Masters is causing a stir with a blockchain startup and indicates that in less than two years the blockchain will have arrived in every bank in the world. That and nothing else could actually completely turn finance upside down. In addition to the still successful Bitcoin, there is, for example, an interesting project on Ethereum that the big banks are observing with eagle eyes. Such technologies not only change the way money is managed, but also how money is made.
In today’s banking world, money is simply created through a booking record when a loan is granted. Incidentally, this is also a reason why the state can never pay off its debts. While philosophers like Aristotle and Plato were still puzzled over whether the monetary value was created by the metal value of the coins or by the face value that the state stipulated by decree, money is now “produced” through debt. As soon as a bank grants a loan to a private customer or a state, this amount is credited to their account. Actually, however, this is only a claim from the bank to the customer, which is for cash. Because interest (and compound interest) is assessed on the amount allocated, more bank money has arisen than there is any cash (work done in society). A system of money creation that cannot go well forever – after all, the exponentially growing debt that has arisen has to be borne by private individuals and companies.

Blockchain FinTechs as a revolution in the financial world

To come back to the example of Ethereum: Founder and developer Vitalik Buterin was already so interesting for the CIOs and CTOs of the big banks and fund companies at the beginning of the project that they sounded meek at an event in the Swiss embassy, like his lines of code their big empires in the future will make it superfluous. Just like the popular Bitcoins, Ethereum is also based on blockchain technology. The difference: Ethereum is not a pure cryptocurrency, but a platform for distributed apps that consist of smart contracts.

CONCLUSION

Due to the triumphant advance of successful FinTech start-ups, such as the deposit broker “Weltsparen”, the financial sector is becoming agile, but the companies often do not represent the revolution of the sometimes messed up financial system – at least with a few exceptions: Especially those FinTechs that focus on the blockchain Technology will certainly become even more important in the long term. The big banks see their existing hegemonic position in jeopardy and are working hard on new methods, but their masterminds are mostly the innovative start-ups. In the future, it is very likely that different groups of FinTechs, each of which cover different areas in finance, will combine the business areas to create a highly agile network of value creation and financial services.
[werbung] [fotolia]

Der Beitrag Agile Finance and Agile FinTech erschien zuerst auf agile Companies.