This is a guest post by Scott Duncan. Scott is a Certified Scrum Practitioner who has been involved in all facets of internal and external product software development with commercial and government organizations since 1972. Scott has spoken a many conferences and seminars over the years including many agile ones over the past 5 years both in the USA, Finland and Israel.
A lot is written these days about agile methods having “crossed the chasm,” that is, moving from early adoption and more risk-taking organizations into traditional IT and more risk averse organizations. In one sense, this speaks to the benefits people have begun to realize from adopting and agile approach. In another, however, it means that some “bandwagonism” has also taken place and organizations are moving to agile because it seems to be what others are doing. And this occurs largely because many who have moved tell stories of success with an agile approach. However, like many new things in software development, not just agile methods, this adoption across the chasm shows signs of how people became involved with case technology, ISO 9001, CMM, etc. in the late 80s and 90s:
1) Those who have adopted it either do not say much about their experience or speak largely of their success with the new approach. Hardly any company wants to stand up publicly and describe how they failed at their attempt. Thus, most of the “buzz” is positive, suggesting to others that they need to be getting involved with this because success seems to be the norm.
2) The desire is to get going with “something,” so the training and consulting sought by companies is usually focused on “how-to” knowledge. This allows them, as soon as possible, to start “doing it.” To get to this stage of bringing in a new approach, some senior management probably had to be convinced to invest time and money in the effort as well as accept the potential risk that it does not go well. Thus, that management would like to see something done to prove the approach as soon as possible.
3) The new approach is likely not going to fit into the current organizational structure/culture without some (potentially significant) change. Just how much change an organization can truly tolerate has a lot to do with their risk-averseness and place on the stability spectrum. There will be well-respected, thoughtful people who will not be comfortable with what these new approaches will demand. They will want to see a more, at least, “go easy” approach for the adoption effort.
4) There will be talk of how to “tailor” the approach to “fit” the organization since it will appear only reasonable that no generic new approach can be ‘right” for each and every organization. So practices and techniques will either be swapped out for ones closer to what the organization already does or, in some cases, abandoned altogether as “not yet feasible” because of the level of change required.
5) Finally, there will be innumerable firms offering organizations a path to implementation which will support the idea of “doing” as soon as possible. Many of these will be over the chasm companies themselves who have decided the new approach is the “thing to do” to show they are “leading edge” to their customer base which is expecting them to know the new method. These companies will have some of the same issues making the new approach fit into their existing culture and offerings. In some cases, this will result in trying to make the new approach look a lot like the company’s existing approach to show the client base that no radical change has to occur. This will make clients more comfortable with the idea of adoption since it may seem to be relatively easily accommodated in an existing way of doing things.
Again, regardless of the approach, what is often missing in an organization’s early understanding of such new approaches are the basic principles (and values) behind the external practices, techniques, and how-to guidance. Thus, if an organization does not understand what is behind a given practice/technique, tailoring can limit, even destroy, the point of the practice. The point is usually more than the outward behavior the practice asks people to emulate, so changing the practice because the behavior is too challenging or, apparently, unnecessary for the current organization ends up with a replacement that may not produce the result needed (or, indeed, produces some result that works against effective adoption of the approach as a whole).
For larger, more comprehensive programs with numerous requirements and processes to implement along with the associated documentation, the impact of a change here and there may be negligible in the overall implementation. It is likely to be top-down driven and involve substantial parts of the organization with significant expectations and guidance for how new processes will be implemented. Such efforts are also likely to fit in with, or be made to fit in with, existing organizational structure. Large organizations also know how to absorb these comprehensive programs without overt opposition and failure but also without benefits that equal the cost of implementation. (Aspects of the cost can also be smoothed over as it can be hard, in a traditional, phased-based, sequential lifecycle, to completely trace and account for all the time spent. Proofs of ROI can be easy or hard to come by depending on which way people actually feel about their tolerance for change.)
So what does all this mean for agile adoption?
Agile approaches are sufficiently low on formality and high in visibility that actual resistance to change cannot be hidden very effectively. The short iterations with clear delivery goals make it hard to cover up lack of achievement of those goals. This is all good news for an agile approach. However, rationalization for tailoring agile practices to fit the organization is less easily resisted. When such tailoring misses the point of the original practice it can be harder to definitively prove that the tailoring is causing any lack of success adopting the agile approach.
For example, take the XP practice of pair programming. Some people find pairing to be uncomfortable, intrusive, slow, not a good use of “resources,” etc. as a way to get code written. They may, then, simply abandon this practice, not knowing, perhaps, that there are other possible practices that would not as completely dispense with some of the goals of pairing (e.g., ping-pong programming, side-by-side programming). If an organization does not try to stick with the agile values and principles and understand that pairing isn’t simply about getting code written, their tailoring may easily lose the communication, feedback, visibility, trust-building, design integrity, etc. that are part of this practice.
Having experienced large organizations deciding to “go agile” and diving in after a couple days of training and minimal (or no) coaching, I believe this lack of a firm understanding of the values and principles causes much confusion and difficulty later. Indeed, from the very outset of the effort, enough tailoring may have been done such that the organization never does experience the full benefit of an agile approach. In this way, further tweaking and tailoring to “fix” the problem of less benefit than expected will seem even less divergent from the values and principles. Efforts to argue against such will seem to be, as noted above, a dogmatic stance taken by those since they may not be able to properly verbalize what the tailoring is doing to the agile approach and why they advocate sticking with the recommended agile practice(s).
For this reason, I believe it is critical, early in the training/exploration associated with an agile adoption, to make sure everyone who will be involved with or affected by the adoption effort understands the agile values and principles. In this way, when they feel they need to tailor something or as they suggest changes to their process through retrospectives, they will be better able to recognize whether the proposed change to an agile practice/technique is moving the work further from the benefits intended by an agile approach and which the practice has been design/developed to support. Indeed, without this understanding, dogmatism may arise in defense of the practices, making adoption harder because advocates may be seen as refusing to support the organization in making the transition. Likewise, without such understanding, efforts by the organization to “warp” the agile approach to more comfortably fit the “dysfunctions” that exist will not be as easily resisted since the discussion will revolved around possible minutiae of practices and techniques not the harm such changes may bring because of how they subvert the goals of agile values and principles.
(images by mshades and Wolfgang Staudt)
Twitter -
Subscribe -
Newsletter -
Bookmarks
Latest, greatest and favoritest posts:
The Big List of Agile Practices
The Decline and Fall of Agilists
AINO: Agile In Name Only
