Veröffentlicht am

How Culture Influences Your Agile Change Effort

culture and agile teamwork

“Culture eats strategy for breakfast”

Although Peter Drucker never said this, many people still are convinced that culture does at least influence change and decision making within a company. How strongly is highly debated. As the effort we put into agility is all about facilitating change to improve outcomes for a company, it is important to deal with culture to be able to influence an organization.

If you look at the totality of all companies, you can observe many individual cultural phenomena. Since corporate culture was made the subject of research in the early 1970s, attempts have been made to systematically survey and categorize the factors that make up corporate culture.

The Competing Values Framework as a Model to Evaluate Culture

The “Competing Values Framework”1 formalized by Cameron and Quinn is one model that can help us to assess the culture that is dominant in our company. It can help us to understand, why applying Agile principles might be hard in our context and can so help us to derive measures to increase the chance to implement an Agile approach.

Let us consider the following image representing the frameworks basic components:

One thing I like about the framework is, that it does not put a company in only one bucket (quadrant). Instead it admits that every company will embody the culture mentioned in all four quadrants to a certain degree, although it might lean towards one or two quadrants more specifically.

I am discussing this framework and the impact of culture in greater depth in my upcoming book “Disillusioned by Agile? From Pain to Progress: Diagnose and Alleviate Agile Dysfunction – A Handbook For Practitioners*.

Let us briefly discuss how each culture type influences the implementation of Agile practices. This should help us practitioners to adapt our approach, as we try to introduce Agile ways into our context.

Hierarchical Culture

It is historically the oldest of the promoted corporate cultures. With the dawn of the industrial age (around 1900), German sociologist Max Weber observed companies and businesses in Europe and in 1947 recorded the attributes that what was then considered to be the ideal industrial company should have in order to operate as efficiently as possible. He proposed seven characteristics to which every company should aspire:

  • Rules
  • Specialization
  • Meritocracy
  • Hierarchy
  • Separated authority
  • Impersonal relationships
  • Accountability

This culture proved to be extremely successful in producing products of predictable quality in large quantities efficiently, reliably, and quickly. A high degree of uniformity and standardization in processes and procedures was intended to ensure that large numbers of workers could always produce the same goods according to clearly defined rules.

Characteristics of Hierarchical Culture

The hierarchical culture is characterized – as the name suggests – by a hierarchical structure. Responsibility increases with height in position within the corporate pyramid. Rules, guidelines and control are set from the top down. The goal of most employees is to work their way up within the hierarchy through merit.

The following values are important within this culture:

  • Efficiency
  • Obedience
  • Accuracy (in the execution of processes)
  • Consistency
  • Uniformity
  • Reliability
  • Precision (in doing the work)

Relationship to Agility

Agility is in clear contrast to the hierarchy culture, because it is not efficiency that agile teams propagate, but effectiveness in dealing with complex problems that are different and challenging from project to project and from iteration to iteration.

There are definitely values that both cultures have in common, but on different levels. Accuracy and uniformity are emphasized within agile teams, but at the micro level (e.g., in program code), not in following ordered development processes. Thus, great emphasis is also placed on a common language when formulating requirements (e.g., in user stories) and on the consistency of associated acceptance tests. However, agile approaches encourage creative problem solving and do not dictate what practices teams must live by. If a team finds a better way to meet the requirements, it is allowed to change the way it works in the interest of achieving the goals. Yes, it is usually given the opportunity to actively share its experience with other teams.

What about Efficiency?

Efficiency is found at the micro level in agile teams: for example, as far as possible, all simple, recurring processes that are not of a creative nature (or that could also be performed by a machine) are automated. Also, options are always examined as to what could still be automated in the future or where more human interaction is needed and rather less automation is required (e.g. when verifying releases together with the customer).

Hierarchical culture often hinders collaboration in teams that want to become agile, e.g., when decision paths are unnecessarily long or rules are defined that are valid throughout the organization, but which stand in the way of a results-oriented approach. Such conditions lead to teams that nevertheless try to proceed according to agile principles appearing to the outside world (the rest of the organization) as a normal business unit.

Covering Up Is Overhead

To be able to maintain such an image these teams they deliver all the required project documents at the interface with other teams, without deriving any internal benefit from this. This adds overhead for them that doesn’t always provide demonstrable benefit to the project and usually slows down the team’s productivity.

This also means that agile teams in such a culture may often act contrary to existing conventions. They may therefore also run into problems as they are seen as non-conformists. An example of this is when they try to keep the customer heavily involved throughout the duration of the project and even encourage them to question or even revise the requirements agreed six months ago.

Dangers for Agility

If the hierarchical culture is so strong that it acts like a corset that confines each team as a result of strict control mechanisms, this may lead to any advances to adopt an agile approach getting stuck in the early stages.

If the documentation to be produced is too voluminous and the team is primarily occupied with editing concepts and endless meetings just to satisfy some process template, then it will struggle to deliver production-ready software frequently, which contradicts one of the fundamental principles of the Agile Manifesto.

Long delays waiting for decisions to be made by someone higher up in the hierarchy, such as the architect, place a burden on the Agile team. Delays can also occur when, on the customer’s side, a question about a particular requirement is first passed up the hierarchy and only after many detours finds its way to the correct person, who is able to answer the question competently. On the part of the agile team, this leads to partially completed work that must be additionally monitored and represents a debt that can weigh heavily in the later course of the project. Many loose threads are only hesitantly woven into a tapestry that could provide an accurate picture of the current state of development. This makes it very difficult to determine where things stand within a project.

We can say that a hierarchy culture influences mostly negatively your Agile change effort.

Market Culture

With increasing competition (including international competition) in the 1960s, there was a call for a more dynamic alternative to the hierarchical structure of companies. It became increasingly important to maintain business relationships. Goods were exchanged across national borders. Competition – even for national companies – was increasing. Customers were no longer satisfied with a simple basic product, but were increasingly demanding.

Companies suddenly had to be much more outward-looking, and customer orientation became the mantra of the business world. This also had an impact on the companies themselves.

Profitability, results, and ever-higher productivity targets are of paramount importance here. A clear common goal and an aggressive strategy serve as drivers for effective work.

Characteristics of Market Culture

A market culture is results-oriented. Projects are judged on their marketing potential and unsuccessful projects are terminated abruptly before the damage becomes too great. There is also usually strong competition within the company when different business units are compared with each other.

This is usually done using typical key market figures, sales figures, profitability calculations and profit opportunities. This climate reveals that in this culture, the following characteristics are promoted above all:

  • Determination
  • Toughness
  • Demanding climate
  • Competition
  • Profit orientation
  • Polarization (“We are the good guys, the outside world (competition) is the enemy.”)
  • Cleverness
  • Customer orientation

Relationship to Agility

Agile is often welcomed in a market-oriented culture. This is because it promises to deliver in an uncomplicated way the features that the market, i.e. the customer, is most likely to need. Even short-term changes in the priority of requirements do not pose any problems for agile teams. Short iteration cycles enable them to quickly adapt the focus to the customer’s current needs.

Constant optimization of the approach is also generally welcomed as long as it meets the goals of the market-oriented organization. I.e., as long as it increases profitability, reduces costs, or even makes it possible to bring innovations to market faster and thus represents a competitive advantage.

Certain aspects of the agile approach, on the other hand, meet with less favor in this type of organization. For example, in some market-oriented companies (especially in the fast-paced Internet environment), iteration cycles are still too long. Rapid response to market opportunities as they arise and short-term profit-seeking cause some companies to constantly shift priorities so that they are sometimes not even constant for the duration of an iteration.

Dangers for Agility

Employees may be burdened with additional tasks (e.g., supporting marketing activities) that are topical at that moment and may no longer be able to focus exclusively on the goals agreed upon at the beginning of the iteration. This may result in delaying the delivery of features that have been tested and are ready for production.

Another danger is that the focus on achieving market goals and wins in the short term can lead to undermining the agile movement’s emphasis on integrated quality. The agile team might be accused of focusing too much on it and not delivering a sufficient number of marketable features.

When Heroes Become Competitors

The emphasis on and “hero-ization” of “doers” can also lead to unhealthy competition within the team. Teams tend not to work closely together. Instead they consist of a bunch of lone wolves who are primarily concerned with individual advancement and their own careers. This instead of a common goal that everyone contributes to achieving or – in the case of failure – everyone is held accountable for.

If the competition between several teams is fueled, this can lead them to spur each other on to top performance – freely following the credo of the free market economy. But it can also easily lead for the company as a whole to have teams start working against each other in order to be favored in management’s favor. This can undermine the principle of close collaboration.

A market culture influences your Agile change effort in significantly, as it has a strong customer focus and prefers short cycles.

Clan Culture

In the late 1960s and 1970s, researchers increasingly looked at Japanese companies and found that, unlike American and European companies, a very different spirit prevailed there. They observed a clan-like structure, almost as if the companies were family businesses.

Companies with a clan culture are characterized by an atmosphere of shared values and goals. Individuals are encouraged and organizational cohesion is one of the most important features.

Unsurprisingly, a clan culture views its customers as partners. It makes every effort to provide its own employees with a work environment in which they can collaborate productively and in which they can actively participate. Loyalty to the company is strongly encouraged.

Characteristics of Clan Culture

The typical characteristics of a clan culture can be summarized as follows:

  • Friendly
  • Supportive
  • Cooperative
  • Loyal
  • Participatory
  • Harmonious
  • Human

The role of a manager in a company with this culture is that of a mentor. He or she is concerned with creating the most ideal working environment possible for employees to collaborate productively. He leads not by rules or regulations, but by instilling shared values and goals.

In a clan culture, collaboration, sharing, and caring are not empty words; they are evident in the close bonds that connect employees – sometimes even personally.

As such Clan culture tends to look inward and wants to closely integrate outsiders into its own structures. As such it is quite supportive of an Agile change effort. It influences the choice of strong teams that are cooperating frequently.

Relationship to Agility

Clan culture exhibits many attributes and usually promotes values similar to those favored and promoted by agile teams. The emphasis on a partnership-based relationship within the team and the organization, which sometimes even extends to the customer, leads to close collaboration where everyone pulls together.

It’s no surprise, then, that advocates of agile approaches borrow heavily from Japanese management and philosophy. Just think of the pronounced affinity to the principles of the “Toyota Production System”.

Just as many operations in 1970s industry looked east and admired Japan’s technological boom, many proponents of the agile movement have taken ideas from Far Eastern approaches and applied them to the discipline of software development.

This resulted in techniques and practices such as “Value Stream Mapping”2, “Kanban”3, “Just-in-Time Production”4, “Built-in Quality”5, and “Sashimi”6 that found their way into software development – in modified form, of course.

Promoting individual competence instead of imposing rigid rules, participating in decisions instead of a top-down commanded approach, are all qualities of the Clan culture that also accommodate the agile approach.

Dangers for Agility

The Clan culture is closest to the agile way of working together and agile approaches thrive in such an environment. Nevertheless, the strong need for harmony can sometimes get in the way of the agile team. Agile teams thrive on the fact that problems and obstacles in the course of a project are first made visible, “brought to light”, so that they can subsequently be cleared out of the way.

Now, if the problems are personal, then it can happen that in the interest of harmony, problems might be swept under the rug and therefore continue to get in the way. This means that the need for harmony and loyalty must have a counterpart in openness and goal orientation so that it does not become a danger.

Ad-hoc Culture

In connection with the increasing fast pace and globalization of markets and the ever shorter product life cycles (let’s just think of the Internet era), a new type of culture has emerged in recent years. Let us call this type the ad-hoc culture. In this type of culture, contacts in companies are very dynamic and limited in time. The aim is to launch an innovative product on the market within the shortest possible time. This to open up new markets quickly, and to achieve and, if possible, maintain a position at the top of the industry through constant further development.

Consequently individuality and innovation are emphasized in this culture. Responsibility is distributed across all employees and not centrally coordinated. Creative chaos prevails. Ideas are generated and discarded. Everyone shares almost all roles: from conception to development to marketing of a product.

Characteristics of Ad-hoc Culture

What characteristics are upheld in an ad-hoc culture? It is driven by the market as much as the market culture. But the focus is primarily on creating new markets, occupy market niches, and possibly move on just as quickly to “greener pastures.”

The characteristics that make up this type of culture are:

  • Innovative
  • Fast
  • Temporary
  • Short-lived
  • Creative
  • Inventive
  • Dynamic
  • Flexible
  • Adaptable
  • Organized Anarchy

Employees in such a culture take risks and dare to do new things. They push ideas forward and try to inspire like-minded people to do the same. Any way to achieve the goal is fine, as long as it generates a new, innovative product.

Teams merge as quickly as they disband. Since each employee is considered an entrepreneur, there is an expectation of great autonomy and self-reliance for the individual.

Relationship to Agility

