Category Archives: post-agilism

Interesting Posts on Agile Challenges

Scrum Challenges

A couple of posts that describe how many teams are flailing and failing with Scrum:

I’ve observed similar patterns. However, my gripe with an oft-heard Agilist response: “they are failing because they just don’t get Agile” or “if Agile failed for you, it’s your (or management’s) fault” smacks of blaming the victim(s). An emerging response that I support is:

Maybe a pure form of ‘Agile’ isn’t appropriate for that team, in their context.

(Time for some Process fusion?) Philippe Kruchten has a great talk on this: Situated Agility – Context Does Matter, a Lot.

It’s also very difficult dealing with the scorched earth of a failed Scrum project after the Scrum trainers have left and the team is struggling on their own, feeling humiliated. “Are we the only ones failing? Why do we hear all these wonderful reports of how Scrum would solve all process ills? What’s wrong with us? We’re trying…” It’s hard to get them to retain the good practices they learned from Scrum and to encourage them not to throw out everything and return to a system that wasn’t working before either, but is more familiar, so it feels safer.

Rumours of Practice

TDD – more of a rumour of practice than actual practice? (much like some of what is described in the two posts above.)

Roy Osherove: Goodbye mocks, Farewell stubs

My own observations about these and other Agile practices being more of a rumour of practice than an actual practice leads me to wonder if Agile practices are another flavour of a bubble. Time will tell, but some of the behavior is troubling. It still galls me that many blindly parrot TDD as an un-alloyed good practice, instead of TDD as another tool to think about using, particularly when people might be basing their conclusions off of rumours, rather than personal experience. This irrational exhuberance is one reason why stock markets ramp up on empty speculation, real estate prices boom on over-valued properties (using mortgages that people can’t afford to pay back), and tulips are bought with abandon. (At least you can plant your tulip bulbs and enjoy beautiful flowers when the bubble bursts. What do you do with your old un-maintainable tests?)

My advice to those who may be struggling? Don’t worry about being “Agile”, (particularly if you’re trying and failing) and worry about providing value. That’s what really matters anyway. (That, and enjoying your work.) Providing value to the users of your software, and valuing the people you work with is important. Value, coupled with the skill and interest level of the team members, will trump methodology in the long run.

A Post-Agilist Concept: End Methodology Wars

One of the Post-Agile ideals I have witnessed and encourage is the breaking down of walls between methodology camps. When teams apply practices, processes, rituals and tools from Agile methodologies and create a fusion with other, compatible processes in order to create value, interesting things occur. In spite of apparent differences, many good ideas can be gleaned from dissimilar processes, and applied and adapted on your team with great effect. This paper:  Towards A Framework for Understanding the Relationships between Classical Software Engineering and Agile Methodologies expresses a Reagan-esque: “Mr. Process Zealot, tear down that wall!” ideal.

While I may not agree with all the details in the paper, it has some important concepts I want to point out. First of all, they describe the tension between Agile and phased or linear “waterfall” methodology pundits. They point out that this tension is sometimes referred to as a “methodology war” and say that this behavior is harmful to software development communities. They also find evidence of compatibilities between seemingly incompatible methodologies, and introduce an interesting analysis framework for analyzing software methodologies called “CHAPL.” (They get extra points for using a mnemonic, and for the “C” representing “contextual analysis”.)
An excerpt:

On one hand, [some] software engineers … dismiss agile methodologies and strongly advocate the value of classical [software engineering] practice, while others … insist that agile methodologies will replace Waterfall-like models and apply to all software projects. This heated debate is sometimes referred to as the “Methodology War” …
It appears that the typical characteristics of the debate are that the proponents of the conflicting methodologies:

  • describe each other in extreme and biased terms
  • devalue the opponents’ methodologies and/or practices
  • justify their own values through either experience-based explanation or inadequate comparisons between the methodologies.

We believe that this war is detrimental to [software engineering] practices. In order to end the Methodology War, some researchers have presented the similarities and compatibilities between the two methodologies.

Methodology wars are the inevitable outcome of process visionaries working against the grain to introduce new ideas, and the resistance they face from the more established process idealists. Sometimes radical behavior or extreme statements are an effective way to get attention for ideas that are dismissed. Now that Agilism has become as well known as other process communities, it’s time to stop fighting and find the areas where we agree, and try to improve how we all develop software. Instead of posturing over what process movement is “best”, let’s focus on the value we can create together.

The paper was published by APSO 2008: Scrutinizing Agile Practices, or “Shoot out at Process Corral”, In conjunction with 30th International Conference on Software Engineering, Leipzig, Germany, 10 – 18 May, 2008. Yes, I was on the program committee.

Software Development Process Fusion Part 2

What is it? The Short Version

Software development process fusion involves taking different kinds of processes and tools and utilizing a combination on your project to help you reach your goals. You aren’t just using one particular methodology or school of thought or toolset, you are using a combination of tools that fits your unique needs on your project to help create value.

What is it? The Very Long Version

In Part 1 of this series, I talked about fusion in music from early days of the genre, when it was somewhat controversial and aimed more at enthusiasts, to the present, when most music we hear on popular radio stations is a fusion of styles. On country stations, we hear rockabilly, pop, rock and roll, blues and traditional country fused together in many songs. Popular music now has influences from all kinds of cultures, and we are seeing hip hop music fused with traditional Indian music and pop. In my collection, Canadian artist Cat Jahnke includes folk, pop, rock, gospel and film music in her songwriting and performing. A more obvious fusion might be found in fellow Canadian artist Rebekah Higgs music, categorized in the “folktronica” genre, a combination of electronica music and folk. Another Canadian group with a wide variety of styles fused together is the Duhks, who “…play a blend of Canadian soul, gospel, North American folk, Brazilian samba, old time country string band, zydeco, and Irish dance music…” according to wikipedia.

These kinds of fusions of ideas are all around us. The fusions of styles from different traditions, cultures and ideas are due in part to our increasing interconnectedness and mass media and communication. In the effort to create something new in the market, we often borrow something old or unfamiliar in our culture and mix it with the current and familiar. We have fusion cuisine, for example (a Chinese restaurant near our home became an Italian restaurant and serves delicious Asian-Italian fusion cuisine). We see it in exercise with holistic training, and exercise regimes that combine eastern, western, kinesiology and spiritual elements. Often a combination of ideas helps us reach our ultimate goal, which isn’t to create a fusion of styles, or to adhere to just one style, but to achieve a desired effect or outcome.

The goal of each of these examples is quite clear. With music, the musician’s goal is to create something that resonates with them, an expression of their art and their personality. Their other goal is to produce something that is satisfactory and enjoyable for their audience. With restaurants, they want to provide fresh, delicious food. With exercise programs, the goal is better health and fitness. Another important underlying theme is financial success. We all need to make money somehow to live, and even though we may produce something that is wonderful, it may not be recognized by the market. Sometimes our goals in software development aren’t quite as clear, particularly for those of us down in the details of coding, testing, writing, etc. It can be hard to see the big picture and measure ourselves against it. It can also be hard to deal with the imprecise environment that our software is released into and instead cling to something that feels predictable and stable, like a well-defined process.

Software development process fusion involves taking different kinds of processes and tools and utilizing a combination on your project to help you reach your goals. You aren’t just using one particular methodology or school of thought or toolset, you are using a combination of tools that fits your unique needs on your project to help create value.

This paper is a recent example: Process fusion: An industrial case study on agile software product line engineering that talks about the fusion of two bodies of practice. I’d like to find more that have identified several different schools of thought: iterative and incremental, Agile, phased or “waterfall”, spiral, user experience, etc. etc.

Process Mashups

A couple of years ago, I was interviewed about post-Agilism by a company that does industry analysis of the software field. One of the interviewers used an interesting term when she described the message she got from my work. She said something like this: “We really see that teams in the future will be less dogmatic about what particular process ideology they need to follow, and will be more focused on using different ideas to get the results they need. We’ll see all sorts of interesting process mashups as people combine different process ideas on their own projects to reach their particular goals for that particular project.” Wow. She got that from my writing? “Process mashup” wasn’t a term I had used, but it’s another way of explaining what I am trying to get across.
Mashup seems to be a relatively new term that describes combining different sources into one form. Wikipedia has some different examples of mashups.

Here in Canada, a fusion of ideas is built into our culture, since our society is modeled as a “cultural mosaic” which means people retain and continue to practice their original culture when they move here to live. On CBC (Canadian Broadcasting Corporation) radio, there is an interesting show called Mashup, hosted by Geeta Nadkarni, that I enjoy listening to. The website describes the show:

Over the summer Mashup will explore what really happens when cultures intersect in love, at work and at play. You’ll hear from immigrants, second-generation Canadians, mixed-race Canadians, people who’ve been in Canada for decades – each with a personal story about how cultures collide in their daily lives. Canada is a country of mashups. People from different cultures find themselves living and working together here – bumping into different values, assumptions and different ways of doing things.

When I listen to the stories and challenges of how people overcome the collisions of culture, I see many parallels on software development teams. In fact, we tend to have our own little mishmash of cultures on our teams due to our ability to collaborate with technology, and there is often a shortage of skilled people in one particular area, so people from different countries are often on the same teams. I see this culture mashup as a more accurate description of what most teams experience and how they implement processes, so why not embrace it?

We’re Doing That Anyway

Most teams I work with tend to use a blend of process ideas in practice. Often, we like to talk about our Scrum or XP process in the pure sense on mailing lists or at conferences or user group meetings, but what we are really doing is a blend of Scrum or XP, corporate culture and practices (what we’ve learned through experience that seems to work for our project, but doesn’t necessarily fit the process literature.) Often teams apologize to me if they are doing something that isn’t by the book process-wise. I ask: “Is it working for you?” and if they say “yes”, I tell them not to worry about it.

