Over the years in my consulting practice I’ve had the opportunity to help several organizations adopt agile techniques at both the project and enterprise levels.  I’ve also seen organizations struggle to either incorporate the experiences of the initial projects to adopt agile techniques within other teams or to simply remain agile on these original teams.  Although change such as becoming fully agile this is never easy, it definitely helps to understand that there are several common challenges which organizations seem to face when becoming, and then remaining, agile.

These challenges include:

1. We don’t have much experience remaining agile (yet).  Because many organizations are still just in the process of adopting agile approaches there hasn’t been many organizations that have fully made the change, and fewer yet have had to struggle through remaining agile.  The implication is that most of the advice in this section is conjecture, so take it for what it’s worth.

2. You staffed the initial teams with pro-agile people, leaving the doubters for later.  This is a actually a good strategy to take, but it can make it very difficult in later rounds of adopting agility within your organization.   Many organizations seem to invest significant effort at the early stages of adopting wholesale changes such as this, but after several years people begin to lose interest in the change and declare success too early.  Thus the people who are most resistant to the change are often given the least resources to make the change, which means they often don’t truly make the change and are likely to slip back into their old ways.

3. Serial thinkers.  Many IT professionals not only still believe in serial approaches to development they are not even familiar with evolutionary, let alone agile, approaches.  This is perfectly normal when you consider that a large portion of the process-related advice over the last thirty to forty years has focused on serial strategies.  The result is that many people think in a serial manner, they want to identify and analyze most if not all of the requirements before they tackle design, they want to design most of the system before they start coding, and so on.  These people will need to be given time, training, and mentoring in the new ways of working. Unfortunately, as I pointed out in the previous point, these people are likely to be left to the end of your overall change program and may not get the support which they need to truly make the change. More importantly, you’ll need to be vigilant to ensure that a serial mindset isn’t hampering your ability to be agile, or at least you want to publicly recognize that you’re not quite agile yet and need to still improve.  The bottom line is that people with a serial mindset are very likely to both resist the adoption of agile techniques are will abandon them the first chance that they get.  It will prove very difficult for your organization to remain agile if you do not invest the resources required to retrain these people.

4. Closed mindedness.  Many traditional IT professionals are close minded to agile approaches, they haven’t invested the time to learn about the techniques, they make the mistake of assuming that agile software development is merely code and fix in disguise, or they accept the prejudiced dogma of “anti-agilists” without looking into it for themselves.  Be on the lookout for these people and actively try to educate them, most people will eventually accept agility particularly if you show them how agile approaches work in practice within your organization.  Sometimes people will persist in publicly sharing their misunderstandings about agility; in these cases you need to consider challenging them to diffuse their efforts before they spread too much misinformation.  You also need to accept that your organization likely has some old dogs who can’t be taught new tricks, people who may need to be motivated to find employment elsewhere so that you can succeed at agility.

5. Politicians.  Politics is a necessary evil within all organizations and you’re going to have to become politically adept if you wish to succeed with agility.  Some politicians will actively try to prevent the spread of agility, particularly if it threatens their power base, and may even try to change back to non-agile approaches when given the opportunity.  Smart politicians will sit back and wait to see what happens, then once it becomes clear to them that agility is the right direction they’ll “jump on the bandwagon” and publicly support your efforts.  Smart politicians will also claim to support agility, they’ll even go through the motions of changing, but in reality this will prove to be just a façade over their existing organization which is still following traditional approaches. These politicians are basically waiting for agility to fail so that they can easily change back to their old ways.

6. Black and white mindset.  Many IT professionals believe that issues need to be black and white.  As a result the IT industry constantly seems to inflict religious issues upon itself such as Linux vs. Windows, object-oriented vs. data-oriented, .Net vs. J2EE, and agile vs. traditional.  The reality is that it isn’t a black and white world, that there are in fact grays and even a wide spectrum of colors.  Most organizations, particularly large ones, will discover that they need to adopt a range of methods, some agile and some not.  The implication is that IT professionals, particularly enterprise architects, need to be flexible in their approach.  Inflexible people will make it difficult for your organization to adopt agile techniques and then after you have done so they’ll make it difficult to remain agile.

7. Fear of change.  The adoption of agile techniques likely requires significant changes in the way that your organization works, changes which will take years to fully adopt. It is completely normal for people to fear change: either they are afraid that they won’t be able to learn the new agile skills or that they simply won’t fit in to the new environment.  The bad news is that people who fear change will actively try to prevent it, either publicly or privately, undermining or even reversing your efforts to become more agile.

8. Specialists.  One side effect of a serial approach to software development is that many IT professionals have become specialists with a very narrow skillset.  Although specialists are often highly skilled at what they do, they often have little understanding of other specialties and may even have problems working with others outside their specialties.  How many times have you met a programmer without basic requirements gathering skills, data modelers without programming skills, or project managers without a basic understanding of the technologies their teams were working with?  Those people weren’t very effective, were they?  A better strategy is to become a generalizing specialist, someone with one or more specialties who has a general knowledge of software development and better yet the business domain as well.  Generalizing specialists are more effective than specialists because they appreciate the issues that others on their team face and often have the rudimentary knowledge and skills to understand potential solutions.  Teams comprised of generalizing specialists can travel lighter than those of specialists – each specialist needs to record basic information within the artifacts which they understand, resulting in the team tracking the same information in several places, whereas generalizing specialists can record the information once in the most appropriate place because they understand and can work with a much wider range of artifacts. Your organization needs to actively promote the idea that your IT staff expand their skillsets; this will make it easier for individuals to be agile and thus your organization to remain agile.

9. Out of date skills.  Many people haven’t kept up with agile software development techniques, particularly those in specialties that do not have a strong object-oriented programming culture (which is where agility has its roots), and find themselves unprepared for agile approaches.  Worse yet, in recent years many organizations have cut their training and education budgets to the bone and haven’t invested in the improving the skillsets of their staff.  The bottom line is that many people face a very steep learning curve which your organization may not have provided them sufficient time (several years in some cases) to overcome.  People need to first truly become agile if they are to remain agile.

10. Ivory tower mindset.  A significant minority of enterprise architects believe that they shouldn’t sully their hands with “mundane programming” activities, instead they believe that their role is to think through the big issues and then to model them.  This attitude is problematic for several reasons.  First, their detailed knowledge of current technology quickly becomes out of date and thus they begin to make unreasonable assumptions about how things work.  Second, many programmers have little respect for so-called technical people who don’t code and will discount anything that these people say or do.  Third, the architects will often invest more time than they need to documenting their work instead of mentoring developers in it.  Fourth, the architects have little opportunities for the concrete feedback which they need to verify that their architecture actually works, they instead have to wait for project teams to report back to them, often months or even years later.  When development teams are working in agile manners, yet some of the people (such as ivory tower architects) whom they interact with do not, it will cause organizational friction which will wear away at your software process improvement (SPI) endeavors.  A better approach is described here.

11. Documentation-heavy mindset. For years many IT professionals have been led to believe that developing comprehensive requirements documents as well as detailed design models are an effective way to develop software.  This mindset has been prevalent with a large number of people for decades, yet recent studies have shown that documentation heavy approaches leave little to be desired.  One study found that the creation of detailed requirements documents early in a project and the change management procedures associated with doing so is the leading cause of failure on IT projects.  Another study found that the creation of detailed design models had no effect on the success of a software development.  Larman (2003) presents a detailed summary of the research evidence supporting evolutionary development techniques and the evidence showing the problems with serial techniques in software development.  It is possible to take an agile approach to documentation. Although agile teams still need to write documentation, hopefully agile documentation, they need far less than people with a documentation-heavy mindset would like to see.  These people either need to be retrained to work with less documentation, or they need to be reassigned to other efforts, so that development teams are allowed to remain agile.

12. Chargeback schemes.  Agile enterprise architects, among other enterprise support groups, are directly involved with helping project teams to adopt and evolve their work.    The challenge is that enterprise efforts need to be funded in some manner, and a common way to do so it to apply internal charges to the project teams for services rendered to them.   Although this is clearly a sensible approach it has the drawback that it motivates project teams to minimize their contact with the enterprise architects, thus hindering the spread of agile enterprise techniques.  Another approach is to fund enterprise groups directly and not charge project teams – from the point of view of project managers the enterprise architects effectively become free labor, and who is going to turn that down? 

13. Desire to do it all at once.  There are a lot of ideas and techniques described in this book, but it would be a serious mistake to try to adopt them all at once because the change is likely more than you can handle.  Luckily there’s an old adage that you eat an elephant one bite at a time; the implication is that you should adopt agile techniques one at a time, evolving their environment over several years in order to make the shift to agility more palatable.

Recommended Resources

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.