The management pendulum

I believe it acts like a pendulum. Companies often react less proactively but rather reactively due to certain key figures such as layoffs or a drop in sales.

At this point, companies are on one side of the extreme, e.g. many processes and hierarchies. Now the company is moving to the next extreme due to the decision of the management and realizing that there is now too much chaos in the organization. So we’re reintroducing a couple of processes.

In the second step, the pendulum does not swing that far, but it swings in the other direction again. It loses momentum. This process lasts until the pendulum has caught itself in the middle.

I find this metaphor quite appropriate to see how managers try exploratory changes in the organization and try to find the right balance. I believe that this pendulum helps to better understand change and to support management in this direction.

Examples

You can also transfer this pendulum to many other developments. For example, Generation X was more shaped by hierarchy and wage labor. With Generation Y came the other extreme: flat hierarchy and work with meaning and trust. Now a generation Z could switch back to the other side of the pendulum.

It is similar with agility: Managers have broken down processes and hierarchy and notice that it is sometimes a bit chaotic. So one began to introduce processes and hierarchy again. A typical pendulum process.

You can use the pendulum as you like for all trends in your company to remind yourself: Why is this happening and what’s next?

[werbung] [fotolia]

Der Beitrag Trends and agility in organizations – from one extreme to the next? 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.

What are Objective Key Results (OKRS)

The method was invented by Andy Grove and John Doerr and first mentioned on Google in 1999. You can currently find the method at Oracle or Twitter, for example. The T3N describes this as follows: Measurable key results are assigned to each objective (objective). The successes are measured at regular intervals and new OKRs are defined.
The OKRS are not determined at the company level, but are negotiated with each team. A manager then has the task of synchronizing these together with all employees and adapting them to the company’s goals. The idea behind the goals is that they cannot be fully achieved and are therefore an incentive. According to Murakamy are the main advantages and goals of OKRS:

• clarity about the most important tasks to generate in the company
• The right focus for the next three months
• About proper use scarce resources to decide
• transparency creating for employees to work on the right things
• A better communication to introduce
• Implement indicators to measure success
• To connect vision, mission and strategy to short-term, operational planning

An example of Objective Key Results (OKRS)

In the following I would like to give an example of OKRS so that the explanation can be better understood and you get an idea of how these can be used in everyday life.
Imagine a consulting company that currently has a turnover of 20 million euros. The management’s goal is now to be on a par with large consulting firms such as Accenture (34.9 billion euros) and Capgemini (12.5 billion euros). Now you define certain key results which you can measure. These could be:

• Winning every 2nd tender in the public sector
• Advising 8 of the 30 DAX companies
• 100 new consultants hired this year

After a one-on-one interview with your HR department, you could now set the following goals:
target :

• Improve the number of applications

Key results

• Increase investment in social media by 30%
• More flexible contracts for all new applicants
• Establish home office as the standard in the company

You would now have to set similar goals with your salespeople as well as your consultants and synchronize them all together. This results in specific goals, which are adapted to the corporate goals and are clear, measurable milestones. These are transparent for all teams and can / should encourage.

Conclusion

The method is of course not completely new, but now everyone is talking about it. So you set goals that are hardly achievable and measure the achievement of goals using specific figures. It is important for you as a manager to synchronize these. Important: There are no sanctions for failing to meet the targets. The advantage is that you create team goals that are transparent for the entire organization. Surely this is worth a try. What is your experience with it? Feel free to write it in the comments!
[werbung]
Verwendete Quellen anzeigen

[fotolia]

Der Beitrag OKRS: the agile management method erschien zuerst auf agile Companies.

• What are my very personal experiences in my life as a rebel?
• What best practices can I share – and what have been my biggest mistakes that others can learn from?

In the first step I would like to tell my very personal story about a change in which I was involved for a whole year. From this story I derive best practices that can help an organizational rebel in everyday life. The following story happened during the last 3 years in the course of my consulting activity. I don’t want to give any time periods because the company is supposed to remain anonymous. In the following, some details have been changed so that the company cannot be traced. Hired as a consultant, I found myself there in an environment of tradition and change.
Reading tip: SMEs between tradition and change

My very personal experiences

One day I received an exciting project. I was supposed to support a company for a year, to restructure a department and, in addition to consulting, also tackle the change with management and employees.

From one day to the next to a rebel

Change is difficult – hardly anyone likes it. Especially not in a group with fixed structures. But changes are essential to move a company forward. So I was called by a company to restructure a department with almost 100 employees. In 50 percent of my time, I helped the managers responsible to change the organization – the other 50 percent I took on important projects using agile methods. So I had come to change something – an organizational rebel – which perhaps not all employees received with open arms at first.

Planning, planning, planning and shut up

A very well-known agile mind and book author once gave me the tip a few years ago: “If you come in somewhere new, shut up and take a close look at everything.“That’s exactly what I did. In the first few weeks I was busy getting used to it, understanding processes and getting the seniors to explain the company to me. Together with the manager and his team leaders, we met regularly for one-day workshops on planning the new department. Especially at the beginning I listened carefully. I didn’t bring my own ideas to the table, but rather thought about how I can put the manager’s visions into concrete terms. Before I came up with an idea, I usually discussed it personally with one of the team leaders. By the way, if you want to read some theory, you can click on my article on organizational development.
Reading tip: Organizational development

The target image was created!

After a while, we had defined the target image for the department. We had to observe the following framework conditions:

• Compliant with the certified standard
• Compliant with processes in other departments
• Lots of people who don’t all want to work in an agile manner
• Different customers, not all of whom were enthusiastic about agility either
• highest flexibility with maximum stability

There were currently very large teams in the company that worked according to traditional methods. This should be changed. We had the idea to appoint two new team leaders and to form four teams from two teams. These are:

• Internal IT: automation and operation – Kanban
• Project team – large customer projects – complete self-organization and autonomy
• DevOPs: For medium-sized projects and agile (Scrum) customers – Scrum and DevOps
• Classic unit: small customers and customers with standard tasks – ITIL

Challenge accepted! To do this, we came up with a four-step model. Some of the employees were supposed to continue to work in the old organization, the other part slowly moved with the customers. It was important to us that the stability of the department was maintained. I created a graphic for this – I will go into the individual phases in more detail later. To explain: DevOps is an artificial word that is made up of the words Development and Operations.

With full force against the wall

After a few weeks I got into my first project, which I was supposed to do in 50 percent of my time. I was a project manager for a large client. There was a program manager above me and two sub-project managers below me. So I did what I had learned in the target picture and organized this project as agile as I could.
One aspect of this agility was to give the sub-project managers a high degree of freedom and autonomy in their task execution and to keep their backs free as Scrum Masters. I also saw myself more like a lawyer in front of the client and the program management. Unfortunately, it only occurred to me too late that my project was completely out of line with the ITIL-oriented line of the program and, despite its success, was perceived by the program manager as uncontrollable and chaotic. ITIL is a way of organizing IT and is often not easy to combine with agile methods.
Better: Unfortunately, it wasn’t until much too late that I realized that two worlds were colliding. Agility paired with an ITIL-oriented line of the program let my project step out of line. Despite the success, the program manager perceived the change as uncontrollable and chaotic.
In order to protect his project, after three months I was suddenly allowed to put on my hat and “go” – the unit was again organized in the classic way. So I did it! I was kicked out of my first project after three months. Fortunately, the manager of my department was behind me and decided to just give me a new project. There was just me as a project manager and a team. The predecessor should train me. By the way, if you want to read more about the establishment of Scrum in traditional companies, then I have a free whitepaper for you here!
Reading tip: Agile in the Waterfallworld

Networking can help – the Change Board

However, two months passed between the old and the new project and I was able to devote myself to the change. After I got home quite early on the day of the exclusion, I was in the office all the earlier the next day. I used the next time to have a short one-on-one conversation of 15 minutes with 40 of the 60 employees and made notes. I formed clusters and had roughly summarized the wishes and suggestions of the department at a glance for the manager.  Now we formed the change board, which consisted of the following types of employees:

• Strong skeptic against change
• Knows a lot of people
• Is very committed and has lots of ideas
• Team leader of other departments

At the first attempt, we presented a plan to the change board and the new teams. Together with the board, we filled a backlog with tasks. A sprint took place every two weeks and every employee was allowed to take tasks from the change board. Each of the ten participants helped. Team leaders from related departments were invited to provide feedback. After four sprints, we had completed all preparations and could start the change. Each phase was represented by exactly four sprints of two months each.

With a new approach and classic methods

Now I started my new project, which I was supposed to carry out alongside the change. It was another big customer with an innovative technology stack. This time I adopted the same method as the previous one and continued the project in exactly the same way for the time being. I wanted to achieve exactly the status quo. I apparently managed to do this and slowly gained the trust of the team – including that of management. So I devoted 50 percent to change and 50 percent to classic project management.

Persevere and do marketing

Now it was time to persevere and continue the sprints of change. Every week there was a status meeting and every two weeks there was a review and retrospective. Participation in the Change Board was voluntary and I saw my job in motivating people to keep going. We worked our way forward sprint by sprint.
In the course of my project, in addition to the change, I moved more and more from the classic project system to Jira and we carried out the first small sprints. I now had more trust in the company and was slowly able to make the project a little more agile.

Every change also has an end

Every change has to be completed at some point. The first phases were mostly a technical changeover as well as the move to the new offices and the relocation of the employees. Later on, coaching and finding your way around in the new roles came in particular. It was also possible to volunteer for a team. However, the last 25 percent of employees had to be persuaded to switch to the new organization. I accompanied each and every one of them individually and tried to help.

It goes on: After agile comes virtual

Now the change is over and I have to say: It was fun and we all think we did a good job. The change is also officially completed and other departments may follow. I didn’t pack my things afterwards, as might have been expected, but instead took on another mission for the manager: the company set up two new locations.  I was supposed to coach the company’s first virtual team, which is spread over three locations. But this should be a topic for a new article.

Conclusion: best practices for the organizational rebel

The change was a lot of fun and I was looking forward to the next task. Now I derive my do’s and don’ts for organizational rebels from my experiences. First and foremost, a change agent should see himself as an advocate of change, i.e. defend it again and again, instead of preaching like a priest.  Networking is also important in order to attract the opinion leaders in the company. Furthermore, work should be done on the status quo, because a classically run company will not become Google or Spotify overnight.
It is also important, especially at the beginning, to first listen and gain the trust of the employees. As a rebel, you shouldn’t realize your own ideas, but see what the company management really wants to achieve. Of course, it doesn’t always have to be 100 percent agile. ITIL organizations can also be agile and are very important for certain customer projects. Always remember that you are between tradition and change. Much that rebels want to change may even have guaranteed the success of the last few years.
Let’s get to the Dont’s. It is important not to polarize, but rather to stay in the background. You should also not pursue your own goals, such as wanting to make everything agile. Of course, I wanted to try out the LeSS framework, but that just didn’t make sense for our customers. Incidentally, the LeSS Framework is a method of scaling Scrum. If you want to read more about agile scaling, go to the article here.  A change is also not a matter of a few days and takes time. We invested a year in the change. It is also important to pick up all employees and take them with you, otherwise you will lose the opinion leaders of the company and you, like me, will be thrown out of a project. A great saying that I have used again and again in Change is:  Grass doesn’t grow if you pull on it. People need time to slowly adapt to the new situation – because the job means securing livelihoods for everyone. I have summarized my findings in the following figure:

[werbung]
Verwendete Quellen anzeigen

[fotolia]

Der Beitrag Between tradition and change – the story of an organizational rebel erschien zuerst auf agile Companies.

Characteristics of SMEs

The entire German corporate landscape is predominantly dominated by small and medium-sized companies (99.3% of all companies are SMEs in Germany), which are an important pillar of the German economy due to their innovative ability and experience. According to the definition of the EU (IfM Bonn 2018), SMEs are divided into three categories:

• Small business (up to 9 employees and 2 million euros in sales)
• Small companies (up to 49 employees and 10 million euros in sales)
• Medium-sized companies (up to 249 or 499 employees and 50 million sales)

There are two definitions. My experience has shown that many companies up to 499 employees still count themselves as SMEs. Overall, the term SME and medium-sized enterprise is initially the same. Furthermore, most of the small businesses are more traditional businesses with a focus on handicrafts such as carpenters etc. are. Small and medium-sized companies are also predominantly manufacturing companies and are thinking about the vision of Industry 4.0. A small number are software houses and consulting companies that offer knowledge-intensive services. This distribution can be deceptive. Most of the companies are very small, but the picture is very different when it comes to the employment rate.

Special features of SMEs and large companies

But what exactly is the difference between SMEs and large companies? On the one hand, I like to distinguish these from the fact that they have a low budget as a large company and often pursue long-term planning and sustainable strategies. Furthermore, these are often represented in a niche and have a high level of expertise, which is based on long-term employees. These are usually more flexible due to shorter decision-making paths and find themselves in a field of tension between tradition and change. Has another distinction Dr. Winfried Felser made in an article. So he contrasts large companies and SMEs. I have taken over parts of his table and will explain them briefly.
Limitation: Some points in the table sound a bit harsh or could be interpreted negatively. However, that is not the case. For example: “away from the customer”. In large companies there are many internal issues that are necessary from a certain point on. Longer coordination with many stakeholders and employees is also simply necessary. In any case, I would like to limit the fact that this is not to be interpreted negatively.

This shows that large companies often have more budget and that change support is often provided by a special focus team. In SMEs, on the other hand, money is often tight and the employees have to manage the change work alongside day-to-day business. Large companies also have the opportunity to purchase consulting services that are of little use in SMEs due to the low budget. In SMEs, there is often a much higher orientation towards day-to-day business, as this brings in sales and profit.  This also means that there are few internal topics. (Example: Large companies have a data protection department – SMEs often only have data protection officers who carry out this activity in addition to day-to-day business).
Also in SMEs, all employees are close to the customer (day-to-day business) and often even on-site with the customer. Due to the often short line to the managing director (especially in owner-managed companies), decisions are often made and implemented quickly. The focus is often on a sustainable strategy and maintaining sales. In large companies, on the other hand, there is more of a strategy depending on the current board of directors, which has to coordinate with many committees.

Digitization and agility in SMEs

In my doctorate, I checked SMEs for the difference in agility and digitization. There are numerous case studies on digitization, such as by  by Arbussa et al. (2017) as well as studies on the potential of digital change such as  Data analysis tools (O’Connor and Kelly 2017). As already stated by Lindner and Leyh (2018), it is  on the lower budget and the fact that SMEs are often less digitized than large companies. Therefore, according to the two authors, there is often a centralized and rather inflexible IT in SMEs, which, however, is often built up gradually and slowly due to the lower budget (Essers and Vaneker 2016).
There are also numerous articles on the subject of agility. Lindner and Leyh (2018) state the following: It is clear that SMEs are often seen as more agile and flexible due to their small size and often shorter decision-making paths (Arbussa et al. 2017). However, one thing applies to SMEs: rapid growth, which  can reduce this flexibility and agility. This is how agility is examined in the context of growth. Authors like  Branicki et al. (2017) speak of maintaining the so-called “entrepreneurial spirit” or authors such as Ng and Kee speak of post-agility in grown SMEs.
[yop_poll id=”38″]

Conclusion

There are numerous SMEs in Germany and they dominate the German corporate landscape. They are characterized by low budgets, short decision-making paths and a just do it mentality. They are also often players in a niche and have a long-term thinking and sustainable strategy that is based on long-term employees. SMEs are fundamentally more agile than large companies and, from the point of view of digitization, more retrograde, which is often due to the low budget.
I find the study of SMEs very exciting and I believe that SMEs in particular will become even more important. Since I have been working in SMEs myself since the beginning of my career (3 years), I can also say from my own experience that it is really worth recommending to look at SMEs in addition to large companies.
[werbung]
Verwendete Quellen anzeigen

[fotolia]

Der Beitrag Special features and characteristics of SMEs in contrast to large companies 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.

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.

Since the introduction of agility, we have been trying to scale it. The first step towards agile scaling was taken with Scrum of Scrums. Subsequently, a large number of agile evangelists began to think about solutions for a company-wide scaling of Scrum and wrote very exciting books and approaches from 2010 to 2016.

LESS, DAD, SAFe? Is it all just marketing?

It all started with the SAFe Framework by Leffingwell (2010). The magazines reported about this framework as being very bureaucratic and inflexible. Leffingwell has greatly improved this framework to date and releases new versions every year. More information is available in his new book . IBM then wanted to scale agility and, with Ambler and Lines in 2012, created Disciplined Agile Delivery, a collection of many best practices that were introduced in 2012 have been published as a book . In 2015 Ken Schwaber (Nexus) and soon Larman and Vodde (2016) followed suit with the LeSS framework. There are first lectures by the two and a book that will appear from September 2016.

Evaluation of the frameworks through interviews

In the course of Research on agility I’ve studied these scaling frameworks in depth and wondered why I rarely see them in use. 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.

Does agile scaling even exist?

Scrum is a bit like Lego. It can be combined with any other method. So it is in the big as well as in the small, z. B. A backlog should always be understood in the same way. The only difference is that if there are several teams there is a backlog that carries larger user stories, so-called epics, with it. Or let’s take a project backlog that lists all projects and prioritizes them. So I always start with the most important projects. So I don’t actually scale Scrum, I use the values and methods of agility so that they create value in the right place at the right time.

Holocracy, the Scrum principle, agile leadership and resilience

After evaluating the interviews, I have now summarized all the frameworks I found and sorted them by relevance. A detailed overview of the exact contents and authors can be found in the article Frameworks for agility . I would now like to go into what constitutes this.
The frameworks mentioned in the heading do not restrict the organization as strictly as current scaling frameworks, because their focus is on the organization and the people within it. No framework prescribes exactly what is to be done, but each aims at a flexibility and self-organization of the individual participants. Roles instead of positions should be formed and, if necessary, the actual organization should be overridden at any time in order to react faster and better to changes.
[werbung]
Verwendete Quellen anzeigen

Der Beitrag Agile scaling in companies 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.

[werbung]
Verwendete Quellen anzeigen

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