What are the reasons: Political instability, new trends, new technologies, competitors and a still unknown Generation Z make long-term planning almost impossible. Even employees seem to have the motto when changing employers: “After three years you can, after five years you have to!” to be taken very seriously.

Often the reasons mentioned force managers to opt for short-term success, as this is foreseeable and measurable. But how can you keep a balance between long-term and short-term success? In this article I analyze both types of success and summarize the findings in concrete recommendations for employees and managers.

Prepare: the marathon runner

Short-term success is like a sprint. With enough carbohydrates (energy) in your body, you can sprint quickly and be successful. Surely you have already walked such a route or at least ran to the next ICE to catch it in time. The consequence: short-term success and you have to take a deep breath first.

A marathon consists of different stages and often the runner cannot say exactly what weather or what obstacles await him on the way. That’s why he does the following: Exercise and keep fit. He practices sprints but also long runs and gathers experience with different weather conditions. There are stages in which he can run quickly and there are also stages which make it difficult for him to make progress.

Use energy correctly: the green sea turtle

I have a great story in the book: The cafe on the edge of the world ” found. The protagonist Casey is an avid swimmer and likes to snorkel on reefs. During such a snorkeling trip you will meet a green sea turtle and swim with it. But something exciting happens: The turtle, which seems so leisurely, has hung up as a skilled swimmer. Casey meets the green sea turtle again while snorkeling and watches it closely.

She notes that the turtle never fights against the current. She slowed down her movements and only paddled enough to stay in place. Only when the wave flows back into the sea does it use this current for itself and make a stretch. Casey, on the other hand, always tried to swim with the same amount of force.

We too have to struggle with difficult times in life when circumstances are not favorable due to the market or management. It sometimes helps to just wait and not waste so much energy. Use the time to think about the future and wait for the next wave.

Conclusion

Professional life is made up of phases of progress and phases of standstill or resistance. Use these phases for short-term and long-term success. Now I would like to summarize the findings in concrete recommendations for employees and managers

For Employees : Use good projects and high phases of the company to achieve short-term success. But then you can also use rest periods and standstill to read and to exchange ideas with technical experts about possible topics in the future.

Reading tip: Employability

For Manager : Use good market positions to be successful in the short term and implement customer requests quickly and flexibly. Use short reviews and vacation periods of the customer to change the company and exchange ideas with experts.

Reading tip: Agile management

Der Beitrag Maintaining a balance between short-term and long-term success erschien zuerst auf agile Companies.

• What is the current status of the scaling of Scrum in corporations?
• What are the challenges?
• How could this be solved?

tip : You are welcome to read additionally what the Differences between medium-sized companies and corporations are.

Scaling agility in corporations

The last time I was really active as an agile consultant in corporations in 2015, the first teams were organized according to agile methods. The position of the team leader in particular was criticized and its importance in an agile world was questioned. I found the following scenario (see illustration).

The teams were based on agile methods, had a Scrum Master (usually someone in the team did it on the side) and a Product Owner, who was either on the team, the team leader or someone from the specialist department. These were often the first steps and my task was to bring agile processes closer to the teams.
Reading tip: Scaling Scrum
Now I was back on site and was guided through the new, modern corporate premises. It was impressive what was built there. There are 8 tables each (1 Scrum Team) with one board. Then there was a small partition or piece of furniture for the next agile team.
I was very surprised and excited when I saw the organizational chart. Because the three corporations have made insane progress and have almost broken out of their structures. For me, there was a flatter hierarchy with 30 to 50 agile teams, which are jointly led by 1-3 department heads as well as 5-10 Scrum Masters and 5-10 Product Owners. In addition, there were many other roles such as the Feelgood Manager or similar staff positions.
The following figure shows the scenario using a fictitious group. There are 18 teams as well as 3 Scrum Masters and Product Owners who lead the department. You already notice that a Scrum Master and Product Owner have to look after 6 teams. There are also two department heads who jointly manage disciplines and exchange ideas.

I have to say that I was really excited about what has happened over the years and I think this is the right way to go. The transformation has not stopped for a long time, but it is making great strides. I found it exciting that the team leader role has dissolved and the department heads are already beginning to lead together. I think it took a lot of work to do this. I would therefore like to express my great appreciation for the three corporations. If you want to see another approach, you can take a look at my 2nd roundtable.
Reading tip: 2. Round table for scaling Scrum

Challenges: agile Taylorism and Scrum Master

Corporations are currently in a state of great upheaval. Agility is much more difficult to implement and research, especially due to the large number of people. In the conversation we focused on two main areas. On the one hand, this is the real performance of the new organization and the fact that this form of organization is heavily dependent on the Scrum Masters and the corporations are unable to find enough suitable Scrum Masters. I will now explain both challenges in more detail.
Agile Taylorism Risk
Agility is behavior, mindset and culture. It is common knowledge. For this reason, coaching and teaching the agile mindset are important. This is currently a point that managers want to increasingly implement. Without a corresponding culture and framework, you steer into agile Taylorism. What do I mean by that?
Central points of Taylor (1911) were that the main focus of a business organization should be directed to achieve the highest possible economic utilization of the workers and the machines. In concrete terms, this means that workers and machines should achieve their highest productivity, their highest efficiency. Another goal is the division of work into the smallest units. In this way, every employee can concentrate on a small part of the work and do it better and faster. Today we know that precisely this work leads to demotivation and monotony in the execution of tasks. The criticism of Taylor can be found in the “humanization of work”. Agile work / agile methods are seen as an alternative.
So let’s imagine that 40 agile teams each have a Scrum Master who wants to get the most out of the team. The individual components of the software are also strictly divided between the teams (one team makes payment, the next makes contact forms, etc.). If we compare this with the previous paragraph, we notice that we have agile teams, but at the same time we also implement Taylor’s ideas very precisely. For this reason, the managers of the corporations are increasingly focusing on this, since the achievement of Taylorism is not the goal.

Lack of Scrum Masters

You can see that in the fictitious example, three Scrum Masters have to accompany a large number of teams. This is a tough job. In none of the three companies were there enough positions on the one hand and enough applicants for the position of Scrum Master on the other. However, precisely the position of the Scrum Master is decisive for the success and the communication of the agile mindset. I therefore like to refer to the Scrum Master as the “extended arm of agility”. So we have talked about this point in more detail. The current challenge, according to the manager, is that Scrum Masters can hardly be found, although many positions are open. Nice Boris Gloger stated in 2012 : “Of the 600 that I train alone each year, shouldn’t 10% really want to do Scrum each year? But that is not the case, as I often notice. There is demand, but hardly any people who want to work as Scrum Masters. What’s going on there?”
But why doesn’t anyone want to become a Scrum Master? We asked some employees and Scrum Masters, who only held the position for a while. In summary it was said:

• Scrum Masters have no enforcement skills (no leadership – toothless tiger)
• Scrum Masters have a lot of responsibility (sometimes 5 teams) and they are not adequately remunerated.

Overall, the job was described as very ungrateful. It is certainly tough, because in the example alone, a Scrum Master (8-man Scrum Team) has to lead 24-32 developers. As important as the position of Scrum Master is, it is also difficult to fill it. In this regard, I was already wondering why many recruiters are currently looking for Scrum Masters for corporations and why freelancers are a dime a dozen as Scrum Masters.

The solution

I then brainstormed with all three corporate managers on how we could tackle the current challenges. You presented me with current ideas and I showed my research results.

Against agile Taylorism Cross-functional with OKRS

First, we discussed how the notion of agile Taylorism can be prevented. In addition, there was initially the idea that teams should not be set up according to components (unless there is no other way). Thus, cross-functional teams are to be formed. As a result, a wide variety of experts such as testing, requirements engineering, backend and frontend developers, etc. are mixed in the teams. This is also known under the term feature teams.
In order to maintain controllability, motivation and control, we found the concept of OKRS (Objective Key Results) very exciting. OKRS means that you measure performance against team goals. I explained this in more detail in another article. In the first attempt, three teams should be controlled via OKRS. I’m excited to see the results and I’m currently trying it out with my team as well.
Reading tip: OKRS – the agile management method

Solution to the Scrum Master dilemma