The ad-hoc culture emphasizes agility and sometimes even assumes it in its employees and teams. It sometimes even strains agility to the extent that it threatens to slide into chaos. Creative solutions to problems are allowed to come from all corners of the company. There are very few rules. The agile approach principle of doing what works and leaving what gets in the way is encouraged.

Employees in a company that emulates an ad-hoc culture are often generalists. They are capable of stepping into many roles, depending on the shortcoming at the time. Even when employees are highly specialized, they are willing to work closely with specialists in another field to dream up new, creative and sometimes even surprising solutions and products.

The straightforward nature of agile approaches is appreciated. This is because it propagates little administrative ceremony and places goal achievement ahead of adherence to precise procedures.

Also valued is the ability to adjust iteration cycles according to project needs. Short, intensive or high-risk projects can work very well with one-week cycles. If projects are of a different nature, there is nothing to be said against a different iteration length.

Dangers for Agility

Sometimes you hear complaints from companies with an ad-hoc culture that even agile approaches encompass processes that are too formal, impose too many rules, and thus get in the way of creativity.

However, this attitude ignores two things:

  1. Agile approaches prescribe only a minimum of ceremony and even allow it to still be adapted to the circumstances of the organization, the project and even the current situation in the project.
  2. There is a thin line between self-organization and chaos. Approaching chaos may well be liberating for creativity, but it can just as well have a negative impact on productivity. Agile teams don’t actually want to slip into chaos, they just want to stay close to it so that change is enabled while still allowing for purposeful work.

The emphasis on individual freedom and independence can make it difficult for employees to fit into a team. Although agile teams encourage self-competence, they also want team members to be strongly supportive of each other. They encourage team members to find a common work rhythm. This helps them deliver an increment of functionality at regular intervals (iterations). This requires that team members bring a certain level of discipline. They are also encouraged, in some circumstances, to define and adhere to common standards of approach so that a consistent, quality deliverable can be created.

An ad-hoc culture can have a strong influence on Agile change efforts by fostering a results-oriented environment.

Conclusion

Any prevailing culture influences heavily the way we work, think and also how we handle change. Any Agile change effort that does not take into account the prevailing culture in a company will encounter significant resistance without having a means to interpret and understand observed behavior.

To be able to influence the environment positively we need to inform our interventions with cultural awareness. This can not happen acting from afar, but we need to dive into the culture, work closely with people and leverage the existing culture to move forward.

Footnotes

  1. Kim S. Cameron & Robert E. Quinn, Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework, 3rd Edition, Jossey-Bass, 2011↩︎
  2. Jeffrey K. Liker, The Toyota Way, 2nd Edition, McGraw-Hill, 2004, Chapter 3 ↩︎
  3. Jeffrey K. Liker, The Toyota Way, 2nd Edition, McGraw-Hill, 2004, Chapter 9 ↩︎
  4. Jeffrey K. Liker, The Toyota Way, 2nd Edition, McGraw-Hill, 2004, Chapter 2 ↩︎
  5. Jeffrey K. Liker, The Toyota Way, 2nd Edition, McGraw-Hill, 2004, Chapter 11 ↩︎
  6. Peter DeGrace & Leslie Hulet Stahl, Wicked Problems, Righteous Solutions, Yourdon Press Series, 1990 ↩︎
  • CHECK OUT NOW

  • The Practitioner's Handbook Early Edition is available now

Veröffentlicht am

ChatGPT for Agile Software Development – Boost or Risk?

ChatGPT sample code generation dialog

Agile software development is a widely adopted methodology that emphasizes flexibility, collaboration, and iterative progress. As software engineers strive to optimize their workflow, the use of ChatGPT can offer numerous benefits to enhance their agility. However, it is important to be mindful of potential risks that could hinder the agile process. Let’s explore both the advantages and potential pitfalls of incorporating ChatGPT into agile software development.

Ways ChatGPT Could Help

There are some ways ChatGPT could help software engineers be more Agile:

      1. Improved Communication: Effective communication is a cornerstone of agile development, and ChatGPT can facilitate this by providing real-time feedback and suggestions during team discussions. It can analyze code snippets, offer syntax recommendations, and even assist in identifying potential vulnerabilities. This could streamline the development process and fostering collaboration among team members.

      1. Rapid Prototyping: ChatGPT can aid in generating code snippets and prototypes, which can accelerate the development of minimum viable products (MVPs). This allows software engineers to quickly iterate and gather feedback from stakeholders. Doing so could lead to faster decision-making and validation of ideas, a core principle of agile development.

    1. Enhanced Documentation: Documentation is vital in Agile development to maintain transparency and knowledge sharing among team members. ChatGPT can assist in generating documentation templates, code comments, and other technical write-ups, saving valuable time and effort, and ensuring that project documentation remains up-to-date and accessible to all team members.