It’s important to realize that pure “Agile” and pure “waterfall” don’t really exist on projects. They are ideals, or strawmen, depending on what your particular software religion is. (That includes my writing here, it is a model of software development that I and others find ideal. We strive towards reaching a goal of using our process to serve us, rather than working to serve the process.) There is nothing wrong with ideals, but they can be carried too far. Many feel that Royce’s original “waterfall” paper described an ideal, and that process wonks got to that diagram in Figure 2 on about the second page or so and stopped reading, adopted it on that alone and the waterfall practice was born Somewhere along the way, most teams that were focused on results figured out how to adapt their phased or “waterfall” approach to get the job done. Others got too caught up in the ideal of the process and created bureaucratic nightmares that produced more paper and procedures than working software. We see the same thing with Agile extremism – the process is held up at the expense of the people on the project who are blamed if anything goes wrong. Roles like testing and technical writing are marginalized (“there is no tester role on Agile projects”): tests are automated, and after the fact manual testing skills are marginalized as “being negative.” Testers are twisted into any role but testing, such as development or business analysis. Tests become “documentation” or “requirements” that drive development. While there’s nothing wrong with experimenting with ideas, it should not be at the cost of dehumanizing skilled people who are trying to deliver the best working software they can. What exists on most successful teams I’ve worked with, who realize that they need to reach goals for the organization, for their users, for their teams, and for each individual, is usually a combination of changing process ideas and practices at work at any given time. Some are recognizable and named, and others are just what the team does in that environment.

In the Agile world, most process adoptions tend to be a blend of Scrum and XP. Some teams I’ve worked with couldn’t do a pure implementation of either because of their unique circumstances. One team couldn’t completely adopt XP because of the physical layout of the building prevented them from arranging themselves all together. Shrinkwrap software companies often have trouble getting a real customer representative on their team, and often have a product manager, business analyst or someone with a customer-facing role stand in. Sometimes teams are successful at delivering working software in spite of process adoption limitations, and sometimes they probably aren’t. (Usually, failures I’ve witnessed are due to a lack of skills rather than a process failure.) There are a lot of perfectly good reasons why Agile process adoptions aren’t implemented in the purest sense and yet still succeed. (Hint, skill is usually a big factor.)

People have also adapted so-called “waterfall” or phased lifecycle approaches as well. Furthermore, there are different ways of viewing software development processes. Steve McConnell explains this in a comment on his blog post:

I think it’s important to remember that Waterfall and Agile aren’t the only two options. “Agile” is a very large umbrella that includes many, many practices. “Waterfall” is one specific way of approaching projects that’s in the broader family of “sequential” development practices. Staged delivery, spiral, and design to cost are three other members of the sequential family. I agree that waterfall will only rarely do better at providing predictability than agile practices will. But there are other non-Waterfall practices within the sequential family that eliminate 90%+ of the weaknesses of waterfall and that are more applicable than full-blown agile practices in many contexts. (By full blown, I mean like the project in the cautionary tale–fully iterative requirements, etc.)
…There is no One True Way. When people think about the fact that there’s software in toasters, airplanes, video games, movies, medical devices, and thousands of other places, it seems kind of obvious that the best approaches are going to arise when people pay close attention to the needs of their specific circumstances and then choose appropriate practices.

That’s contextualist thinking expressed eloquently, and is easier to hang your hat on than the: “doing what works for you” post-Agilism maxim.

Software Development Process Fusion – Know Your Goals

To get this fusion concept to work properly, it is incredibly, incredibly important to know what your goals are for providing value to your customers while building value on your teams. Otherwise, you may end up with a mishmash of watered down practices and have no way to measure whether they are helping you or not. Without an understanding of what success looks like, your team may end up with a “we’re doing what works for us” combination of process ideas that get you no further than with what you were doing before. I have seen this on countless teams adapting Agile processes. They thought adding daily standups, using iterative development, TDD, and getting rid of up-front planning and documentation was enough for success, and they ended up worse off value-wise than with a heavyweight process implementation. My response to the “We’re only adopting what works for us” concept is: a) Have you tried it? and b) If you have, can you evaluate whether it is helping your project or not? If you can answer both of those, then that phrase is completely appropriate. If not, we need to be sure we really do know what works for us and have a standard of measure to evaluate whether what we are adopting is helping us now, and if it helped us in the past, is it still helping us now? Believe it or not, sometimes the best processes can become stale and ineffective over time. Can you tell what is working on your project?

One team that I was on in the pre-Agile era was ruthless with tools and processes. Our development team lead would always say: “Does the tool suck, or do we need more practice or training with it?” whenever a tool or process wasn’t working for us as advertised. Notice the people focus – he empowered us, and made sure that we had a way to measure our tool and process adoption against our project goals. If things weren’t working, the finger was first pointed at the tool or process, not the people doing the work. We ended up with a combination of practices that evolved over time. We had clear goals on what we needed to do and what success looked like, and the following characteristics. We used :

  • an iterative and incremental delivery lifecycle
  • experimental programming/development
  • prototyping
  • strong customer involvement in planning and development
  • a strong emphasis on individuals developing their skilsl
  • frequent communication (standups, quality circles, pairing, collaborating, regular meetings with stakeholders and executives on goals and vision)
  • varied methods of developing requirements
  • varied methods of frequent testing from project beginning during the planning and idea phase, to product critiquing with serious exploratory testing on anything delivered, and at project end
  • varied automation in testing, build processes, and anything else that helped us be more productive

Anything went within reason, as long as it wasn’t unethical and didn’t hurt someone and didn’t threaten our deadlines, we were encouraged to experiment with different processes and tools in the ongoing effort to build the best software that we possibly could that not only satisfied, but impressed our user community. This was true “continuous improvement” in action. Sadly, most process ideals that I see completely miss out on most of this. They may have an iterative lifecycle, but don’t realize that the point is to help you deliver something your customer needs in stages to get their feedback, and to be able to adjust your plan as it hits the reality of the project. They do testing, but they artificially constrain it by trying to automate everything, or severely constrain requirements by forcing them into “tests”. They talk to each other, but have daily standups and iteration meetings whether they are really communicating anything useful or not.

The teams that seem to miss out on creating value over a sustained period of time are not open to ideas outside their favorite process, and belittle and marginalize people who have ideas on how to solve real problems. They look to the process to solve those tough problems, and cling to it instead of looking at the bigger picture. Successful teams I’ve worked with, on the other hand adapt, and change their process and understand that the process is yet another tool in the software toolbox to help them reach their goals. Process isn’t king – skilled people are. (Lacking in skill? Invest in skill development before worrying about your process too much.)

On that team I described above, we didn’t care what the role on the team was as long as they provided a service that helped us create value in our product. We needed people to translate requirements and product vision from something vague to something concrete that programmers could work on. We used a variety of lightweight ways to express this, and didn’t have rules about it. If it worked, it worked and we used it until it stopped working for us. The same went for testers. Those that were skilled at finding problems in designs and in the product and provided an information service were valued and encouraged, no matter what tools or processes they used. The quality of their information was what was important. No one walked around saying: “That’s not Agile!” or “That’s not [process we were using]” and discouraged you if you were doing something different. If it worked, the creativity was celebrated, not feared and driven out because it wasn’t recorded in some book somewhere. When the Agile Manifesto came out, and processes like Scrum and XP were gaining traction, we tried the ideas and adapted them to our process fusion. Processes and tools that worked were retained, and surprisingly, some practices like TDD were jettisoned over time, with a focus moving towards developing programming skills with some sort of lightweight code inspection process taking its place. We heard success stories of other teams who were doing wonders with things that had stopped working for us, and we wondered a bit why we were different, but at the end of the day, we were reaching our goals. We had stable, working software, a process that worked, satisfied customers, and a highly skilled team that valued each other and the diversity that individuals brought to it.

The Rule is There Are No Rules

I’ve seen too many process zealots or snake oil salesmen display bigotry towards others with different ideas that don’t fit their particular model. It’s easy to pick on the Agile movement because it’s a big fad right now, so there are a lot of readily available examples of people going around saying “That’s not Agile!” and creating an elitist club. Over my career, I’ve experienced people in the Object Oriented movement do this, and some RAD folks looked down their noses at one team I was on because we didn’t use the “approved” prototyping tools they used. Teams with a high level of CMM were also elitist snobs, as were some RUP practitioners, consultants and tool floggers. There are a lot of people out there who are more than happy to set an ideal standard of measure for us to live up to, make us feel guilty for our software “sins” and then profit from telling us we’re doing it wrong. A wise theologian once said something like this: “without sins the priest would be out of work.” Next time you feel you are doing something wrong, or someone else makes you feel that way, evaluate how they are profiting from making you feel that way. If you are creating value even though you’re “doing it wrong,” ignore them.

I’ve seen novel ideas to real life project problems turned aside because they didn’t follow somebody’s idea of process rules. If a pure process adoption is your goal, then you may have to do that sort of thing, but if a successful product that delivers value is your goal, following arbitrary process rules can be a real hindrance. If the software is well developed, who cares that you did some up-front planning. Who cares if you didn’t use story cards? If the team has great communication, who cares if you don’t do daily standups? If testing is done well, who cares if it isn’t completely automated? If you are good at eliciting and expressing requirements, who cares if you didn’t use ATDD or some other Agile automated test ideal? If your code is stable and maintainable, who cares that you didn’t use TDD? If you deliver value, who cares that you needed some up-front design? If your software is usable, who cares that you didn’t use BDD, but used traditional user experience techniques instead? (I’m not discouraging you from trying any of those Agile practices, indeed, try what you like as you strive to improve your process, but do it on your own terms – don’t feel pressured to try them just because it seems everyone else is doing it.)

As I mentioned earlier, we can put artificial bounds around what we do in software development, and invent rules that can impede our goals. Furthermore, rules that worked really well on some high profile project may not be appropriate for our project. Also, rigid rules can be a barrier to creativity and creating novel solutions, which are both the lifeblood of technological innovation.

My stance on all of this: if the particular process or process fusion you are using is working for you, do that. I really don’t care what it is, whether it is an Agile process, Cleanroom, RUP, Evo, some phased “waterfall” variant. If you have a bang up XP implementation that is working for you, your team and your customers, that’s great. Keep doing it. If you have a process fusion, don’t feel badly because someone says: “That isn’t Agile.” All I am encouraging is that you understand your goals, have a way to measure whether your tools and processes are helping you or not, and be open to other ideas when you need to adapt and change. Look at the history of software development and other ideas that have come before and try to learn from as many different sources as possible. Enlarge your software development process toolbox, and try combinations of ideas. Others have done this before, so it isn’t really that radical. Google the term for more ideas.

Agilism all too often ends up people being much more concerned with following “the rules” instead of being concerned with providing value and reaching goals. Merely following a good process in the hopes that all those tough problems will be solved by strict adherence to that process may not work for you. There is a difference between understanding what you need to do, and adapting as you go, and merely following a ritual without understanding the meaning behind it.

What Process Combinations Have Your Teams Created?

I see this sort of thing as having a future in software development processes partly because successful teams I’ve worked on have always changed and adapted not only their plans, designs and their code, but their tools and processes as well. We’ve also seen a fusion of ideas become popular in other areas, and it seems like a natural evolution. First we work through various extremes, and then we find some sort of balance. I’d like to hear about the combinations and adaptation of processes on your team. One day I hope to hear of a team that says: “We created a process mashup like this: we learned how to measure performance requirements of our development efforts and software inspection from Evo, iteration planning and management from Scrum, continuous integration from XP, persona creation from the user experience world, user testing from Cleanroom, and a large variety of testing ideas from various schools of thought in testing, combined with this other stuff we do on our teams that isn’t written down in a book or talked about by experts.” Most importantly, what are you doing to create value for your customers and your team? Are you using a purist implementation of a process, or are you combining different process aspects to reach your goals?

Software Development Process Fusion – Part 1

I first brought this idea up publicly last year at the Agile Vancouver conference with a promise that I would share more of my thoughts. What follows is an attempt to fulfill that promise. This has turned out to be rather long, so it will appear as a blog series.

I grew up in an environment with a lot of music. My grandfather had a rare mastery over a wide variety of musical instruments, and family gatherings were full of singing and impromptu jams. At home, my father had a very eclectic taste in music, and I had a steady diet of gospel, classical, big band, bluegrass, traditional German and Celtic music. One of my babysitters had spent most of her life in India, and introduced me to all kinds of wonderful forms of Indian classical music when I was very small. I was exposed to popular music on the radio, and I took part in various music groups in school bands, choirs and at church. By the time I was in high school, I had a wide exposure to many different kinds of music, and enjoyed any sort of music that moved me, no matter what the style. I could enjoy a common thread in music that was composed and performed in a way that appealed to me, even if the styles were very different. In some cases, my classical friends couldn’t stand some of the popular music I enjoyed, and some of my gospel music friends would refuse to listen to secular music. Enjoying a wide variety of music styles could be controversial, depending on who I was talking to.

In the late 80s, I was in a choir that was in a competition in Toronto. I was billeted with a family who introduced me to a Canadian band called “Manteca.” My new friends introduced me to a style of music called “fusion,” and Manteca were well-known for their mastery of that style. There were elements of improvisational jazz, popular music and world music in their work. Because of Manteca, I decided to learn more about the history of this style. It didn’t take long before I discovered Miles Davis recordings from the ’60s and ’70s that pioneered a combination of musical styles. I then checked out work by Larry Coryell, and jazzy popular bands like Chicago and Blood Sweat & Tears. From Miles Davis, I followed some of his former band members works such as John McLaughlin, Herbie Hancock, Chick Corea and Joe Zawinul. I also checked out groups like the Crusaders, Weather Report and anything with bassist Jaco Pastorius. Some of the music was highly experimental, sometimes it was hard to listen to. One of my favorite bands in that style was Mahavishnu Orchestra, founded by wizard guitarist John McLaughlin. McLaughlin also founded a band called Shakti that utilized a different style of fusion. Shakti was a highly improvisational band utilizing master musicians from India, and McLaughlin on guitar.

From this musical journey, I discovered progressive music from the ’70s, with bands like Yes, King Crimson, Emerson Lake and Palmer, and Genesis. These were all groups with highly talented musicians who brought other musical styles into popular music forms. As with fusion, this style of music was highly experimental – some of it made popular charts, and others remained obscure. What these styles of music share is a demanding level of skill for the performers, an experimental, pushing the envelope attitude, often utilizing collective improvisation (particularly in live concerts.) They were also controversial when they first came out, but many “wild in their time” elements have become enmeshed in mainstream music today. However, in the pioneering days of fusion, it was not uncommon for critics to pan albums and for purists to cry fowl.

One musician who has had an enormous influence on popular music is former Genesis front-man Peter Gabriel. By the late 1990s, the style of music that Peter Gabriel made accessible to a huge audience in the 1980s emanated from airwaves and stereos everywhere you went. I heard Jesse Cook talk (a guitarist who fuses flamenco guitar with many different styles) about the impact Peter Gabriel has had on modern music, particularly with his ability to fuse popular music with traditional music from other parts of the world (“world music”.) Jesse Cook mused at the time that anything we heard on the radio could probably be traced back to Gabriel. When we were discussing the different styles that had an impact on everyday popular music, we wondered what it was like for the musical pioneers when their ideas were new, and how little most of us know about the history of music we take for granted.

I still listen to music that combines different styles. One of my recent discoveries is Harry Manx, a blues guitarist who plays slide guitar on a Mohan Vina, an Indian slide guitar. He deftly fuses traditional Indian music with traditional blues. I find that I am moved by too many styles of music to merely just choose one, and sometimes the weird combinations do something for me that just one style on its own can’t do. I still love classical music, and find that a particular period or style of music suits my mood. Music can touch us in ways other things can’t. Music also evolves, and musicians draw on many influences – yesterday’s “pure” style becomes influenced by something else, and we co-opt other ideas and change. I suppose we expect that in the arts. For example, the Canadian artist Emily Carr’s work is called “post-impressionist” because she came after the famous impressionist painters, and developed a unique style that doesn’t quite fit in that category. Like the fusion musicians, Carr’s artistry has many influences and changed a good deal over her life. Carr had a special ability to fuse disparate themes together in a painting. She might combine everyday objects we might see in our homes with a nature scene, or combine two different scenes together.

In software development, we don’t have a long and rich history to draw from like our artistic counterparts. That doesn’t stop me from approaching software development from the same angle as I do anything else though. Brian Marick in his “Process and Personality” article says: “…my methodological prescriptions and approach match my personality.” This is also true with me. I like to fuse different ideas together and see if I can create something new from the combination. There may be stark lines drawn between the fields where the ideas come from, but that doesn’t bother me too much. It gets me into trouble sometimes, but the ideas are what are important to me. When it comes to software development, I don’t really care if an idea is “Agile”, “waterfall” or has no label at all. If it’s a good idea to me, it’s a good idea. Sometimes on software development projects, I weave together combinations of these ideas in a way that may seem strange to some. I’ve started calling this style that I and others are exploring: “software development process fusion.”

Post-Agilism Frequently Asked Questions

Edit: Update – Jason Gorman weighs in with his thoughts in: Post-Agilism Explained.

What is Post-Agilism?

This requires a two part answer. Post-Agilism is:

  1. a growing movement of former Agilists who have moved beyond Agile methods, using a wide variety of software development tools and methodologies in their work.
  2. an emerging era. Now that the Agile movement has moved to the mainstream, what’s next?

Why Another Term?

I didn’t know of any other way to describe people who went through the Agile movement, and after a while decided they didn’t identify with being “Agile” anymore. They weren’t reversing back to big-up-front design, heavyweight processes, and were building on what they found effective in Agile methods.

“Post-Agilism” is a term I use that helps my thinking with this phenomenon. Some of the behavior is a reaction to dogmatic zealotry, like philosophical skepticism. For some reason, the term “religion” comes up an awful lot when “Agilism” is discussed, as described by Ravi Mohan, and Aaron West.

I’ve also seen behavior towards processes that is like scientific skepticism, or what might be better described as falliblism, that seeks to question process claims through investigation and scrutiny. That’s the “process skepticism” side. “Does this process ‘X’, as one of many tools we can use help us reach our goals of satisfying and impressing the customer? If not, why? What can we try that might work better?” I originally blogged the neologism “post-Agilism” in the hopes that it would help spur people to try out new ideas, and encourage those who were tired of Agile methods and wanted to build on them and move forward.

Jason Gorman and I both independently thought of the term “post-Agilism” because we were afraid that the industry would stop innovating. We both felt stuck in the “Agile” rut, and knew others who had worked through the Agile movement, and then said: “That was fun. Some things worked well, others not so well. What’s next?” This is sometimes the curse of the early adopter. What do you do after “Agile”, particularly when you feel that the innovation that the Agile movement injected into the software development world has slowed down, or maybe even stopped?

Gorman and I both came to use the term by looking at modernism vs. post-modernism in areas like architecture and art. Agile to us felt like modernism in architecture and art. Progressive, but with rules around the values and frameworks of implementation. There was this other thing going on though, where the rules of Agile were broken, and people created hybrids, or mashups of processes. This sounded more like the freewheeling, anything goes values of post-modernism. Hence the term: “post-Agilism.”

Isn’t the term “post-Agile” an oxymoron, or a fallacy?

It is if you use the dictionary definition of “agile”, but Brian Marick explains the difference of meaning of “Agile” (capital-A) quite well here:

It really gripes me when people argue that their particular approach is “agile” because it matches the dictionary definition of the word, that being “characterized by quickness, lightness, and ease of movement; nimble.” While I like the word “agile” as a token naming what we do, I was there when it was coined. It was not meant to be an essential definition. It was explicitly conceived of as a marketing term: to be evocative, to be less dismissable than “lightweight” (the previous common term).

…That’s why I habitually capitalize the “agile” in Agile testing, etc. It doesn’t mean “nimble” any more than Bill Smith means “a metalworker with a hooked blade and a long handle.

Note: I consider Brian to be one of the good guys – he is not an Agile marketer, but someone who is highly skilled at what he does, and is dedicated to driving the craft of software development forward. He has had an enormous influence on my career – Brian encouraged my exploratory testing efforts on Agile teams in particular. If you haven’t read his work, you should check it out on www.testing.com and www.exampler.com. From what I understand, Brian is as against the hype and dogma as we are, if not more so.

Jason Gorman explains further:

Adapting to circumstances is an agile strategy that can significantly improve our chances of success. But post-Agilism – [Agile] with a capital ‘A’ – is not about strategies. It’s about hype and it’s about dogma, and how they can – and, let’s face it, actually have – put a choke-hold on genuine innovation within the Agile community over the last few years. This is not what the Agile pioneers envisaged, I suspect. …I remain staunchly post-Agile, and see no fallacy in remaining decidely agile to boot! Just because you don’t like Big Macs, it doesn’t mean you hate beef burgers…

Is Post-Agilism Anti-Agile?

No. In fact, it can help preserve good practices that were popularized by the Agile movement in the face of a backlash. It’s better to think of it in terms of “after Agile” rather than “against Agile”. As Jared Quinert says:

When I started referring to you and others as ‘post Agile’, I used it to mean that you were the people whose thinking had moved on, that you were thinking about software development after Agile, and were reacting to stagnation. Some were uncomfortable of acceptance of Agile as an unquestionable best practice, not a solution to specific problems, or a set of principles which may or may not help your unique project.

Some people have expressed fear of returning to waterfall or phased approaches. This is a fear I share, and post-Agilism is a potential way out of that seemingly binary choice between Agile methodologies and big design up front, heavyweight processes. There are more than just those two choices, and in companies that have been burned by bad Agile implementations, it is tempting for them to throw the baby out with the bathwater. Post Agilism is one of many ideas to help counter that. Take the good, move forward and improve, don’t go back to the processes that weren’t working before just because you’ve had problems.

This thought of “after-Agile” isn’t so much a threat to Agile practices as an assimilation of them, combined with other ideas. Jason Gorman:

Those of us who consider ourselves “Post-Agilists” have taken what worked and cross-bred it with the best bits of dozens of other approaches and disciplines, creating new variants that have the potential to be even more exciting, daring and shocking.

I’ve heard post-Agilism referred to as a “process mashup” by others.

Post-Agilists aren’t necessarily “anti-Agile”, in fact they tend to incorporate a lot of Agile practices on projects, as well as other practices they find useful. Jason Gorman:

The Agile movement has successfully challenged the existing order and shaken the software industry out of a potential rut, bogged down by outmoded 19th century industrial thinking and “big process” dogma. It has opened the door to a very wide range of possibilities, and is now the catalyst for a Cambrian explosion of new ideas on how to deliver software and systems with bizarre, exotic-sounding names like Pliant Programming and Nonlinear Management.

Is Post-Agilism Superior to Agilism?

No – this isn’t about value judgments or superiority. Post-Agilism is a descriptor of something that we have seen and experienced. I’m personally not saying one thing is better than the other. I’m just saying people have moved on from Agilism for whatever reason. Who knows what the future will bring, and what will be remembered as being successful or “good” or “bad”. I’m ambivalent about it, but it is not a movement I started, people were displaying this kind of behavior long before I identified with it. I don’t think everything post-modernism brought us was necessarily good, but I like the fact that it added more ideas to the mix. Jared Quinert expresses ambivalence about the term: Maybe we are in “late agilism”. … “It’s bound to be renamed by someone else one day anyway.” We can be as wrong about any topic as anyone else.

Isn’t This Really Just “Pure Agile”? Aren’t You Just Reacting to Agile Corruption?

No, we are reacting and adapting to experience on our own projects, and to change. Furthermore, post-agile thinkers I’ve spoken to tend to be contextualists who, like the Context Driven Testing community, believe the value of a practice depends on its context.

Ravi Mohan:

…each agile practice (or the whole lot together with an appropriate label) makes sense only in certain contexts (certain types of enterprise software, with certain types of teams) even in the “uncorrupted”, “pure” state. A “pure agile” process is not superior to a “non agile” process de facto. Agile is not the “best way we know how to create software”.  It is one way we know how to create software. It has no intrinsic superiority (except against obvious straw men like “pure waterfall” for projects with rapidly changing requirements). “Post Agile” is just an adjective that describes people who have used agile extensively, adopted what made sense, rejected the parts that didn’t work (and the hype) and choose to think for themselves. It is not a reaction against the perceived corruption of an originally perfect process. (From comments on Vlad Levin’s blog.)

A popular misconception is that if you are using an iterative lifecycle with incremental delivery, focus on communication, customer involvement, value testing, and delivering great software, then you are, by definition “Agile.” The Agile movement did not create these practices, (nor do prominent Agilist founders claim to have invented them) and it does not have sole ownership of them. Many of us were doing these things on projects in the pre-Agile era. In my own experience, I was on teams that used iterative lifecycles with two week iterations in the late ’90s. We looked at Rapid Application Development and adopted some of those practices, and retained what worked. We also looked at RUP, and did the same thing, and a big influence at that time was the Open Source movement. If you go back to the ’60s, thirty-forty years before the Agile Manifesto was created, Jerry Weinberg describes something very similar to extreme programming on the Mercury project. That doesn’t mean the Agile movement is wrong, it just shows that there are other schools of thought other than Agile when it comes to iterative, incremental development.

The Agile movement did not invent these practices – they’ve been around for a long time. Some of us were very excited about what the Agile movement brought to the industry, because we had also been working in that direction. What the Agile movement gave to us was a shared language, a set of tools and practices and advances in these techniques that can be very useful. The Agile movement has given us a lot of innovative ideas, but we can look at pre-Agile and Agile eras for great ideas and inspiration.

Another reason that some react negatively to the Agile movement as a whole is the “higher purpose” vibe that seems to emanate from Agilist gatherings. Michael Feathers put words to this, he described it as a “utopian undercurrent”, which is a brilliant and appropriate use of languge in this case. On the Agile Forums, Micheal Feathers said this on a thread:

… I think that there has been an undercurrent of utopianism in the agile community: “If only we get software development right, our businesses will succeed and the the death march will be relegated to the scrapheap of history.” As much as I’d like to believe that emotionally, I recognize that there is enough flux in an economy to make those sorts of states intermittent and somewhat unpredictable. There will be times when a team will be perfectly aligned with the surrounding organization, when the code will fly out of the finger tips and everyone will be happy. But, in general, organizations often act badly under stress. Projects can fail for reasons totally unrelated to a team’s performance.

This is an important insight. Tim Beck responds to a thread series on the Agile Forums where Brian Marick says:

Whereas the number of people new to Agile who describe their project as “the best project I’ve ever worked on” seems to be declining, and we believe work should be joyful…

Tim says:

I could be my typical snide and sarcastic self and say something in mock shock and awe, but I’m going to resist this time and actually applaud this important recognition. Agile isn’t all it is cracked up to be. It doesn’t always produce successful projects. It doesn’t always produce happy programmers. It doesn’t always produce delighted customers. The sooner we realize this, the sooner we can move on, or in the case of the Agile Alliance, the sooner they can attempt to patch up the beast.

Tim and I both agree with Brian that work should be joyful, that you should be able to enjoy what you are doing. Tim’s point is that just because your team is Agile, it doesn’t mean that you are guaranteed to have joyful a work environment. In fact, some Agile projects are as political, soul-crushing and demoralizing as any other project. It can be annoying to deal with that utopian undercurrent, particularly when people refuse to deal with issues because “we’re Agile!” – preferring an ideal over reality. Brian’s point is an important one to look into. Why does it look like this has changed over time? What is the real problem?

Won’t This Cause Harm to Agile Methods?

The value of Agile methods can stand on their own. Post-Agilism is just a term to clarify why some people choose to use Agile methods, and move on. There are still a lot of people who are perfectly happy with Agile methods. We are just reminding people that there are alternatives.

I’ve found the term has helped drive out confusion over mainstream Agile views, and this other group of activities that were similar, but didn’t really fit. If others find the term confusing and use it as an excuse to not even try Agile methods, that is their choice. They would probably find a different excuse if this term wasn’t around. If they are serious about trying Agile methods, this term should merely tell them that they are already behind the curve, and should hurry up learning something new in the hopes of improving.

One thing I have noticed is that Agilists are now looking at defending some of their positions, and looking for evidence to back up claims. I think that’s great. A little healthy skepticism and introspection can make good things stronger, and weed out practices that aren’t so good. If the term “post Agilism” helps people improve their work by making it defensible, that’s a good thing. Some of the criticism and skepticism is helping Agile practitioners improve their own work.

I also have trouble making a value judgment on behavior and activity that is going on as time passes and people embrace Agile methods, adapt, and some move away from that school of thought. It’s a descriptor, not a call to arms. The market will reward and punish our ideas over time. New ideas and experimentation aren’t bad things to me – stifling innovation is. One of the gifts the Agile movement gave us was an escape from the rut software development had fallen into. One of the dangers is apathy and complacency if Agile methods are touted as “the best way to develop software.” If we are already the best, why improve?

Where is the Post-Agile Manifesto?

There is no manifesto. This is not an organized group – it is a phenomenon of people around the world who have some sort of Agile experience, and have independently moved on. We are now discovering that there are more people doing this. Most post-Agilists I’ve talked to still value the points in the Agile Manifesto – they see it as a good start, but not the final answer. Furthermore, the Agile Manifesto is a bit like world peace. It is difficult to disagree with, but many disagree on implementations. Post-Agilists seem to want to expand the idea space on what those kinds of implementations might be.

What’s The Formula? Can I Buy the Process?

There is no formula. Software development is a complex business, with many factors. We’ve spent a lot of good effort in methodologies and tools, but there are many more variables to be aware of. Tools and processes are important, but it’s up to you to find out which ones work for you, in your context. I echo the Pragmatic Programmer’s advice for learning a new programming language every year, and Alistair Cockburn’s advice to try out and learn a new process frequently. Grow your toolbox. Focus on what goals the business is trying to achieve, and see how your technology, process and tool decisions help reach those goals – not the other way around.

Tim Beck has one way of putting this:

I’ve said it before and I’ll say it again… I don’t know how you should build your software. No one but you can figure that out.

Isn’t Post Agilism Going to be Corrupted Too?

I hope the post-Agilism movement is a transitional movement that gets us back to worrying about good software development, instead of worrying about what pure “Agile”, “waterfall”, “RUP”,”CMM” et al “recommend” we do. Sometimes I’m not sure if post-Agilism is a movement as much as a phase. I started seeing post-Agilist behavior in about 2003, and it has grown organically without having founders, a manifesto or group of values to shepherd it. I’d rather characterize post-Agilism as a descriptor of something we see, rather than a goal we want to attain. If we see people who are fluent in Agile methods, but also draw from many other sources as they strive to develop the best software they can, we might say: “Look, there, that is post-Agilism in action.”

However, now that the cat is out of the bag, people will do whatever they want with the terminology. I’ve heard of Agilist marketers complaining that “Agile” is no longer a differentiator for them in the market. (Sometimes I wonder if there are there any software companies left that don’t call themselves “Agile”.) I imagine if the “Agile” branding devolution continues, someone is going to use “post-Agilism”, or some other term to fill the void in a similar way, along with other “new” ideas. The abuse will begin, the reactions will begin, and hopefully we just move beyond it, and forget about terminology and focus on building great software. It’s just the way of the world – people need to make money somehow, and time marches on.

What Does Post-Agilism Look Like?

Kathy Sierra was one of the first people to raise this issue. It’s a good one. My first answer was: “Let’s all find out together.” I still believe that, and while I have more experience and ideas now, I’m more interested in what you think. What are you, the reader doing or observing that looks like post-Agilism? What do you think it looks like and means? What creative combinations and cool amalgamations are you using as you experiment to improve your software development efforts?

James Bach has said this about post-Agilism:

It’s not a declaration of a new world order, it’s a transitional strategy on the part of and for the benefit of people who feel that Agile has lost its way.

Jason Gorman says: Post-Agilism is simply doing what works for you.

There are a lot of ways that people have moved on from Agilism and are doing something new. A common theme is to look at processes as a constantly evolving set of tools that need to be adapted to reach the goals of the software team and the business. This is often a fluid combination that extends beyond popular Agile definitions. For example, Alistair Cockburn was recently interviewed on “What’s Agile and What’s Not“. The answers are interesting. I particularly like his top ten list for figuring out whether your team is Agile or not. From a software development perspective it is fairly narrow, which makes it easier to decide whether you are Agile or not. Where it gets interesting, particularly when it comes to testing, is in point number 6. The “Agile Testing” view of testing is obsessed with automated testing, and it can be difficult to introduce other kinds of testing ideas in that community.

Back in the old days (for me circa 2001-2003) on Agile teams, if you were on an XP team, you could expect that kind of thinking on testing, but on other Agile projects, you had a lot more freedom to experiment to see what worked or not. That freedom to experiment as a tester on Agile teams is disappearing. Now what I see is an obsession with automating basic functional tests, that have to be “test-first”, which takes me back to the dark ages of testing where we pre-scripted all tests. That didn’t work so well, because we were only using confirmatory tests, and it forced testing to be predictive rather than adaptive. On Agile teams in the old days, I wasn’t so constrained, and it was nice to be able to have the freedom to be an investigative tester rather than just be a rubber stamp.

Nowadays, it seems testing ideas on most Agile teams I encounter are obsessed with automated unit testing, and are often forcing FIT way beyond its capabilities to meet some functional or acceptance test-first ideal, and the resulting maintenance issues that come along with it. (It’s not uncommon to see the top programmers spending all their time trying to get the FIT tests to work while the other programmers, business analysts and testers wait, sometimes for days on end for them to get their FIT infrastructure to work so they can write the code to satisfy the story.) One colleague of mine waited over a week for one report to be added to a system, 7.5 days were spent getting FIT to once again work with their system, and the other half day involved writing the story, and the actual program code. They remarked that this must be “test-dragging development”; at first, it was quite seamless and efficient, but as time went on, the maintenance costs of the automated tests were prohibitive.

There is some hope however, as exploratory testing seems to be gaining some currency in the Agile community. Most of the time though it feels like the Agile Testing ideals of “test-first” and “100% automation” win out, even if you have to force testing into a narrow definition to do it. That’s fine if that’s what you want to do in testing, but for some of us, that isn’t the be all and end all for testing. We see those ideals as part of a possible testing strategy. There are other examples other than testing where this stagnation, or narrowing of definitions of activities are taking hold in Agilism.

“Post-Agilism” is a term that gives permission to those who feel they are in the stranglehold of Agilism to move on and follow something that doesn’t seem to have currency in that community. It reminds them that there is more to software development than just the Agile movement.

Here are some other thoughts from around the web:
From the Software Underbelly blog: Post-Agilism:

Well, Halleluiah, I found some people talking about something other than following this ridiculous religion of Agilism. They saved me from one of my biggest rants. The original purpose of this column was to lambaste all the dogma drenched blather of Agilism. The loudest nails on the chalkboard for me was this attitude that process was EITHER predictive OR adaptive, i.e. my way or the highway.

…with Post-Agilism we take the good ideas but get back to looking at what works in a particular environment. I have always preached that good process is not from a book but an evolution. You design a process at the beginning as best you can and then continually adapt it as you go through releases. The process defined at the beginning is not nearly as important as how the evolution of that process proceeds from that moment forward.

Some people think that Lean is Post-Agile:

The Agile movement has given us some big advances, and also some big distractions. The good news is that we are perfectly free to toss out the distractions and substitute something better.

I’m personally not a big fan of Lean in software development, but he makes some interesting points.

This post “being agile in methodology” underlines what Post-Agilism can mean:

So, when are you using Scrum as methodology? In my project, we use lots of scrummish terms and tools, but for us being agile is also being agile in process. Why use the waterfall methodology when it comes to process? Why should we stick to tools we don’t find comfortable? We don’t. Our guideline is make it work for our team and our project. But when have we wandered so far of the beaten path that we no longer can call the methodology Scrum? Let’s wait ten years and see what it is called.It is good to know that we are not alone in this process, it actually has a name (though scorned by my team members) it is called post-agile…

In another example, Tim Beck decided to found the Pliant Alliance. Tim says:

Post-agilism to me is the more general description for what I did in founding the pliantalliance.org. I moved past Agile and started to think about what was good about it and what wasn’t. I started encouraging others to do the same. It turns out that I wasn’t the only one doing this and Jonathan came along and coined the term ‘post-agilism’ to describe what we all were doing.

What is Pre-Agilism? Isn’t that just waterfall?

Pre-Agilism is the period of time before the Agile movement was founded. This gets a little tricky though, because the Agile Manifesto signatories were also commentating on something they were witnessing and experiencing. Practices that were started prior to the “Agile” term creation were included under that umbrella. However, there are a lot of areas over the history of software development we can draw from.

Prior to the Agile movement, there were projects that used iterative lifecycles, were concerned with testing, customer involvement, and things of that nature. When I first read Martin Fowler’s The New Methodology, when I saw the first section “From Nothing, to Monumental, to Agile”, I interpreted that as describing the mainstream. There have long been projects and development ideas that rejected heavyweight, waterfall approaches, even when a phased “waterfall” approach was the dominant theory. I was on some of them in the late ’90s. We looked to the Open Source and Free Software communities as well as thinkers like Barry Boehm, Jerry Weinberg, Tom DeMarco, Tim Lister, Alan Cooper and others (including influential testing thinker James Bach) for ideas and inspiration.

That was an exciting time, and the Agile movement emerged as a dominating force in the iterative vs. waterfall debate. There were a lot of ideas that were experimented with and talked about in the fringes at that time. Some of the most influential for me were the usability and context-driven testing ideas. Going back further, there are classics on computer science that still have relevant lessons for us today.

There were also many who were using textbook waterfall phased approaches that were heavyweight. That was certainly a dominant thought in the late ’90s when I entered the game. The Agile movement was a breath of fresh air for people in those kinds of projects, and provided some great tools for dealing with this, particularly when it just wasn’t working. Here was an alternative that had a lot of credibility.

Why Aren’t You More Clear About This? Where Are the Examples?

I’ve held back a bit deliberately on my own ideas and examples because I wanted to see more ideas come to the fore. This is occurring slowly. I’ll add more on how I view software development and a post-Agile example or two in time.

What Do You Hope to Achieve?

With Post-Agilism, I just shared an idea I used to help reconcile something I was seeing happening, and experiencing myself. Others have found the term resonated with them, and they identified with what I was saying. Many have said they did find it encouraging. That continues to be a goal, to encourage those who want to improve software development in general, whether they are Agilists, post-agilists, or (insert fancy term here)-ists.

Others have reacted negatively to the term, and have started debating the value of it, as well as the value of the methods they believe in. I think that debate and communication of ideas is a wonderful thing. I hope we hear more about software development process and tool failures, not so much to say “I told you so!” or poke fun, but so that we all can learn.

This is what I mean by learning from mistakes. I have friends who are pilots. Any air accident is shared across the industry, and they openly share problems. In fact, they have to. One of my pilot friends told me that they are able to innovate because they focus on problems, and how to eliminate them and improve on them. One of my pilot friends said that this is part of the lifeblood of innovation in the aircraft industry. In software, we often downplay the problems, and vilify people who bring them to the forefront. We can learn a lot from our mistakes, and collectively move forward and innovate by looking at areas where we are weak. If this term helps spark some useful debate, collaboration and knowledge sharing to help us overcome areas we are weak in, I think that would be great.

At the end of the day, Post-Agilism is just an idea, or a model that some of us find helpful right now. Don’t find it helpful? Don’t worry about it. We aren’t trying to change minds, we’re just trying to get people to think about what they are doing. If Agilism works for you, great! If something else does, that’s great too. There are a lot of good ideas to choose from, particularly if you expand your view.

Maybe one day, we’ll just get back to calling all of this “software development” and we’ll pick and choose the right tools for the job to help us reach out goals. We don’t have to pick sides – there are great ideas to be found from all kinds of sources that we can learn from and try.

Responses to The Agile Backlash

Here are some reactions to the Agile Backlash post:
Tim Beck weighs in:

In the end, I firmly believe (and I think Jonathan does too) that the “Agile or not” debate is moot. There is a post-agilism movement coming (or already here) and we are going to have to deal with it. The software world is changing (did it ever stop) and if you don’t adapt to the world you’ll get left behind.

As Tim knows, “post-agilism” is a descriptive term of a growing community I have observed over the past couple of years. I am not trying to found a movement, there is no manifesto, and I’m not selling a process. “Post-agilism” is a term I used to describe the growing group of practitioners who agree with the Agile Manifesto, but don’t consider themselves to be “Agile” anymore. I struggled with this for a while, and I find the term helpful for my own thinking. It was difficult to square the Agile movement on one hand, and this group of practitioners I kept meeting who just didn’t fit. Others have described a watershed moment when they read the term. “That describes me! I’m not alone!”

Jason Gorman is on the money:

I’m saying that I completely believe in iterative and incremental, feedback-driven delivery of working software. This is based not only on experience, but also on some simple maths that shows me that the evolutionary approach is nearly always better and never worse than single-step delivery (“waterfall”).

But I’m not saying that because it’s written in a book or on a web site. And that’s what makes me post-Agile, I guess.

A reader emailed me:

This is the most balanced Agile piece I remember you writing, the most balanced IT piece overall. The focus has moved from just Agile to software development, which is where I wish the industry focus would move.

Another reader emails:

All the religious hype really gets up my nose, and I just want to get on with the business of developing software the best way we know how, and thinking about all the ways we can do it better.”

Another reader says:

I’m not yet ready to abandon the term “Agile” to those who invoke it in name only. I’d rather shine the light of day on this practice. But whatever name you use, keep up the good fight.

This is exactly the kind of thing I like to see from Agilists.”I’m not ready to abandon the term. If you are, fine, but I’m going to work on improving things from within the community than from without.”

Chris McMahon expands on the skill component:

Skill of course is critically important. (The Economist had an article a couple of weeks ago pointing out that even while companies are outsourcing function to India and China, they are desperate for talent, and will hire talented employees anywhere in the world they find them.)

Other *human* attributes are also critically important.

Matt Heusser posts:

I see a lot of “Agile” process zealots. I don’t get it. One of the points of the manifesto is to focus on individuals and interactions over process and tools, and yet people keep selling methodologies and tools. I suppose that’s because it’s easy to sell. I intend to propose a session at the Agile Conference 2007 to discuss this.

Oddly enough, the term “post-agilism” came to my mind after talking with Matt over a year ago, after we both did keynotes at a conference. Matt was wondering whether the Agile movement was an example of a type of post-modernism. I thought about it for a couple of months, but there was this growing group of people I met that didn’t fit that seemed to be more like post-modernists than the Agilists I was observing.

I also felt conflicted. I liked the Agile Manifesto, and the values of XP, but I didn’t consider myself an Agilist anymore. I had been on teams that practiced evolutionary design and development before the “Agile” term was formed, and I just didn’t relate to the Agile movement anymore. I felt it had stopped innovating. I wasn’t alone. Across the pond, at approximately the same time I was thinking of these things, Jason Gorman was thinking the exact same thing. Jason expressed the post-modernism angle much better than I could. (Note: please work to prove us wrong.)

Matt has jumped ahead with this idea of Post Modern Software Development , and is talking about Perils and Pitfalls of Agile Development. Keep pushing the envelope Matt!

As Tim Beck says, there is an Agile backlash which is already taking place in some communities, or is on its way. Our choice is to either deal with it in a healthy way, or get swept aside when the charlatans jump on the next fad tool or process they can sell to the unwitting.

Another reader commented:

Agile is yesterday’s silver bullet.

This is an interesting point, with potentially serious implications. If “Agile” is perceived by some to be a silver bullet, we are going to have to fight to keep the good things the Agile movement popularized from getting thrown out with the bad.

One reader said to me: “This is great! There is nothing better to improve the Agile movement or help create something new than to speak from the heart and buck the groupthink and hype with thoughtful introspection and constructive criticism. Furthermore, dealing with a backlash in a healthy way is extremely important.” This reader then told me a story of a company he had dealt with that used an Agile consultancy for a project. The project failed, so management banned anything that could be associated with “Agile”. What that meant was that there was a ban imposed on anything that used an iterative life cycle, and incremental, evolutionary design and delivery. This is exactly the kind of reaction we don’t want to see. Instead of building on what worked and improving, they have taken software development back into the dark ages in that company. My reader went on: “This isn’t the only company I’ve seen do this – throwing out “Agile” and returning to big up-front design. I wish more people understood that there is a better way, and I think what you are doing sheds light on that. This can help us improve.”

My hope with the Agile Backlash post is to let people know there is a better way.

The Agile Backlash

Now that the Agile movement is making it into the mainstream, and gaining popularity, it is facing a backlash. Aside from the mainstream pro-Agile trend we hear so much about, I see three reactive trends: rejection by non-practitioners, a mandated reversal in corporate methodology focus, and an adaptive reaction that builds on good software development ideas and practices.

A Source of Division

Sadly, the Agile movement is creating a lot of division in the software development world. A stark division is drawn between Agile practitioners, and those who aren’t “Agile”, therefore to the Agilists, they are “waterfall”, and by default, inferior. This attitude ranges from the relatively harmless, yet tasteless “Waterfall 2006” conference parody set up by well-known Agilists, to companies being torn apart from within as factions rage against each other, grappling for methodology dominance.

I get emails from people all over the world sharing with me the trouble they are now facing. Instead of collaborative, enabling Agilists trying to help a team do better, they are faced with zealous naysayers who try to force process change. One correspondent mentioned that they were fearful of the Agile process evangelists in the company, and other staff were avoiding them. They were tired of being berated for not knowing the Agile lingo, and being belittled as “waterfall”, and “backward” when they would ask innocent questions. The Agile zealots in their company had taken to yelling at the other team members if they did something that was “un-Agile”. They expressed that the team was reasonably cohesive and productive in the past, but now that a couple of team members had bought into the Agile movement, they were disruptive. Obviously, this is behavior that is completely against the values of any Agile methodology I’ve come across. Sadly, the divisive, belittling behavior of some Agile zealots is painting the entire community that way. Some managers are dealing with this situation by removing the people that are disruptive, and fearfully avoiding the Agile processes as a result.

Martin Fowler has aptly described this kind of behavior as “Agile Imposition“. For the reverse of what I described above, read Fowler’s post where he describes “Agile” being imposed on a team by management whether they want it or not.

Another divisive issue is economically-based. It’s important to realize that there are people and companies that are now making a lot of money from Agile processes. Some have told me that they are in danger of losing a customer, because the customer is suddenly concerned that they aren’t “Agile”. The customer is happy with the product or service, but a potential competitor has come along, is using “Agile” as a differentiator, and is trying to use it as a wedge to try to steal away a customer. Some companies react by branding themselves as “Agile”, without altering much of what they are doing. A little lingo adjustment, and some marketing makes short work of the differentiator their potential competitor is trying to use. Unfortunately, this waters down what Agility is supposed to be about. In some communities, you would be hard-pressed to find a company that deals in software development who doesn’t call themselves “Agile”, when few of them are actually using a methodology like XP, Scrum, Crystal, Evo, Feature Driven Development, etc. As people who call themselves “Agile” create messes and some project disasters become known through the local community, the shine certainly wears off.

Other companies react in a more healthy manner. What is this “Agile” fuss? Is it something we need to look at? One person told me that after reading my recent writing that displays some skepticism of Agile methodologies, they realized why they do what they do. They do it because it works. They don’t see a need to change, but are finding the challenge by a potential competitor as a way to make their client relationship stronger. They are looking at their processes, explaining them and making them defensible. Focusing on “what works” is at the heart of many of the Agile methods anyway. This is a healthy way to deal with division: look at what works for your company, and make it defensible. Also, look at areas that can be improved, and look at the Agile movement as only one potential source for innovative ideas.

Methodology Reversals

A troubling trend I have witnessed is a mandated return to old ways of doing things in the face of Agile failures. The story goes something like this: Company A is having process and quality problems. With the support of executives, they adopt an Agile methodology, and implement it with great care. Agile coaches are used, experienced Agilists train the team, and they work to improve their process adoption. In short order, the results are phenomenal. Quality improves, team cohesion improves, and the executives see a happy, healthy, productive team that is helping them meet their objectives. Over time though, productivity drops. Quality once again begins to suffer. The team turns to coaches, training, and work harder to implement the process to the letter. The results aren’t there anymore though. They forget to adapt and improve to changing conditions, and they just stick to the process, and try to follow the formula that worked in the past. As they get more desperate, they make wild claims promising that “Agile” will help them unseat a powerful competitor who is “waterfall”, or will guarantee bug free software, improve all employee morale problems, etc. The wild claims are not met, and executives get nervous. “What else are these Agile evangelists wrong about?”

At least with the old way of doing things, they could exert more control. After all, they had a big paper trail, and isn’t that what the big successful companies do? “We need to stage delivery of each phase of software development and get buy-in and sign-off like the old days. This “Agile” thing was a nice experiment, but it isn’t working. Time to call the big process consultants, and let’s get everyone into their own offices, hire a requirements expert, and go back to what we are used to.” This is not necessarily a healthy way of dealing with the issue. Why not build on what worked, and adapt it? Sadly, this is an Agile implementation failing by people who knew what they were doing. Moving back to the way things were failing before will not necessarily help.

It shouldn’t surprise us that processes stop working over time – stores are full of books to deal with boredom over basic needs such as diet and intimacy. “Spice up your diet!” deals with the problem of yesterday’s favorite dinner becoming today’s tasteless same-old, same-old. If we tire and find repetition difficult to sustain with basic needs, why do we expect our software processes to be necessarily good for all time? This failure to adapt, and blind devotion to a formula causes “Agile” to get a bad name.

Company B on the other hand hears a lot of Agile hype. Every other company in town says they are Agile, and we think we are Agile too. We don’t have much documentation, and we do a release twice a year. It doesn’t get more Agile than that! Someone with some sense attends a user group meeting or a conference, buys a book or two, and starts educating the company on what “Agile” really is. Management isn’t completely comfortable with “Agile”, so they only allow a partial implementation of a methodology. “We’re doing what works for us.” is the common phrase. In some cases this is true, especially as a company iterates towards an Agile implementation, or improves after adoption. In many cases that can be translated into: “We can’t completely adopt an Agile methodology, so we’re going to do what we can, and call it Agile anyway.” As soon as Company B has problems, “Agile” is blamed, and management reverts to the official status quo. “We tried Agile, and it didn’t work.” Again, even though they didn’t implement it properly, “Agile” gets a bad name.

In some extreme cases, association with a particularly corrosive project failure can make it difficult for people to find work in their local community. If project X was a big enough failure to reach the local rumour mill, and project X was also a flagship “Agile” project, some Agile practitioners may find they have to drop the “Agile” label in their community, or they find they are equated with the charlatans.

Innovations

I’ve noticed some small trends that build on Agile methods and are moving forward. One is that most of the early adopters of Agile methods that I know are quietly expressing skepticism over the effectiveness of the processes and are looking for “Agile 2.0”, or the next phase of the Agile movement. Others have left the Agile movement and have moved on. At any rate, these are skilled thinkers who see that Agile processes do not address all the needs of a company. In fact, they see that in some cases Agile methods are inappropriate and ineffective. Others found that they worked for a while, but they needed to drop a methodology and adapt something new to be able to sustain the productivity and quality they required of themselves.

Many have found the Agile methods are too narrow and rigid for them, and don’t fit the bill for the situations they face. Some teams have dealt with this by mastering a process, finding where it didn’t work, and improving on it. Sadly, they face criticism from Agilists who may feel their source of revenue or process religion threatened. These innovators who constantly build on what they know and improve are the people that give me hope, and this trend is something I have labelled “post-agilism“. (Jason Gorman (and probably others) was also thinking about this. Check out his: “Post-Agilism: Beyond the Shock of the New“.)

Another trend I’ve seen is a correlation between companies with stellar process implementations who were financially unstable, and companies with disastrous development shops who had huge sales and were seen as successes in the business community. There are exceptions of course, but this is easily misinterpreted by those who equate a correlation with cause. Gary Pollice has an excellent article: “Does Process Matter?” where he explains how there are many more dimensions to a successful company than their software development methodology. Effective sales, marketing, timing in the market, and having something people want to buy in the first place have much greater bearing on the financial success of a company than the software development methodology that is being used.

The damage to the Agile reputation can occur with thinking like this: “Company X claims to be Agile. Our sales for a month are higher than theirs are for a year, so why should we adopt something that might hurt that? This Agile thing sounds like something to stay away from.” And with that, the ideas are dismissed. The thinking innovators see it differently.

The thinkers realize that the marketing hype of the Agile methods does not address a great deal of what makes a company successful. In fact, they realize that no software development process will make a company financially successful on its own. So they begin to look towards the big picture, and strive to align themselves with the rest of the company. The collaboration skills they have honed while executing some Agile practices can come into play as they move beyond the short-sighted picture of software development processes.

Note: Some people didn’t need the Agile movement to learn these skills. The Agile movement did not invent, and does not have sole ownership of lightweight, iterative processes, frequent communication and strong customer involvement in software projects.

Another troubling trend is the admission that some of the claims of success by Agilists are suspect. Ron Jeffries graciously posted: Misstating the Evidence for Agile and Iterative Development: an accusation from Isaac Gouy as one example. If we subtract the Agile marketing engine hype, discount the books, papers, talks, workshops and conferences that are fueling financial gain for those associated with the Agile movement, what is left? Is all of this Agile hype just that? Hype? Have we been duped by slick-talking process gurus who are giggling maniacally as they drive their sports cars to their banks to cash in their “Agile”-related spoils? This is certainly an impression that is growing with some who have tried Agile processes and found that they just did not work in their unique contexts.

What about the glowing success stories? How do we account for the legions of Agile fans, some of whom display a religious cult-like devotion to Agile methods? Some even appear to be intelligent people. Were they swayed by a leader who with a shakti-pat, or healing, blessing or word of knowledge, convinced the hardened skeptic? I don’t subscribe to conspiracy theories, and I believe that in certain contexts, Agile processes have enabled teams to do extraordinary things. However, measuring the effectiveness of software processes is extremely difficult. Only changing a process, and measuring the result does not take many factors into account, particularly when dealing with a group of humans. In fact, as phenomena like the Hawthorne Effect show us, the measurement itself may impact the changes we see. Rick Brenner calls these Observer Effects.

We may wrongly attribute the success of a software development process when something else may have a stronger impact. One team aspect I didn’t pay enough attention to, and possibly misattributed early Agile successes I observed, is skill. I’ve realized that any skilled team can make a process work for them and do good work, and any team lacking in skill is going to fail no matter what process they are using. Not exactly rocket science, but it was an important lesson for me. There are many other factors that can come into play.

Is misattribution of the reasons behind project success a problem? It can be, particularly when other teams implement the same kind of process, and find they aren’t much further ahead than they were before, over time. The cold reality of their situation, when contrasted with the raucous Agile hype, has caused many to justifiably feel misled. This kind of experience strongly fuels a backlash mentality. The popular (and long) post by Steve Yegge has elements of this, along with some Google hype: Good Agile, Bad Agile. Here is his follow up: Egomania Itself.

Moving Forward

The Agile backlash is here. Some of it is justified, and some of it is not. My intention in this post is to encourage people who find themselves in these different situations I’ve described above.

Are you an Agilist, and you find the particular processes your team subscribes to are working? Are you afraid of returning to the way things were before? Acknowledge that there is a backlash, and for whatever reason, you and your team might be faced with it. Build on what you have learned, and don’t be afraid to adapt and change to keep your productivity and quality at the levels you have achieved. Work to improve what you are doing, and don’t be afraid to discard practices that aren’t working anymore.

Are you a skeptic? Have you found a way to do things that works for your team? Good for you. Don’t give in to the divisive behavior of those who want to capitalize on Agile marketing. You are not alone — there are others who are in the same boat as you. Stick with what works, and don’t be swayed by the hype. Make your position defensible, and have a look at what some of the Agilists are talking about, so you are aware of the issues. Are you a skeptic from within, someone who finds themselves disillusioned with the Agile hype and zealotry? Have you tried Agile methods and find yourself in a similar position that you were in with other methods? This shouldn’t be surprising. Change your course to improve what you are doing. The more difficult the situation you find yourself in should let you know how drastic your changes should be.

Are you a decision maker who is looking for a formula to make more money, or to save more money and be more effective? If you are, I have a bridge to sell you in Saskatchewan. There is no magic formula. There is no cookie cutter approach. The Agile methodologies will not solve all development process ills, and they certainly won’t guarantee success in business ventures. In some cases, they can cause more problems than they address. As Fred Brooks told us twenty years ago, and Gary Pollice recently echoed, there is no silver bullet.

Agile methods are like anything else in life. Applying them involves trade-offs, and unintended consequences. A backlash is certainly one of them. Handling any trade-off well requires solid thought and good problem-solving. Let’s move forward together, and create the new future of software development, standing on the shoulders of the giants who have come before us.

Who Do We Serve?

Bob and Doug are programmers on an Extreme Programming team. Their customer representative has written a story card for a new feature the company would like to see developed in the system to help with calclulations undertaken by the finance group. Currently, they have spreadsheets and a manual process that is time-consuming and somewhat error prone. Bob and Doug pair up to work on the story. They feel confident – they are both experienced with Test-Driven Development, and they constantly use design patterns in their code.

They sit at a machine, check out the latest version of the code from source control, and start to program. They begin by writing a test and forming the code test-first, to meet the feature request. Over time, they accumulate a good number of test cases and corresponding code. Running their automated unit test harness gives them feedback on whether their tests passed or not. Sometimes the tests fail sporadically for no apparent reason, but over time the failures appear less frequently.

As they are programming and have their new suite of automated test cases passing, they begin refactoring. They decide to refactor to a design pattern that seems suitable. It takes some rework, but the code seems to meet the pattern definition and all the automated unit tests are passing. They check the code in, and move on to a new story.

The next day, they demonstrate the feature to the customer representative, but the customer representative isn’t happy with the feature. It feels awkward to them. Bob and Doug explain what pattern they were using, and talk about facades, persistence layers, inversion of control, design patterns, and demonstrate that the automated unit tests all pass by showing the green bar in their IDE. The customer representative eventually reluctantly agrees with them that the feature has been implemented correctly.

Months later, the finance department complains that the feature is wrong almost half of the time, and is causing them to make some embarrassing mistakes. They aren’t pleased. Wasn’t XP supposed to solve these kinds of problems?

Looking into the problem revealed that the implementation was incomplete – several important scenarios had been missed. A qualitative review of the automated tests showed that they were quite simple, worked only at the code level, and no tests had been done in a production-like environment. Furthermore, no thought had been put into the design for the future when the system would be under more load due to more data and usage. “That isn’t the simplest thing that could possibly work!” they retorted. However, the team knew that data load would greatly increase over the coming months. If they weren’t going to deal with that inevitability in the design right then, they needed to address it soon after that. They never had, and blamed the non-technical customer representative for not writing a story to address it.

Finally, when the customer representative tried to express that something wasn’t quite right with the design, they were outnumbered and shot down by technical explanations. One representative against the six technical programmers on the team who were using jargon and technical bullying didn’t stand much of a chance. After the problem was discovered in production, Bob and Doug admitted that things felt a little awkward even to them when they initially implemented the code for the story, but since they were following practices by the book, they ignored signs to the contrary. The automated tests and textbook refactoring to patterns had given them a false sense of security. In fact, the automated tests trumped the manual tests done by a human, an actual user, in their eyes.

What went wrong? Bob and Doug measured their project success on their adoption of their preferred development practices. They worried more about satisfying their desire to use design patterns, and to follow Test-Driven Development and XP practices than they did about the customer. Oh sure, they talked about providing business value, worked with the customer representative on the team and wrote a lot of automated unit tests. The test strategy was sorely lacking, and their blind faith in test automation let them down.

Due to this incident, the development team lost credibility with the business and faced a difficult uphill battle to regain their trust. In fact, they had been so effective at marketing these development methods as the answer to all of the company’s technical problems that “Agile” was blamed, and to many in the business, it became a dirty word.

Sadly, this kind of scenario is far too common. On software development teams, we seem especially susceptible to desire silver-bullet solutions. Sometimes it seems we try to force every programming problem into a pattern whether it needs it or not. We suggest tools to take care of testing, or deployments, or any of the tasks that we don’t understand that well, or don’t enjoy doing as much as programming. We expect that following a process will prevail, particularly a good one like Extreme Programming.

Through all of this we can lose sight of what is really important – satisfying and impressing the customer. In the end, the process doesn’t matter as much as getting that result. The process and tools we use are our servants, not our masters. If we forget that and stop thinking about what we’re trying to solve, and who we are trying to solve it for, the best tools and processes at our disposal won’t help us.

That “Agile” Word

I just came across an interesting post on The Hijacking of the Word Agile. Here is a quote from that post that got my attention:

The word ‘Agile’ seems to have been hijacked once again. Now, it is commonly used to justify just about any bizarre ‘practice’ and strange behavior in a software project. In some cases, it is even misused to justify complete chaos.

Inspired by the list of weird behaviors in that blog post, I thought I’d create my own list. Here are some similar so-called “Agile” actions I’ve seen:

  • Quote: “We do releases every 3 months, so we’re Agile.”
  • Quote: “We don’t have a process or do much documentation, so I guess we’re Agile too!”
  • Being in an organization for months, and seeing no outward clues of anything remotely Agile going on. Later, we were told the organization was following an Agile method that normally is very visible (as in “hard to miss”); most people there had no idea they were doing anything Agile at all.
  • “Quality Police” moving from enforcing traditional processes to enforcing Agile processes. This included political manipulation and attempts to humiliate or blackmail developers. All under the banner of “Agile Testing”.
  • Copying a variety of RUP, iterative development and Agile writing quotations. Mixing them up into a cornucopia, that, when used out of context, sounded an awful lot like what the team had been doing all along.
  • Consultants taking CMM or V Model, (or whatever they have been selling for years,) and sticking the term “Agile” on it, (presumably for the marketing buzz), without actually investigating Agile processes and adapting.

It’s not surprising that this kind of behavior by those ignorant of Agile methods, turns some people off of the term “Agile”. Couple that with some of the obnoxious Agile elitism and zealotry that is displayed by a few who are well-versed in and experienced with Agile methods, and even more people are finding themselves suspicious of this marketing term “Agile”. Tim Beck decided to do something about it, and came up with his own term for software development: “Pliant Software Development.”

We like and use many agile techniques and methodologies. We believe that in theory, agile development and pliant development are pretty much the same. In practice however, we feel that agile development has become a little too un-agile. There are whole sets of “process” which fall under the banner of agile development and unfortunately some people have gotten to the point where they are unable or unwilling to veer from the prescribed course of action. This leads to problems, because no two software development projects are the same. There are far too many technical, social and political issues to be able to come up with a 12-step program that fits all software situations.

–From the Pliant Alliance FAQ

Here are some different ideas on “Agile” from various people:

Unfortunately the industry has latched on to the word “Agile” and has begun to use it as a prefix that means “good”. This is very unfortunate, and discerning software professionals should be very wary of any new concept that bears the “agile” prefix. The concept has been taken meta, but there is no experimental evidence that demonstrates that “agile”, by itself, is good.

The danger is clear. The word “agile” will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.

The Agile Alliance worked very hard to create a manifesto that would have meaning. If you want to know their definition of the word “agile” then read the manifesto at www.agilemanifesto.org. Read about the Agile Alliance at www.agilealliance.org. And use a very skeptical eye when you see the word “agile” used.

Robert C. Martin

It really gripes me when people argue that their particular approach is “agile” because it matches the dictionary definition of the word, that being “characterized by quickness, lightness, and ease of movement; nimble.” While I like the word “agile” as a token naming what we do, I was there when it was coined. It was not meant to be an essential definition. It was explicitly conceived of as a marketing term: to be evocative, to be less dismissable than “lightweight” (the previous common term).

Brian Marick

…That’s most of what patterns are about: codified collective experience, made personal through careful feeling and thought. Unfortunately, it turned other people into sheep or, maybe worse, lemmings.

Jim Coplien

As with any mythodology, principles that begin with reasonable grounding can be misapplied and corrupted. This reminded me of James’ observation that the Traditionalists and the Agilists are both instances of the Routine or Factory School of Software Testing (as Bret Pettichord describes in his wonderful paper Four Schools of Software Testing). I may disagree with James to the degree that I don’t think the early or smarter Agilists intended to behave in a Routine-School manner, but I think he’s right to point out that a large and growing number of their disciples appear to have slipped into Routine behaviour.

The common element between Bad Traditionalist processes and Bad Agile Processes is that both want to remove that irritating thinking part.

Michael Bolton (emphasis mine)

The lesson to me is this: our words are important. When a term is used in many contexts meaning something different in each, it’s a vague word. When a word is vague, it is important to get a definition from the people using the word. Otherwise, it may only seem like we are using a shared language, when we really aren’t. We should also be careful with our own language, and the terminology we associate ourselves with, because, in the case of vague words, it can have unintended consequences.

Pliant Software Development

Recently, I met Tim Beck, who is behind Pliant Software Development. I like his ideas, and I support what he’s doing.

When I came across this website, I liked what I saw, and when we got together in person, I really liked what I heard. Tim is thoughtful, principled, positive and forward-looking. He wants to see software development move ahead and continuously improve. Like me, he doesn’t think we have the final word on software development yet. I was also pleased to see in his work that he is also a contextualist. You won’t get any “one-true-way” marketing from him.

Here’s an excerpt from the Pliant About page:

Again, there is no right answer. Therefore, there is no point in trying to find one. What we must do is strive to adapt our processes so that we get better at developing software. As the definition at the top of this page implies, in order to be pliant, we must bend or fold our current process to fit the situation we are facing. Since the situation is constantly changing, we have to be constantly changing our process.

One comment Tim makes frequently is this:

Are we solving the real problem?

Inspired by his description of the company where he worked that coined this phrase, and hung it up on a banner, I had an idea. This question should be printed out on a large banner in software development companies, visible to all (executives included), particularly where process or tool zealotry is reaching a fever pitch. All too often we reach for a process/tool without looking at the real problem. In many cases, we then end up with our problems being compounded. Not only does the real problem remain unaddressed, but we end up with even more systems to maintain, distracting and robbing us of productive problem-solving time. We might get so distracted while working on the “solutions”, that we have even more fog preventing us from seeing the real root of the problem. Sure, it might be more fun to adopt an ambitious test automation project, or buy that shiny new tool we’ve been looking at, but if we don’t understand the real problem, we may create an even bigger one.

Check out Tim’s work. I find his posts thoughtful as well as thought-provoking. In an industry that seems prone to silver-bullet-itis, we need more thoughtful process skeptics like Tim, who genuinely want to see the world become a better place.