“Personifying Practices” – A theory of Agile teams, Part 2

My human-factors research on Agile software development teams is developing a theory about what is going on in their environment, specifically regarding the impact of management and leadership in large organisations.

When Agile software development teams and managers interact in their working environment they tend to “Personify Practices” as a way of making sense of their relationship. This was the idea introduced in Part 1 and draws on 2 years of interviews with 25 senior Agile practitioners from various countries. The results were mapped into a hierarchy of 1000 codes which have been further categorised and analysed for themes and key factors that describe what is going on. The theory of “Personifying Practices” aims to abstract this data even further and deepen this understanding to provide re-usable insights. Some of these initial insights are already provided in previous articles about how to create optimal environments for Agile teams: Part 1 and Part 2.

Through the Grounded Theory method, it became clear that the 2 most significant categories of data are management and methodologies, with sub-categories under each of these that were clustered using frequency analysis. These descriptive factors with examples from the data were written about previously in Factors Affecting Agile Team Environments. The theory of “Personifying Practices” should now be able to integrate these main categories of the data into a holistic framework that doesn’t oversimplify the human-factors issues but aims to provide a theoretical framework for understanding them better. Using the two main categories of data, I created a 4-box model shown below. The x-axis is the management category; a range of how management is perceived in the environment, from negative on the left to positive on the right. The y-axis is the methodologies category; a range of maturity in how well Agile methods are being applied in the environment.

On this grid it is now possible to group and explain the data points as different types of relationships in the environment. The human-factors nature of the research was always expected to lead to some sort of construct about how people interact – the result is somewhat intuitive and unsurprising. However now the extensive bottom-up analysis of data can be integrated with – and provides evidence of – a top-down relational construct centred on the notion that people “Personify Practices”. Management and Agile are often considered incompatible (“Why do managers hate Agile?”, “Transactional leadership and Agile; conflict or contrast?”), however my research interest is understanding whats going on when they do co-exist; I found a vast range of outcomes and the theoretical framework below attempts to pull it all together.

Beneficial Partnership: +ve manager +ve methodologies

There is positive perception of a manager as a personification of management practices; Agile methodologies are mature and fit for purpose, they act as a strong counter balance to the practices of management that impact on the team. This equilibrium supports a balanced relationship between management and the team which is one of partnership because both groups recognize the mutual benefit of relating on equal terms in how software is delivered. Both sides accrue benefit from the partnership; management get the best practice software and the team get the right level of management support that suits their environment.

Example from the data: “very supportive … from a training perspective, from a career perspective … from an impediment removal process, they [the manager] were usually the person to whom the scrum master would go for support”

Uninformed Powerplay: -ve manager -ve methodologies

Data points in this quadrant talk to a lack of information on both sides, management does not understand what the team is doing and vice versa. Overbearing management practices are personified as “bad management” which seeks to compensate for the weak application of Agile methodologies. A powerplay arises in this vacuum and the personification of weak agile methods becomes the poor performance of the team members which management tries to fix by micro-managing, which is in turn taken personally in a vicious cycle characteristic of many unsuccessful team environments when Agile and management are proven to be incompatible.

Example from the data: “He [the manager] wanted to be involved. He felt like it pushed him out from day-to-day involvement and he wasn’t sure what to do with himself.”

Dogmatic Co-operation: -ve manager +ve methodologies

Agile methods are mature and strengthen the team but there is a negative perception of management, possibly a new manager unfamiliar with Agile enters the environment and tries to exert personal authority. The manager is simply applying their handbook but as their practices are likely to be based on transactional leadership it can be expected that there is friction with the servant leadership philosophy underpinning the Agile manifesto. There is co-operation through mutual dependency and strong methods prevail because they are the best chance of making progress. The co-operation is dogmatic in nature because each side defers to practices for strength.

Example from the data: “what’s happening … especially in the Agile environment is, we’ll be kind of dogmatic about it. And it’s not cool”

Sympathetic Alliance: +ve manager -ve methodologies

Progressive (but possibly laissez faire) management practices are well received by a team who are probably experimenting with Agile methods and have not bedded down their methods. Management practices are personified in a sympathetic manager who understands the team’s need for space and time to adopt and bed down mature processes. Management and team are aligned in ultimately getting the job done in a safe environment but sympathy is time-based and the team cannot experiment forever. If the methods fail to work then structure will need to be restored through stronger management practices which will be personified as an unsympathetic manager – as perceived by the team.

Example from the data: “you’ve got to be courageous to do this, because people want results tomorrow. And you’ve got to be able to create the kind of space where it says, “We’re going to build this thing right.” “

Get more Leadership Insights for IT professionals - sent directly to your inbox

People and Technology have changed. Have you?

Get insights & new blog posts emailed to you weekly, to help you improve your IT Leadership.

I hate SPAM and promise to keep your email address safe.
Unsubscribe any time.

Please Leave A Reply In The Comments Below: