Dave Thomas: I think agile methodologies have adopted their own venom. And to that extent, I’m pulling back, away from, the individual agile methodologies. I believe very, very strongly in agility. I’m an author of the agile manifesto and I think the underlying values of agility fit far better with my world view of how software should be built. I think some of the implementations of agile methodologies are, frankly, scarey in their kind of…

Bob Payne: dogmatic?

Dave Thomas: dogmatic, yeah that’s a good word, that’s a mild word for some it. It’s kind of like “my way or you’re not doing it properly”, a lot of blackmail, a lot of absolutes. And to me that’s not what agility is all about. So I pull back from that. I don’t want to be associated with that.

Bob Payne: In the past I’ve felt a number of pulls in different directions and I’ve started to realize that it is not necessarily the particular practice but what the resulting outcome is, the rhythm that it sets up.

This perspective sounds very similar to what I’ve been calling “agile without a name” or “effective software development” or what Tim Beck calls “pliant software development“.

P.S. I highly recommend the Agile Toolkit Podcast. It’s a great resource to hear candid discussions about agile topics.

It was also interesting to see that XP has been adopted in about half as many organizations as Scrum. Of course, I’d guess that many of the Scrum shops are using at least some XP software development practices.

XPlanner was the fourth most widely used APM tool and the only open source product in the top 10 most used tools. (There is a factual error in the survey results that says ScrumWorks is also open source. The ScrumWorks Basic product is free but not open source). XPlanner is also the most used tool focusing specifically on XP. It surprised me a little to see that XPlanner is adopted somewhat more by large organizations than small organizations. It’s possible that this is an indication that the licensing fees for the commercial tools are high enough to cause some pain for large organizations. I know at least one large organization that chose XPlanner over VersionOne for this reason.

As the founder^[1] of the XPlanner project, I’m very happy to see it so widely used even with no marketing or sales resources.

“The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly.”

In specific contexts, like junior programmers pairing on complex tasks, pair programming results in significant increases in quality. However, in other contexts the increase in quality, if any, comes at a high cost. The study doesn’t appear to support the conclusions described in earlier XP research. Specifically, that a team could expect “a 15% increase in development cost for a 15% improvement in quality”. This earlier study used students rather than professional programmers and the strength of some of the researchers’ techniques and conclusions have been questioned.

My own personal experience is that I enjoy pair programming for some activities and in some contexts, but not in all contexts. On complex tasks, I enjoy pairing with other senior developers for collaborative problem solving. It’s not as enjoyable, but I also see benefit for the team when pairing with junior or less skilled developers for some tasks. The less skilled developer may provide the occasional useful input often I feel the collaboration is a net loss in productivity. For example, let’s say we’re working on functionality that uses several advanced technologies. If my pair is not skilled in these technologies then the pairing will probably not be a net productivity increase. You could say that it’s valuable for training the less skilled developer in these technologies. However, I’m speaking about the case where the less skilled developer has already had extensive opportunities to learn the technologies in question and has not been successful. “Training” by pair programming will generally not solve this problem, in my experience.

When developing simpler functionality, I see more benefit from testing and specifically from test-first and TDD techniques than pair programming. For the either/or types of people I generally enjoy collaboration and I’m not the type that wants to work in isolation from the team. Pair programming is only one specific form of collaboration. I’ve worked exclusively in open work areas for the last 7-8 years and worked in those environments several times before then. I like that work environment very much and although I had the option to have an office I choose to sit with the team.

I like Martin Fowler’s perspective on pair programming. He says “my view is that you should try it and the team should reflect on whether they feel they are more effective with pairing that without”. I’d also recommend that the team discuss in what contexts they feel they are more effective or not.

I like the Wikipedia description of effectiveness. The description defines positive effectiveness in terms of efficacy and efficiency. Efficacy is the ability to produce a desired effect or achieve a goal. In a software development context, that might mean the ability to produce timely business value. Efficiency is the amount of effect that can be produced with a given amount of resources such as time or number of developers.

I think of efficacy as a primary component of effectiveness and efficiency as a secondary component. In fact, it’s sometimes desirable to intentionally reduce efficiency to increase efficacy. This is the idea behind having “slack” resources. The demands on a team are often dynamic and having slack resources for the peak demand times can improve the team’s overall efficacy. The challenge here is to know the right amount of slack to allow when future demands are uncertain. Of course, being highly inefficient will often not be efficacious. For example, wasting time on unnecessary or valueless activities might cause us to miss schedule milestones.

How do I know if I or my team are efficacious? I have to identify the desired effects I want to produce or the goals I want to achieve. A few examples might be:

• I want to produce something useful or valuable for my employer
• I want interesting work (learning new technologies, continually improving my skills)
• I want to generate sufficient income for my non-work goals like hobbies, travel, or retirement.
• I want balance between work, play, self development, and other activities

Of course, this list could become quite large and would be significantly different for different people. Sometimes the goals conflict and trade offs are required. Sometimes the trade offs are guided by values, but often observing the trade offs we make is a great way to discover our deeper and possibly unconscious and conflicting values. Create your own list. Are you achieving achieving those goals? How do you know? Do you judge your efficacy based on your feelings or by some quantitative method or some combination of the two?

So, are you as effective as you’d like to be? If so, that’s great. Ask yourself again every a few weeks. If not, what are you able and willing to do to improve your effectiveness? You might consider whether you have sufficient feedback. Are you evaluating yourself often (think of it as a personal retrospective)? It’s difficult to accurately predict the future effects of our actions so it’s good to get feedback frequently and adjust accordingly. Rapid feedback is a form of communication that allow us to courageously take action knowing we be able to quickly adjust our actions. This is starting to sound like the values of the first edition of Extreme Programming Explained. I don’t believe that’s a coincidence.

Speaking for myself, I am interested in the effectiveness of my software development activities, where “effective” must be evaluated in a specific context. In Effective Software Development (ESD), I want to have a wide range of resources (practices, tools, resources) available to me and I want to understand the tradeoffs associated with using these resources in various contexts. I’m not interested in labeling myself or my team as an “XP Team” or a “Scrum Team”. Who cares about the label if the team or organization is not effective.

I’ve seen several ESD teams who have used practices similar to the established named agile methodologies. However, they typically used a hybrid of those sets of practices. They couldn’t be labeled as Scrum or XP or Crystal or whatever. Their process was agile — but without a name. And they were effective.

I recommend not worrying about whether your team or organization deserves the fashionable “agile” label. The important question is “are you effective?”. Ask yourself what “effectiveness” means in your organization and then evaluate if your team meets that criteria. This isn’t an optimization problem. If you are effective enough, then focus on delivering value. If not, study the development options available to you and decide which ones will help you and your team be more effective. You might decide on a “ready-to-go” combination of practices like XP or you could experiment with a combination of techniques that are a custom fit for your team. Evaluate the results and adjust as necessary until you become an ESD team.

Values. A description of preference between alternatives. Often the alternatives represent candidate courses of action and the value guides the selection among the alternatives. Sometimes values are basically axioms. They can be irrational in the sense that we might not be able to explain them intellectually or they might be primarily based on emotions.

Principles. Statements describing a model. A scientific principle is a statement describing an aspect of physical reality. Principles might also describe a model of social activity, for example. Principles can be fundamental or logically derived from fundamental principles. It’s commonly believed that principles are derived from values, but sometimes people have certain values because of specific principles. For example, the XP “value” of communication can be derived from the principle that communication improves cooperation and coordination effectiveness. This circularity between values and principles can be confusing at times.

Practices. A pattern of activity that can be repeated to achieve goals within a context. A person defining a practice is applying principles within a framework of their values (preferences). A related collection of practices might be called a process or methodology.

The XP values and principles describe the basis for the XP practices. That’s interesting, but why should we care much about that? If the practices work, do we need to know the values and principles behind them? I believe we do, because the effectiveness of a practice very often depends on the context. Sometimes the practice fits the context reasonable well, sometimes it’s better to tailor or eliminate the practice. There may also be situations where we need different or new practices that must work well with our existing set of practices. Although the idea of tailoring or adaptation of practices causes concern for some agile practitioners (and they have some good reasons for that concern), the common need for adaptation has been discussed by influential thought leaders in the agile community.

You can use the principles to understand the practices better and to improvise complementary practices when you don’t find one that suits your purpose. While the statement of practices is intended to be clear and objective (“write a test before changing code”), understanding how to apply the practice in your context may not be obvious. The principles give you a better idea of what the practice is intended to accomplish. Also, no fixed list of situated, context-dependent practices cover all of software development. You will create new practices occasionally to fill your specific needs. Understanding the principles gives you the opportunity to create practices that work in harmony with your existing practices and your overall goals.
– Kent Beck, Extreme Programming Explained, Second Edition.

Martin Fowler also wrote…

One of the biggest issues with XP, and indeed with any agile method, is how to do the essential local adaptation where you alter the process to fit the local conditions. The principles help provide some guidelines on what bits of adaptation will work, and which go against the XP grain.
Martin Fowler, Bliki, Principles of XP

So why does adaptation create so much concern? The documented XP values and practices can be difficult to understand. Some values look like principles and vice versa. Some of the principles seem more like practices. The values and principles describe a model, but only vaguely. This description is not enough to really understand why and how the practices will work in specific contexts. One benefit of trying the practices as documented for awhile is that you will be more likely to develop and understand the model underlying the XP principles. Reading an XP book or two is not enough to gain that understanding. On the other hand, someone who has not read any of the XP books might have a similar model based on their own experience and thinking over the years.

As an example of potential sources of confusion, in Extreme Programming Explained (first edition), feedback is listed as a value and rapid feedback is a principle. In the second edition, rapid feedback was dropped as a principle. Is feedback (rapid or otherwise) a value, a principle, or what? It’s a little more clear if the principle is rephrased as “people tend to learn better with a shorter time interval between action and feedback”. That’s fine, but why is learning important? Learning is a form of adaptation. Maybe the principle is more general: “people tend to adapt more effectively with rapid feedback”. Combined with the principle that “adaptation can be an effective strategy for being successful in dynamic and uncertain environments”, we can conclude that rapid feedback will often help us be more effective in business and technology contexts that change frequently and where we have incomplete knowledge. I’ve intentionally used qualifiers like “tend to [have this effect]” and “will often [have this effect]” because principles must be considered in context. Here’s some other meta principles that might be useful: “principles are only valid in context”, “understanding the context where a principle applies will allow a person to apply it more effectively”, “looking for counterexamples for a principle can help to understand in which context a principle applies or not”. For feedback, we might review the principles of cybernetics and where feedback leads to problems. We can also evaluate our own experience for counterexamples. The risk of the latter is that it can be very difficult to remain objective when evaluating personal experience.

If you rely on the XP documented values and principles it can be very confusing. You really must think about it more deeply and define your own values and principles, possibly using the XP suggestions as a rough starting point. If your resulting values and principles are consistent with XP, then consider using some or all of the XP practices. Otherwise, find or create practices that are a better fit for your world view.

An effective team may accumulate some debt from time to time, but they are good about not allowing it to become excessive. My own experience is that I start noticing technical debt when it starts causing me some form of pain. The pain might be caused by code that’s difficult to reuse or refactor or it might be bugs or poor performance of either the production or the tests. It could also be code that’s difficult to read or is overly complicated (also related to reuse and refactoring in some cases). When I start clearly feeling the pain of technical debt, I become motivated to clean it up. Sometimes, just the thought of the pain of technical debt is enough to keep me disciplined to use development practices intended to prevent that technical debt from even being created. However, there are other developers and teams that don’t seem to feel the same pain I do in similar contexts and I’m curious about that.

What if we are seeing the effects of a difference in sensitivity rather than a difference in skills? I’ve known people who were very skilled in various aspects of software development but still wrote code that was difficult to understand, refactor, extend and maintain. I sometimes wonder if the key difference here is that these other people and teams have a different threshold of acceptable pain than I do. They don’t feel the pain that I do from that form of software source code. And likewise, I’m assuming there are people who have a lower threshold of pain than I do and that the code I write would cause them some degree of discomfort.

If this theory is true at all, then I have many questions. What’s the real source of the pain? What are the side-effects of very high or very low thresholds of pain? What’s the most productive level of sensitivity? And on and on.

As for the source, I’m sure it differs according to the individual. Some people feel pain when they see dynamic languages without type checking. Others feel pain when see code with excessive, useless comments. Others feel pain when see minimally commented code, regardless of the readability of the code itself. Speaking for myself, I tend to feel pain when I know that the existing code is going to slow me down in the future — or is currently reducing my ability to move forward. That’s why I feel less pain when I read code that’s well structured, with meaningful naming, well-written tests, and useful comments that don’t duplicate what the code already communicates.

What if someone has a very high threshold of pain? I’d expect to see lots of crud (technical debt) in their code and although the original author might (maybe) understand the code, most other people probably wouldn’t understand it very easily. The high threshold developer doesn’t mind spending weeks on new features that would otherwise require days or hours with clean code. And they don’t mind staying at work all night fixing bugs before a major release or spending countless hours babysitting the production system after it’s been released. It doesn’t seem to bother them to spend significant time away from family and friends or to have limited time or other interests and hobbies. In extreme cases, not only do these developers not feel much pain from this situation but they sometimes experience pleasure at being the “hero” who saved the company from the bugs they created. These developers might complain, but the complaining just reduces the pain — removing a potential motivating force to improve their productivity.

If a high threshold of pain can be a problem, what about a very low threshold of pain? I have less experience with this situation but I suspect that it might lead to pedantic, overly critical and rigid behaviors that serve as a defense mechanism for their high sensitivity. This might lead to excessive refactoring or testing that provides increasingly diminishing returns. It might also lead to an overly idealistic perspective on software development if the messy realities become too much to bear.

I know my own pain threshold varies over time as I’m guessing it does for everybody. Some days I am more numb than others. That’s one benefit I’ve seen from pair programming. It tends to average people’s thresholds so that code quality is more consistent. I’ve also found it useful to be able to intentionally modify my threshold (or intentionally ignore the pain) in certain situations.

As you may have guessed, I believe the most productive threshold is somewhere between the extremes — high enough to minimize technical debt, but low enough that courage and flexibility is not reduced too much.

However, it also appears that Brady has a limited understanding of the agile methods he criticises. To make his point he focusses on Scrum teams that apparently had weak development practices and who operated within a dysfunctional organizational environment. Other agile methods, like XP, tend to focus more on development practices but even XP is doomed if it’s attempted in a highly dysfunctional organization.

Brady describes a 6 person team that he says failed with Scrum (athough he appears to be claiming a more general failure of agile methods). He lists the results of that project.

1. “Project closed, business case closed and £30 million loss quietly absorbed and forgotten.” Was this project closure caused by the use of agile methods? At this point, it’s not clear. Would a heavier process have saved it? Again, it’s not clear.
2. “Testing was impossible with such limited up front requirements.” It’s not clear if the up front requirements were limited because nobody knew the requirements or because the requirements were not fully documented up front. In either case, it’s not clear why the requirements that were identified could not have been tested. Agile methods generally recommend incrementally developing the tests in parallel with with code. In other words, create a large well-tested system by starting with a small, well-tested system and evolving it.
3. “Acceptance criteria impossible to define because the requirements were never defined until too late in the programme.” No requirements were defined until (too) late in the project? That definitely sounds like a problem, but agile methods don’t recommend that approach. They recommend not waiting to define all requirements up front since requirements and context often change during development of a project. I’ve worked on very large, global development projects with formal requirements processes and requirements were still being defined late in the project. That’s reality. The world changes and we learn. In any case, assuming at least some requirements were known earlier in the project, they could have had acceptance tests written for them. Brady also says,
   

   The system would only run to 3 concurrent users. Not suitable for a system to be used by 1000s of people daily but who’s to grumble AGILE says this is OK to start building databases and systems without detail like this. Just keep moving forward is all that matters in this cloud of confusion. — Kevin Brady

   Apparently, no refactoring practices were used on this project. Given the weak testing approach, this is not surprising. It’s difficult to refactor effectively without tests even for the known requirements. Agile methods definitely do not say that forward motion in a cloud of confusion is all that matters. However, forward motion in a dynamic environment is possible, but requires a strong collection of practices to support it. It sounds like using agile methods in this organization was like putting a powerful engine in an automobile with a weak suspension, brakes, and tires. It’s a recipe for disaster, but that doesn’t prove all automobiles are flawed. It’s far from obvious that any other development method would have been more successful in the context Brady describes.

4. “Ran out of budget without early warning because no one could see more than 28 days ahead or new the full scope with unmitigated and uncontrolled changes in scope.”
   At least some agile methods (XP) suggest a release plan giving a longer range view of development activities. I don’t know enough about Scrum to know if this is true or not. I do know that a product backlog exists in Scrum that gives a view beyond 28 days. Why nobody could see farther than one spring is not at all clear. (All of these issues point to more fundamental problems than whether the team used agile methods or not.)
5. “Some of the worst usability I have ever seen because the user flows could not be tested up front because the requirements were at feature level”. It’s not clear, but it appears that Brady may be confusing the equivalent of XP user stories (a placeholder for development/client discussion about requirements) with feature level “requirements”. It is very true that defining user stories and never following up with the conversation to define specific requirements like user flows (and documenting those as test cases) could well be disastrous. However, agile methods don’t recommend this latter practice.
6. “A horrid final system. Because iterative development methods were used with each part of the system independently designed without a broad view of the full requirements.”The phrase “independently designed” sounds like a euphemism for designed with ineffective communication between the developers. It’s also clear there was no continuous integration practices. I not seeing any relationship between these problems and iterative development, as Brady claims.

I don’t have a strong objection to Brady’s beliefs about human nature although I believe they have little or no relationship to his criticism of agile methods. We need to find ways to heal “sickly” (Brady’s description) IT organizations so they can use more effective development methods the way the methods were intended to be used — agile or otherwise.

To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication. — Mishkin Berteig

These suggestions sound agile on the surface, but it could also be just a different variation of the “process over individuals” perspective. For example, the suggestions doesn’t consider the vastly different ways that various groups of individuals interact. Why not just prefer “effective communication” for a specific team and context without requiring a priori preferences about how that communication will be implemented? In my experience, a combination of communication styles and strategies including a mix of both face-to-face, synchronous communication and distributed, asynchronous communication have generally been the most effective. I believe it’s a false dichotomy, but if a team must choose between one extreme of always having distributed, asynchronous communication or always communicating face-to-face, then I would prefer the latter. I also believe it would probably not be the most effective way to communicate compared to a combination of the two styles, where the balance is tailored to a specific team’s personality, preferences, and other contextual aspects. Of course, in some contexts the balance might be close to one extreme or the other.

It may appear to be more difficult to discover the proper combination of communication styles than to accept predefined communication preferences. However, I’m confident that if a team wants effective communication and they use techniques like retrospectives to fine tune their behavior based on experience, they will succeed in finding what works best for them and become increasingly skilled at adjusting those approaches as project context changes. This feedback and adaptation is a key aspect of agile team behavior.

I’m not questioning whether this was the right decision or not. However, this is a classic development pattern for non-agile teams. The managers (who are the same as the development team in Shore’s case) define a marketing event as a development deadline. The developers decide to build a prototype or spike solution to minimize technical risk when developing the production code. The managers see the prototype and declare it “good enough” to serve as the foundation of the production code. At that point, the developers are pressured into creating relatively low quality code to meet the deadline. There are a few differences between the cardmeeting.com scenario and the more common scenario. First, the cardmeeting.com team apparently doesn’t have another impending marketing event so they can invest the time to pay back the technical debt. Secondly. they are a very small team with a management team (themselves) who understand the importance of paying back the debt. Most teams are not that fortunate.

I think Shore’s article describes an excellent example of what happens when agile idealism meets the everyday realities of software development. I greatly appreciate that he has written about that experience rather than quietly covering it up. What are some conclusions we might draw from that experience report?

• Agile practices slow down development. At least, it appears that the cardmeeting.com team believed this was true in the short term. I believe agility is not primarily about speed, but about the ability to effectively respond to change and uncertainty. A near term reduction in development can be a good investment for increasing long term project productivity. However, if there are near term deadlines, or a long series of near term deadlines, the forces against using agile practices can be difficult to resist.
• Paying back technical debt requires “interest” payments.. This has also been my experience. Shore isn’t very specific about what type of interest payment is required for the debt. What I’ve seen is that it’s more difficult to write tests after the production code has been written. With a small team, paying off the technical debt means that few or no new features are developed for some period of time. This can hurt the forward momentum, motivation, and focus of the developers. There’s also marketing interest to be paid. Potential customers tire of waiting for new features that important to them and lose interest or go to a competitor. It can be difficult to win back customers once they have formed a negative opinion.
• When Agility and Reality clash, bet on Reality to prevail. Yes, this will probably be a controversial statement to the extent that “Reality” is at least partially subjective. However, the reality in this situation is that a team consisting of experienced agile developers (including a coach and award winning agile thought leader) made the same non-agile choices as many teams make in similar circumstances. And they believe those choices were correct (and very well may have been). It seems to me that people who sell agile approaches often believe the reason that teams reject their suggestions is because of ignorance, stubborness, fear or something similar. Often these teams reject agile practices (at least, in the short term) for the same reason as the cardmeeting.com team. They did it intentionally and believe it was the right decision given their specific context.
• Consider timing when introducing agile practices. The cardmeeting.com team is now paying back their technical debt. They don’t have another near term deadline so this is a good time to do it. Unfortunately, for some teams, there appears to never be a right time and the debt continues to increase.

I recommend reading Shore’s original article. I’m also interested in hearing about other people views of what happens when there is apparent clash between Agility and Reality. I should also be clear that this contrast between agility and reality is not a criticism of agility, but about the more extreme forms of agile idealism. I’ve used similar comparison between reality and the prevailing development strategies on several teams to convince the management to adopt more agile behaviors rather than continuing with their current development idealism (waterfall/phasist, management by wishful thinking, or whatever).