Scrum Masters are very important, especially in this form of organization. I therefore also believe that solutions for the Scrum Master positions are not that easy at all. If you give more skills, then you can use the old team leaders again. Rather, I think that the problem of the Scrum Masters can be solved with the Holacracy approach.
A special pain point is the Scrum Master’s lack of penetration. The aim would therefore be for a Scrum Team to be founded from the Scrum Masters and Product Owners, each of which also has a Scrum Master and Product Owner. These two have certain competencies and are elected by the team democratically or by consensus. So this role can also be changed. You could call this the Chief Scrum Master and Chief Product Owner. The department management could then act as a coach for the agile team of Scrum Masters and Product Owners.
Reading tip: Holacracy

Example from the middle class

I am also currently scaling the Scrum method to several teams in my job. I am currently working for a medium-sized company and of course I don’t have 50 teams, but 5 teams. All of them work for different customers who each provide the product owner, which is why we do not have our own product owner. However, every team has a Scrum Master. This ensures that the customer’s requirements can be met and that the team can work according to Scrum without any disruption.
Our approach is to include the Scrum Masters on an extended management board. This board can jointly make decisions by consensus. Thus we give the Scrum Masters a forum to enforce decisions. We hope that this will give the Scrum Masters position the necessary impact.

Conclusion and limitation

Of course, these were only the results of half a day’s discussions and I certainly haven’t covered all the details. There are further experiments by the corporations such as the appointment of Chief Scrum Masters etc. However, there was not enough time for this or the managers are trying it out and rather wanted to exchange views on points that are currently important to them.
Nevertheless, I believe that we were able to get to the heart of the matter and find two exciting challenges and possible solutions. If you also work in a corporation, write to me via email or in the comments whether it is similar for you. I have to express my respect to the corporations because they are really far advanced and the journey to agility has already taken shape. I too recently finished a change. You can find this story in another article.
Reading tip: My story as a change agent
[yop_poll id=”45″]
[werbung]
Verwendete Quellen anzeigen

[fotolia]

Der Beitrag Scrum in corporations – how do I avoid agile Taylorism? erschien zuerst auf agile Companies.

• Appointment of a Scrum Master (changes every round)
• Sprint Planning 1: Game master prioritizes and explains the first 10 user stories (5 min)
• Sprint Planning 2: Scrum Master and team appreciate the stories (1,2,5,8,13) (5 min)
• Start of the sprint (5 min)
• Review (5 min)
• Retrospective (5 min)
• Draw a burndown chart
• next sprint with new Scrum Masters

Events
These random events can be played in randomly by the game master.

• An employee is sick (skip a lap)
• An employee has to attend further training (suspend the round and read the Wikipedia article on Scrum on the smartphone)
• Product defect (all planes will be destroyed)
• Arbitrarily change a requirement (increase or decrease)
• The balloons can be given to any employee (not a game participant). You tell the participants that the balloons are in room XX. As a sprint item, the players have to find out who has this.
• The material runs out and has to be procured. Give a friend of yours (not a game participant) check slip and send the other player with the order to fetch lined slip of paper. If he only comes back with a slip of paper, you as PO don’t accept the story.

Shopping List

• 6x dice
• 3x block (white, lined, checkered)
• 1x playing cards
• 50x candies
• 50x balloons
• 2x drinks
• 2x fruit

Downloads

Download UserStories and accessories here (click here)

Tip: get the whitepaper too: Agile teams in waterfall organizations free!

FREE AND SECURE DOWNLOAD THROUGH VIRENSCAN

For absolute security, the website is regularly checked for harmful software. The project is funded by the Federal Ministry of Economics and Technology as part of the “IT Security in Business” task force. You can download it anytime without worry.

[werbung] [fotolia]

Der Beitrag Scrum simulation for download! erschien zuerst auf agile Companies.

Awarded the German Study Prize

The master’s thesis behind the whitepaper was awarded the GPM German Study Prize for the best master’s thesis 2016 on project management. Attached you will find Participant brochure and the Certificate .

Agile in the Waterfallworld

The whitepaper was created from my master’s thesis, which I wrote in 2015. The whitepaper is a summary of the results of the master’s thesis. For example, SCRUM and Kanban have been established as successful models in software development for a number of years. However, incorrect synchronization with other methods often results in decisive change management, unclear roles and tasks, a significant loss of cooperation in the course of the project, errors in project estimates and a lack of reactions to changes. Based on specific best practices, this whitepaper is intended to present a model with which agile methods can be successfully established in waterfall-typical organizations without changing the positive properties of existing structures. Through interlocking coordination across the entire project, massive change requests and errors are significantly reduced.
See also for more information Information page too agile in the Waterfallworld! Here I have prepared the content graphically and put it online as Powerpoint.

Safe download through virus scan

For absolute security, the whitepaper is regularly checked for harmful software. The project is funded by the Federal Ministry of Economics and Technology as part of the “IT Security in Business” task force. You can download it anytime without worry.

Download the whitepaper for free!

Download the whitepaper for free after registering for the newsletter. I pay close attention to the newsletter data protection !
[newsletter]

[fotolia]

Der Beitrag Agile in the Waterfallworld – agile teams in waterfall organizations 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.

[werbung]
Verwendete Quellen anzeigen

Der Beitrag Beyond agile and agile software development 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.

Scaling Scrum with frameworks

Scrum is widely used among agile development frameworks. The challenge here: Scrum is based on the work of a small team and does not initially provide any solutions for use in a large organization with a large number of teams. As a result of this need, various approaches to scaling agile procedures have emerged in recent years. In the following you will find an overview of the relevant frameworks, as well as an assessment of the measures and costs. To make the assessment easier, I have taken each employee at a cost of 100 euros per hour. So it’s like buying every employee in as a freelancer. Each framework tries in its own way to find an answer to the question: “How can you scale Scrum”. In the end, I had dialogues with agile coaches and Boris Gloger in order to be able to say how Scrum can be scaled.

Scaling Scrum with Scrum of the Scrums

The simplest approach to scaling Scrum is Scrum of Scrums. Imagine a project with six teams. Each team in turn consists of 8 team members. All teams hold their own daily scrum meeting. Thus, another Scrum Team, consisting of the Scrum Master of the first team, is formed. Experience shows from our experience that basically one Scrum of Scrums level should be formed per 6 teams, as shown in the figure.
Scrum of Scrums sounds simple, but this approach is much more than a simple division of teams, as experience has shown that work can often be redundant and a holistic view of the project is not guaranteed. A best practice is to hold the team meetings at different times in order to enable each team to assess the work of the other teams and then to discuss the whole project in a meeting of all teams (Scrum of Scrums). Here, for example, all Scrum Masters exchange information on the cross-team processes. This team also has a Scrum Master, the Scrum Master. Independently of this, it is also advisable to hold the dailies offset so that each team can visit the other’s daily and thus receive information from other teams. In the subsequent Scrum of Scrums, the cross-team problems are discussed.

Overall, Scrum of Scrums is a good approach to easily scaling Scrum. One point of criticism is that the strengths of a Scrum of Scrums lie mainly in the exchange and coordination between teams and less in overarching planning. A Scrum of Scrums is not a planning process in the actual sense, but a constant exchange. If a consolidated plan is required, this must be drawn up separately. My experience shows that this lightweight concept works for up to 6 teams, but with more teams it slips into a too high level of abstraction (scrum of scrums of scrums of scrums). This results in little effort for the introduction, but a high risk that it leads to problems when scaling with more than 6 teams.
Overall, Scrum of Scrums requires the following measures: Formation of a coordination team and coaching of these Scrum Master teams. This causes different transaction costs depending on the size. However, these costs are quite low in relation to the effort up to 6 teams, as each Scrum Master has to hold a few additional meetings here. If there are more Scrum levels, i.e. Scrum of Scrums of Scrums, additional full-time scrum masters are required to coordinate these teams. With 6 teams, Scrum of Scrums causes additional work for one team. At an hourly rate of 100 euros, that would cost 128,000 euros per 6 teams (8 people) and 384,000 euros for 12 teams (2 Scrum of Scrums of Scrums Team + one additional level). The effort increases extremely sharply with more than 6 teams and is therefore only in a healthy ratio in the cost / benefit ratio with a maximum of 6 teams. For further information, please also note this Book by Gloger .

Scaling Scrum with SAFe – Scaled Agile Framework

The Scaled Agile Framework (SAFe) can be defined as a complex framework, which has its particular strength in the embedding of Scrum in classic company areas. This framework becomes complex because it has many roles, processes and practices. The core of SAFe is the stable organizational structure. Overall, the considerations are based on Toyota’s Lean House (Respect, Flow, Kaizen). The framework itself is divided into team, program and portfolio level. The teams organize themselves “almost as usual” according to a slightly modified Scrum on the basis of XP practices with a size of five to nine members, a product owner and a scrum master.

SAFe brings together teams at the program level in the so-called Agile Release Trains (ART). Five to ten teams (approx. 50-125 members) work together in a train and work on the challenges of a so-called program.

The last level is the portfolio level, which provides the programs with budget and targets (epics) based on considerations of corporate strategy and investment intentions. A distinction is made between business epics (customer-oriented) and enabler epics (technical solutions).

SAFe is not suitable for small and medium-sized projects. It entails a large number of specific solutions from the management level and a high level of effort for the introduction. However, it can coordinate a large number of teams and master even very large releases with the release trains without any problems. For a small number of teams, however, I would advise against a heavyweight framework like SAFe. This results in a high expenditure of time for the introduction due to the high level of complexity. The introduction of SAFe is usually worthwhile with a long-term implementation throughout the organization.
In order to implement the SAFe framework, far-reaching measures are necessary. While there are hardly any costs at the team level, committees and special teams must be formed for the release train at the program level. In addition, metrics for measuring the team level and the release train would have to be defined as well as another team for integrating the product. Further committees and the introduction of Kanban teams are necessary at the portfolio level. These are just a few of the steps you need to take. It quickly turns out that massive change management is necessary and that with 12 teams this effort is distributed over an additional release team, a portfolio team, 1 program team and an extra committee as well as 2 change management teams and massive design effort. These teams alone would cost more than 500,000 euros (with a team of experts at 100 euros per hour) without including the necessary effort in the conception. For this reason, the framework for 12 teams has no cost / benefit ratio, as there will be an incalculable amount of change costs. As you can read on many websites, however, the framework is worthwhile for a high number (50-100) of teams. Here it goes to Framework homepage . See this for more information Book of Leffingwell.

Scaling Scrum with LeSS – Large Scale Scrum

The basic idea of Large Scale Scrum is to adhere to sprint cycles and to carry out important Scrum events, such as Sprint Planning One and the Sprint Review, together. Each team has its own restrospective, but there is also a common retrospective for all teams. For horizontal coordination, there are joint product backlog refinements and inter-team coordination (e.g. Scrum of Scrums). The standard framework for up to 8 teams defines only one product owner, who should keep the overview. The Hugh LeSS framework was designed for further scaling. This also includes Area Product Owners who report to the Main Product Owner.

LeSS thus defines a simple procedure, hardly deviating from Scrum, and a scalable structure. The focus on a hierarchy of Chief Product Owner, Area Product Owner and Product Owner at team level also supports more than 8 teams without any problems. The Scrum of Scrums approach is expanded with the hierarchical structure of the Product Owner and thus provides a quick introduction for up to 16 teams, in my experience, relatively problem-free.
The measures for the implementation of hugh LeSS are the establishment of the joint sprint teams as well as a team that supports the integration at the end of the sprint – additional product owners are also necessary for the implementation. Experience has shown that with 12 teams, 4 additional product owners and one product owner with overall responsibility are required. This means that costs of 80,000 euros for the product owner and 128,000 euros for the additional team are necessary. Here is the Homepage of LeSS . See the book by for more information Vodde and Larman.

Scaling Scrum with Nexus, DAD, …

Overall, in addition to the frameworks mentioned, there are other frameworks such as Ken Schwaber’s Nexus and the disciplined agile delivery from IBM. Nexus is basically only to be understood as a guideline or open framework and the framework from IBM only as a collection of best practices. For this reason these are neglected. See this for more information Book from IBM.
[yop_poll id=”20″]

And which one do I take now? How can I scale Scrum?

In the course of researching agility, I looked at these scaling frameworks in detail and was amazed that I rarely see them in use – companies hardly seem to scale Scrum with them. I then evaluated the frameworks together with agile coaches and came to a surprising result: Actually, these frameworks were described by the coaches as pure marketing frameworks. People would be pushed into a framework and the actual freedom that Scrum had to offer was no longer given. For this reason, according to the coaches, the introduction of such frameworks was often canceled halfway and new solutions and approaches were sought. Also Boris Gloger got me into a dialogue said the following:

In my work, I have repeatedly made the experience that large-scale projects managed according to agile principles lead to significantly better results. However, there is more to Scrum than just a few principles. It has thus been found that agile frameworks such as SAFe®, LeSS and Co. are very complicated. However, Scrum should be simple and take just a few steps (Boris Gloger).

[werbung]

[fotolia]

Der Beitrag How can you actually scale Scrum? erschien zuerst auf agile Companies.

Study on the topic of agile purchasing

On the subject of agile purchasing, a team from Koblenz worked with Prof. Dr. Ayelt Komus conducted an online survey in September and October 2016. According to information, 160 people took part. For the study, questionnaires were sent online to companies and the answers were then sent by the team led by Prof. Dr. Komus evaluated.

Results of the study on the subject of agile purchasing

Overall, Prof. Dr. Komus found in his study that agile methods could fundamentally change purchasing and that many companies are not yet optimally set up for agility in purchasing. The study provides arguments that agile methods in purchasing are still largely unknown or that careful approach is taking place. Overall, the authors summarize the results of the study as follows:

• Almost three quarters of those surveyed expect fundamental changes for purchasing when using agile methods.
• More than 85% of those surveyed do not see themselves as being well positioned as buyers with regard to agile methods.
• “Acceptance of the changes among employees in purchasing” is perceived by the participants as the greatest challenge in the further development of purchasing.
• Participants expect the most far-reaching changes in the “coordination with the specialist department”.
• Participants expect the most far-reaching effects in areas related to software or product development.
• For more than 60% of those surveyed, the changes and challenges of Industry 4.0 and agile methods are the same.
• Only 6% of those surveyed are currently actively and constructively dealing with the changes brought about by agile methods.

Recommendations and conclusion

At the end, Prof. Dr. Komus made some recommendations based on the study. Purchasing should be taught the basics of agility and agility should also be better defined in the context of purchasing. So it is currently unclear what agility actually means in purchasing.
The study is certainly a great stimulus for purchasing managers to be more agile in a complex world and to improve purchasing management. Basically, however, agile methods can certainly help in purchasing and should be considered. So now it’s up to you to think about how you could make yours more agile.
[werbung]

[fotolia]

Der Beitrag Agile purchasing erschien zuerst auf agile Companies.

The 4 zones of Dynaxity

The picture shows the 4 zones of Dynaxity. Zone 1 (static) describes simple, fixed rules and the same structures. So one could speak of a small business that has been secured for generations.
Zone 2 (dynamic) describes the classic company according to some literature. Growth and changes in customer requirements are the order of the day here. There are uniform processes and structures as well as a basic controllability of the company. It is noticeable that in some publications the customer is mentioned as a “disruptive factor” in this phase, as these organizations often work in a rather static manner. However, this is not exactly proven.
Zone 3 (turbulent) arises with increasing dynaxity. Uniform processes and rigid structures are no longer effective here and employees are required to help shape it. This zone is described as a living system that should be dominated by self-organization. In addition, “feedback effects” are found in some publications. That is, solving one problem leads to several new problems.
Zone 4 (chaotic) is basically no longer controllable. Civil wars or natural disasters are cited as examples. So there is a high level of complexity and dynamism here.

Dynaxity and agility

The following figure shows again the 4 zones and tools as well as processes that dominate each zone. It is clear that Zone 1 has a typical hierarchy and Zone 2 actually scales this with contracts and plans. Zone 3 forgets all of these methods and uses the principles of agility. According to the authors who used it in 1980, Zone 3 was derived from the Agile Manifesto. So the term goes hand in hand with agility.
Overall, the term fits very well, even if the word itself is not exactly easy to pronounce. It also summarizes the two triggers of my research, namely dynamics and complexity. Overall, I find it an exciting term and I will certainly pick it up one time or the other.

[werbung]

[fotolia]

Der Beitrag Dynaxity: dynamic and complex erschien zuerst auf agile Companies.

We want to revolutionize management in order to build extraordinary companies of the future with self-reliant employees and executives who can adapt extremely quickly in times of (digital) change (Andre Häusling – HR Pioneers )

Paradigm shift in HR

Currently leading HR experts define a change in personnel management from hierarchy and silo thinking to network and interdisciplinarity. Profit maximization to benefit maximization, external control and top-down decisions on personal responsibility and human expertise. HR is also required to convert incentive systems to recognition systems and to act as a companion or coach for employees.
So in the course of the 1. Roundtables on agility confirms the topic of agile personnel management as an important factor for agile companies. “People are the most important capital of a company”, is the consensus of the participants and in a war for talents the participants demand new methods and approaches to recruiting and employee development. The solution is obvious to the participants: Personnel management has to be agile!

Agile human resource management

If you look in a lexicon for personnel management, you will find the definition as the “sum of personnel design measures to achieve corporate goals. The term is often used synonymously with human resources or human resource management.” ( Gabler Business Lexicon ). Agile means “agile, active, lively” (for more, see my article on Definition of agility ). In summary, one could say that agile personnel management stands for flexible and agile measures for the personal implementation of company goals. In the roundtable on agility, I evaluated with the participants which areas were agile HR or should cover agile personnel management.

Agile employees

One requirement of the participants in the round table is the “agile employee”. This should not follow a fixed position or a pre-defined career plan, but rather take on a role. According to the participants, companies should prefer to hire “agile employees” and keep them for the long term.

Agile employees have an agile mindset and human maturity. Agile employees want to work with the company and develop together with them.

Employee satisfaction

One of the highest corporate goals in times of the war for talent should be employee satisfaction and low fluctuation. How can agile personnel management contribute to this? In addition that has Consulting house PwC found out in a study that employees always have individual needs, but these needs can generally be classified into 5 categories:

• Type 1: Finds satisfaction in his work and tasks.
• Type 2: attaches importance to personal development and career opportunities.
• Type 3: Derives his satisfaction from how he is treated by his manager.
• Type 4: The key to his satisfaction lies in the relationship with his colleagues.
• Type 5: This employee wants to be proud of his company.

Take the time to do a quick survey!

[yop_poll id=”4″]

Agile qualification

Now companies have hired agile employees and everything is great! No, because the question arises: “What can such an agile employee do?”. What qualifications does this agile employee have? According to the participants, the answer is obvious: “agile qualifications”. But what exactly are such qualifications? In the sense of qualifications, agile stands for “moving” qualifications and skills. That means an employee is ready to familiarize himself with new and unknown subject areas and an agile personnel management supports an employee as a coach or companion at eye level.

An applicant should not be able to know what the company needs today, but should be ready to learn what the company will need tomorrow.

Agile recruiting

After it has already been clarified what agile employees are and what they should be able to do, the question arises how agile recruiting is structured, i.e. how I actually get to these agile employees. Specifically, that means: According to which criteria should an employee be hired? So should the focus here be on assessment centers and competence tests? According to the participants, this no longer plays a role in the War for Talents but:

The central task of agile HR is to ask the question: How can we work together? “

Example of agile human resource management

In the course of the 2nd round table on agility, there is an example of agile HR through the integration of Scrum elements. The aim was to develop a “cross-functional HR-IT business” team, which consists of experts from the entire company. The credo was that the HR customer, for example a developer, should sit on the committee and contribute ideas. The vision was: “One HR measure per week”. Every Tuesday in the weekly meeting HR measures were decided, prioritized and implemented within a week. Everyone in the company could visit this body and get involved. This means that the right people are always on the committee and everyone is voluntarily present.

Conclusion: more than Scrum!

Personnel management is in a state of upheaval and is influenced by many trends. It can be clearly shown that a paradigm shift in HR is imminent. There are currently some approaches to this change that are being tested by companies. What is certain, however, is that agile personnel management is not just “just Scrum” but involves a fundamental change in the way of thinking. What exactly agile personnel management looks like cannot yet be fully clarified, but first approaches were defined with the help of the roundtables, which can be further evaluated by the research project.
[werbung]

[fotolia]

Der Beitrag Agile HR management – more than just Scrum? erschien zuerst auf agile Companies.