Factors affecting Agile team environments

This article provides initial results from ongoing research into Agile software development teams in large companies. Such teams usually depend on management’s policies and processes to establish and run their organisational environment, while they focus on the job of delivering great software. The Agile Manifesto specifies that such environments must be supportive and we must, “trust them to get the job done.” However, this is based on the servant leadership philosophy, while traditional management practices typically espouse transactional leadership thinking aimed at achieving high performance through contracts and reward / punishment systems. I’ve written previously about understanding transactional leadership in the context of Agile and how managers can set up better environments for teams (Part 1 and Part 2).

In the last two years I have interviewed 25 senior Agile practitioners from 9 different countries to try and understand these issues in more detail. It is important for large organisations to set up environments which are conducive for Agile programmers and this research is aimed at contributing in this area. I’m using a research methodology called “Grounded Theory” which is a systematic approach to constructing a theory through the gathering and analysis of data. It’s a rigorous process for analysing unstructured data such as interview transcripts and is thus quite common in social sciences. It is gaining traction in software engineering research as we seek to develop a deeper understanding of human factors in IT.

From the transcripts of the 25 interviews, I developed a system of codes which are incidents in the data where something relevant to the research questions are identified. For example, one of my interviewees spoke strongly about how managers should not get involved with testing so I mapped that paragraph in the transcript to a code labelled “testing shouldn’t be a concern of managers”. A total of 973 codes from all the interviews were then grouped into sub-categories and main categories in a hierarchy using Nvivo, which also houses all the research data such as interview audio files and transcripts.

A total of 16 significant sub-categories were identified based on how many incidents they accounted for. For example the category “organisational culture” grouped together all the codes relating to that topic but there were only 45 across 10 of the 25 interviews. Contrast this with the category “management bad” which has 111 incidents across 19 interviews and is thus a much more significant concept in the data. The 16 were mapped against each other based on how many incidents there were in the data and in how many of the interviews they occurred, this is shown below.

Three clusters of sub-categories are clearly shown, (A) being the most significant because it accounts for the most incidents across the most number of unique interviews. Cluster (A) consists of the 5 categories, “management bad”, “challenges”, “management good”, “teams” and “people factors”; the properties of each of these are given below which are derived from the underlying codes and raw data within each:

  • Management bad: Blaming, public criticism, fear, negative connotation with the project manager, tick boxing, nastiness, psychopathic, deadlines don’t change, affects trust, shouting, micromanagement, don’t know the detail, command and control
  • Challenges: Failure, trade-offs, hard work, big projects, external factors, old ways of working, business not involved, recruitment, fight for transparency, loss of skills, stamina required, delivery vs transformation, unpredictability
  • Management good: Flexi hours, caring, servant leadership, supportive, delegated, allowed training, motivated people, advisory, share experience, trust, fun, removes blockers, stood back, incredible leader
  • Teams: Self-organisation, co-location, large teams, Trusted teams, try new things, maturity, constrained by current ways of working, inspired by great managers, solve problems with collaboration, make trade-offs, blockers and impediments, transparency
  • People Factors: Self-development, participation, video chat, emotions, pep talks, stay neutral / diplomatic, conductor role, people don’t want to be exposed, achieve well then have space, need to drive change, people feel like robots, developers speak their minds, bring people together, language, visceral response, self-development, listening

This understanding of the relative significance of categories as well as their properties will be useful in the next stage of the research. It will then be possible to develop an explanatory theory of “what is going on with Agile teams in large organisations?” Emphasizing these critical issues will ensure that the new theory accounts for the majority of their concerns.

About The Author

5 thoughts on “Factors affecting Agile team environments”

  1. Hi Peter,

    Yes in the age of increasing automation and the 4th industrial revolution it seems that things in your A group are still people related.

    Have you investigated the role of Design Thinking, Lean Startup and Agile before? I would be interested to know your thoughts on the diagram on page 23 from the Gartner Enterprise Architecture and Technology Innovation Leadership Vision for 2017 report (https://www.gartner.com/binaries/content/assets/events/keywords/enterprise-architecture/epaeu17/enterprise_architecture_and__tech-innovation.pdf).


  2. Rodney Chambers

    Agile is new to me and I find it to be quite interesting when compared to transactional leadership styles.

Leave a Reply

Scroll to Top