An Enterprise Strategy for Introducing Agile: Part 4 – Impediments: Teams, Management and Culture

When initially introducing Agile practices to a team, the difficulties experienced by the team are all centered on the immediate adoption of the practices, and the consequences of that adoption. After some experimentation with Agile methods the focus becomes centered on larger problems that confront an entire team. Once experienced with Agile practices the problems are larger still and will confront many teams. The scope and nature of the problems faced by an Agile team grow over time as knowledge of Agile practices spread throughout the organization in ever increasing circles of influence.

In an effort to discuss the issues faced by Agile teams, I’ve broken down these issues into the following categories: People, Process, Technology, Teams, Management and Culture. My final article in this series of articles ([1], [2] and [3]) discusses team, management and cultural impediments faced by teams transitioning to an Agile model.

On the whole, teams seldom present impediments to Agile adoption. Most Agile frameworks strongly advocate close, cohesive team work and the result is typically advantageous to team environments. The learning process that the team needs to undergo may be very slow [at least initially], but I personally won’t consider that to be an impediment. I simply view this as being the nature of change.

So, if there is going to be any friction, it is likely to be between different teams than within a particular team. There is the possibility of friction in any situation when one team is dependant upon another or where two different teams are using different methodologies; Agile vs. RUP, for example. In both these situations the standard approach is to prioritize dependant functionality early and code to an agreed upon interface … but this is overly simplistic. I feel that’s it’s important to recognize that there is a dynamic relationship between dependant teams which needs to be actively, and continuously worked. Failing to acknowledge the risks involved in dependant projects can quickly lead to confusion and impact the team performance.


“In the culture of management, the worst thing you can do is admit to anyone that you have a problem you can’t handle by yourself. If you really do need help, you have to sneak it in somehow without admitting in public that there is any problem at all.” – Gerald Weinberg.

Educating a new client on how to build an Agile organization can be very slow and difficult work. In order to be successful you need to be able to speak persuasively at many different levels of the organization. Speaking to the team or to individual members of the team is the usual approach because this is the level into which most consultants are brought. But there is also a wider audience to consider which includes functional managers, the PMO and HR.  Failure to address this wider audience can hobble the transition to Agile (see below).

There is an assumption that management are able to see the changes for themselves and that they will automatically understand the value of Agile methods. I’ve personally found management to no different from everyone else and that they also require education, coaxing and convincing that there is a better way to develop software. The only difference is that the topics of conversation are different for management then they are for developers: instead of discussing TDD, discuss Agile metrics (burn-down graphs over actual developer hours); instead of discussing Pair Programming, discuss the need for collocation.

When working with management, I’ve found that I’ve needed to pay special attention to both Agile metrics (or the lack, there-of), and adaptive planning over predictive planning. The Agile approach to both of these is counter intuitive for most classically trained managers and requires constant reinforcing.

Company Culture
As I’ve mentioned in previous articles, cultural changes are the most difficult to make within an organization. There will constantly be the argument “That’s not how we do things here”, or “We can’t implement that here”. These are “Yes but …” arguments as Ken Schwaber points out in his course. There are no easy answers, especially for something that’s as intangible as company culture.

“… logic and culture have nothing to do with one another.” – Gerald Weinberger

Cultural specific impediments are often related to how an organization rewards it’s employees. Specifically, the compensation, promotion and career planning models. In an environment where performance is determined by specialization of knowledge, the promotions and compensation models reward the compartmentalization of knowledge. Over a period of time (several years) this results in the organization having two (and maybe more) attributes: Certain activities are performed by specific individuals; and, the organization is managed as a matrix.

The first is immediately obvious. If Alice is rewarded for her understanding of the security system, for example, then she is likely to continue doing this until the reward mechanism is changed.

The second point is not nearly as obvious but is a reaction to increased specialization. In order to try and help circulate knowledge and information, groups are formed where the individuals share a common function. Typically this results in an organization where there are groups for Analysts, Architects, Developers, and Testers etc. Project teams are then composed by selection individuals from each of the different groups. Ironically, this functional grouping of people serves to in further segregate of information. Agile methodologies breakdown these arbitrary boundaries on a project-by-project basis by encouraging cross functional teams. Long term solutions are dependant on rewarding teamwork and breadth of understanding [5].

This is what you should not do …
When I was a child one of my favorite books was “The Bike Lesson” [6] where the common refrain was always “This is what you should not do.” In the same spirit I offer the following example of what not to do. As an example of failing to address all relevant parties in an Agile transition, I’d like to use an actual project of mine from several years ago.

A small team of experienced XP developers and I were asked to help a client introduce XP into the organization. We had some initial success and quickly brought the team up to speed. After a couple of months we had a collocated team, working in pairs to deliver tested software every two weeks. At the end of eight months however, we had left the client and had had only minor success in influencing other Agile projects.

So what went wrong? Looking back on it I made several mistakes of omissions:

  • I failed to adequately address dependencies between two project. The result was a delay in completing functionality, and this directly impeded the team’s progress.
  • I failed to recognize and address issues around developer compensation. Developers were reward (by promotion and compensation) for both specialization and building large frameworks. Introducing Agile and encouraging generalization over specialization of skills was a threatening move because it challenged both their position and their year end bonuses. By failing to address the issues around compensation I failed to gain influence with the architects, and eventually was unable to make necessary recommendations.
  • I failed to fully educated senior managers on adaptive planning. The result was that they continued to try and fix an end-date which became increasingly unrealistic with each passing iteration and casting doubt on the other successes that the project team were achieving.

My reason for providing this example is to make you aware that successfully introducing Agile methods into an organization is not a simple task. It takes many different skills both technical and political. The physical and political environment that you’re work within requires as much attention as the technical problems that you’re trying to solve.

Over the last few months, I’ve discussed a roadmap for the introduction of Agile methods, one possible model for that introduction, and some of the impediments that can occur along the way. If you find yourself going down a similar path, I wish you every success and I would love to hear about your journeys.

I’m going to take a break from writing such heavy weight topics [at least in the short term], so next week I hope to post work that’s more applicable to the ordinary day-to-day activities of Agile projects. I’m currently working on two posts that I’m excited about, so stay tuned!

[1] An enterprise strategy for introducing Agile: Part 1 The path to an Agile Enterprise
[2] An enterprise strategy for introducing Agile: Part 2 A plan of action
[3] An enterprise strategy for introducing Agile: Part 3 Impediments: People, Process and Technology
[4] Secrets of Consulting: A Guide to Giving and Getting Advice Successfully
[5] Unjust Deserts, by Mary Poppendieck
[6] The bike lesson, by Stan and Jan Berenstain

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *