Category Archives: agile

agile, process, value

Content Pointer: The Next Wave: Valuable Products First, Process Second

I wrote an article for Modern Analyst that describes some of my process thinking over the past several years. They asked for a piece on post-Agilism, but I prefer talking about value now, so I wrote this piece for them instead.

I introduce my thoughts on a trend I have witnessed for a while now where people move from software ideas (let’s build this killer app!), to process (let’s go Agile!), to value (let’s ensure our application blows our customers away, and everything we do feeds that effort.)

Three years ago, I didn’t hear people talk about value that much at all. It was all process, process, process, and how following an Agile or other process would lead us to success. Now, I am seeing the “value” word pop up more and more, and more teams are using an overall vision to help focus their efforts (process and otherwise) towards creating value for their customers and themselves.

agile, post-agilism, process fusion, TDD, test-driven development

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.

agile, post-agilism

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.

agile, agile testing, post-agilism

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?

agile, religion

A Software Religion Strikes Again?

Jim Coplien has an interesting blog post: Religion’s Newfound Restraint on Progress. If you are interested in “Agile Testing” and Test-Driven Development, this post is worth a read.
Coplien raises some important ideas:

The answer for industry, I think, is to focus on Quality and to find the techniques that work best and are the most cost-effective for your project.

It’s about thinking, not about checklists.

While we might diverge on ideas for solutions, I agree with Coplien’s message here. We need to have broad objectives and goals, and use the effective tools and processes at hand to reach those goals, rather than get lost in silly either/or debates about adopting tools and processes because they are an unalloyed good. We have enough folklore in software development without creating new myths and “best practices.” We need to share success stories and failures, instead of reinforcing ideals and discouraging thoughtful criticism born of experience. Being honest and realistic helps push the craft forward. Being overly idealistic pushes us towards religiosity.

We don’t all have to agree, but we need more of the kind of writing that James is doing here. It’s not so much that he is correct or incorrect, but that he has the guts to speak publicly about his misgivings and ideas. I don’t have to agree with what he says, but if he makes me think about what I’m doing, and challenges my beliefs, that’s a good thing. Sometimes in the face of a challenge and evidence, I change my mind, other times, I have to clarify my own thinking about a belief, which strengthens it. Support your local skeptic, and discourage those who scoff at and bully them.

agile, post-agilism

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.

agile

What’s New?

When I was in university ten years ago, it seemed that Total Quality Management was all the rage in business schools. Terms like employee empowerment, quality control, quality circles, lean manufacturing and statistical process control seemed to be on the lips of the wise.

Nowadays, I am seeing the same ideas that were put forward by people ten or twenty years ago called fancy things like “Agile Software Management.” Some of these recent thoughts would seem at home in Feigenbaum’s Total Quality Management from the 1950s. Some of them were good ideas in the past, and are good ideas now, even if they are rehashed under a new name. We see this kind of behavior repeated over time.

Many early large organizations in North America were railroad companies. They were among the first to discover that large companies faced unique problems. Over one hundred and fifty years ago, Daniel McCallum defined a management structure that was widely adopted and that we are familiar with today. The next time you look at an org chart, feel free to silently thank him.

Prior to the great railroad empires of the 19th century, mercantilism was a dominant economic belief. Adam Smith and his colleagues attacked this model and wrote of a free market system. The system was driven by consumer wants and competition. To survive as a viable business in this system, you needed to be productive. This obsession with productivity is still with us today.

In the early 20th century, Frederick Taylor and the Gilbreths made this into an art form. They employed Time and Motion studies; they lectured and wrote on how workers could increase efficiency, and thereby improve productivity. Today, many decry the work of Taylor and the Gilbreths for various reasons, but we still feel the pressure of efficiency. In fact, not unlike the poor bricklayers, assembly-line workers, or coal shovelers, knowledge-based workers find themselves in a culture obsessed with speed of development and zero defects. Today, we give it names like “Lean” or “Evo”.

As organizations grew larger, thinkers like Henri Fayol came up with systems to deal with the administrative side of management. It emerged as a system of planning, organizing, directing, co-ordinating and controlling. Max Weber was an early thinker who felt that organizations should be socially responsible. It’s interesting that almost one hundred years ago Fayol and Weber expounded on beliefs that we hear echoed today.

Somewhere along the way, management thinkers realized that people do the work, and that no matter what kind of machines we have, or automation we employ, an organization is only as good as its people. Fritz Roethlisberger described the all-too-human Hawthorne Effect. His contemporaries felt that human factors contributed to productivity. Abraham Maslow introduced his hierarchy of needs theory, and now we have volumes of work in this area. Today we are well aware of human factors in organizations. Just talk to someone in Human Resources about their typical day.

Management theory began to embrace innovation as a key component. Over the past twenty years (at least) this has been a major theme. When was the last time you attended a management seminar that didn’t extol the virtues of Toyota, Federal Express and Wal-Mart? Often, the ability to harness technology is trotted out as a factor in the success of those companies. (As a side note, Toyota’s quality scores are carefully examined, but their product recalls are not usually discussed in those venues. Toyota makes a great product, but they aren’t perfect. I have jokingly threatened colleagues that if I hear one more software process wonk drag out Toyota as an example, I will scream. It is an empty threat though – I haven’t yet screamed in a meeting.)

In software development circles, we are faced with some interesting new ideas. Let’s examine the Agile software development movement. The Agile Manifesto was thrust on the scene by respected software thinkers over five years ago. I, like many others, was excited by this statement. Here was an acknowledgment of the humanistic endeavor of software development. It not only made sense but it resonated with my beliefs. Something sounded familiar, though. Agile Manufacturing was an idea that was brought forward in 1995 in a book: “Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer” by Steven L. Goldman, Roger N. Nagel and Kenneth Preiss. According to wikipedia, these are four key attributes in the book:

  1. delivering value to the customer;
  2. being ready for change;
  3. valuing human knowledge and skills;
  4. forming virtual partnerships.

Those sound like good ideas. I don’t know if they inspired the Agile software development movement or not, but even if they did, it doesn’t detract from the points of Agile manifesto. It may just tell us that a lot of people have been struggling for a long time with the complexity of organizations trying to work together towards common goals. Maybe they just came to similar conclusions.
Another new idea on the software development front is adapted from lean manufacturing. The Poppendiecks are at the forefront of this push in the software movement. I like a lot of what Mary and Tom say. It is thoughtful, makes a lot of sense, and they have the experience to back up their claims. However, I get concerned about doing a copy/paste from the manufacturing world and applying it to software development. David Benoit sums this up eloquently:

[I]t still amazes me how many people don’t seem to understand that software development has very little in common with real-world-object development. The creation of software is most like the creation of art. To be good it must be inspired. To be of interest it must be unique. To be worth something it must be different.

As time marches on, I find I am faced with an uncomfortable truth: software development, like any other human organizational effort, is a complex endeavor. There aren’t formulas to guide us that will always work in every situation. And, as much as we have progressed into a modern age, we still struggle with the same things organizations have struggled with for centuries, or millennia. We are still re-inventing the same solutions and are still trying to come up with new ones. Sometimes what is “new” is merely the “old” with a different name. Maybe the author of Ecclesiastes was right when they said: “there is nothing new under the sun.”