But… where there is light there is shadow.

Dangers to Agile Development with ChatGPT

A few points com to mind, when we want to highlight the risks:

      1. Over-reliance on Automation: Relying solely on ChatGPT for code generation and suggestions can potentially lead to a decrease in critical thinking and creativity among software engineers. Agile development values the human element, and excessive reliance on automation could result in a loss of innovation and diversity of ideas, which are essential for creating robust and unique solutions.

      1. Quality Control Challenges: While ChatGPT can provide suggestions for code snippets, it may not always guarantee the best practices or optimal solutions. If not thoroughly reviewed and validated, code generated by ChatGPT could potentially introduce bugs, security vulnerabilities, or violate coding standards. This may result in increased technical debt and rework, contradicting the principles of Agile development.

    1. Ethical Considerations: As a language model, ChatGPT can potentially generate biased or unethical code, especially when trained on biased data. This could result in unintentional propagation of bias or unethical practices in the software being developed, which could have ethical, legal, and reputational consequences, posing a risk to the integrity and fairness of Agile development.

Mitigating the Risks

There are though some things we can do to mitigate the risks:

      1. Strike a Balance: Software engineers should strike a balance between utilizing ChatGPT as a tool for assistance and leveraging their own expertise and creativity. It is essential to maintain critical thinking, innovation, and human decision-making in the agile development process.

      1. Validate Generated Code: Code generated by ChatGPT should be thoroughly reviewed, validated, and tested to ensure it adheres to coding standards, follows best practices, and meets quality requirements. This includes thorough testing, code reviews, and validation against project specifications to identify and fix any potential issues before deploying the code.

    1. Ethical Considerations: Be mindful of the ethical implications of using ChatGPT in software development. Training data should be diverse, inclusive, and free from bias. Review the code generated by ChatGPT for any potential biases or unethical practices, and take necessary steps to mitigate them. It’s important to have a strong ethical framework and guidelines in place when incorporating ChatGPT into the Agile development process.

An Experiment

My personal (admittedly still limited) experience using ChatGPT to generate and explain code confirms the risks associated using the tool (at least in its current state).

Actually, when using it intensely and double checking its output, one can still see its limits.

The code it generates looks mostly clean, but it does not follow a specific coding style. Actually the temperature setting of the ChatGPT dialogue engine is set to give “creative” answers. So you will get different variants on how you could implement an idea. If you have no personal idea on how a solution should look like you can go with any proposed code. But if you try to stick to a specific coding style, you oftentimes find yourself second-guessing what it proposes.

How far ChatGPT’s understanding of the code goes can be easily challenged doing these few steps:

      1. Let it generate some code (for a problem domain, you might be familiar with).
        → I let it generate code to calculate the distance between two planets at any point in time.

      1. It usually gives a verbal explanation on what the code does.
        → It explained to me, that it was using a Euclidean formula to calculate the distance.

      1. Then modify the generated code slightly (like a programmer would do, when moving it to an IDE and evolving it over time).
        → I just changed the calculation of the Euclidean formula slightly.

    1. Paste the modified version of the code back into ChatGPT and ask it to explain the code.
      → ChatGPT explained to me that the code used the Euclidean formula. But this could not be true, as I changed the formula to be invalid.

Conclusion

Just this little experiment shows the danger of relying too much on ChatGPT’s help, at least in its current state. There actually is no reasoning behind what it spits out. Unfortunately for many people that do not take its output with a grain of salt its convincing authoritative tone will produce lots of non valid output.

So yes, validating, testing and questioning its output is essential. We as developers need to step up our game, by knowing what the expected results should be, before asking ChatGPT. So Agile development skills will be in high demand more than ever before.

In the coming weeks I will have a look at various practices from Agile software development (like test automation, evolutionary software design, etc. ) and how they are impacted by the use of artificial intelligence tools.

If you are interested in improving your Agile implementation, then check out my upcoming book.

Note: My experiments were done using ChatGPT version 3.5. As soon as I can get my hands on ChatGPT 4 I will do a follow-up to this post.

 

  • CHECK OUT NOW

  • The Practitioner's Handbook Early Edition is available now