All posts by jonathankohl

agile, post-agilism

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.

agile, post-agilism

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.

agile, extreme programming, post-agilism, TDD, test-driven development

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.

agile, post-agilism

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.

quality theory, test automation, TQM

Employee Empowerment and How I Became a Contextualist

Back when I was in college, I had an instructor who was a big fan of Total Quality Management (TQM). TQM was quite popular, but in our business school setting, it wasn’t taught that much. We learned about Juran, Feigenbaum and Total Quality Control, Deming and a lot of Quality theory. We learned about kaizen, quality circles, flat organizations and employee empowerment. When our instructor had us memorize W. Edwards Deming’s 14 Points, I was hooked. Most of the Quality theory just made sense to me. Why do business any other way?

I particularly liked the idea of flat organizations with empowered employees who were in charge of their own destiny. I had worked part-time with various organizations for several years, and already saw how much waste can occur while executing business tasks. Often, the people doing the work had a much better idea on how to be more efficient, but layers of management seemed to get in the way. I often thought about Quality theory, and in these cases, about using employee empowerment. It seemed to be the answer to inefficiency issues I was seeing, and might help employee morale.

Later on, I learned an effective heuristic for business school case studies:

If I use Quality theory with a good dose of Deming as a solution for any problem, I’ll get a good grade.

So I often used Quality theory for case study assignments. It worked quite well. It seemed that few of my classmates used these kinds of ideas, so I probably got marks for being unique. Then I had Dr. John Rutland as a professor, and things changed. I found out that the heuristic didn’t always work, and that it was a poor one at that. Dr. Rutland figured out quite quickly that Quality theory was my silver-bullet, and deftly pricked the balloon of my pomposity.

After working on a business case study, he asked me for my ideas. I began reciting my typical answer:

  1. empower the employees.
  2. flatten the hierarchy.
  3. form Quality Circles to work on solutions to problems.
  4. etc.

I had barely uttered something about “empowering employees” when he cut me off.

“Jonathan. Have you talked to the individual employees yet?”

“No.” I answered.

“Do you know what makes them tick? Do you know what their motivations are? What their likes and dislikes are? Do you know not only their frustrations but their sources of pleasure?”

“No.” I stammered. “Why did you suggest it then?” I choked out something about having better job satisfaction if employees feel they have a say.

“You mean to tell me that you think an employee who works in the auto industry whose job is to turn a bolt on an engine block a quarter turn all day, five days a week doesn’t have job satisfaction? You may not enjoy that job, but other people might. They may be happy with the way things are, and miserable if they are ’empowered’. How can you be so arrogant to think that without finding out what the problems are, or what the motivations of your employees are, you can just go ahead and impose a system without taking them into account?”

Wow. I was shocked. He was right. I wasn’t empowering anyone, I was doing what Jerry Weinberg describes as “inflicting help.” I felt ashamed at my ignorance. Dr. Rutland went on: “Jonathan, people are cognitive beings. They are all unique. It’s your job as a manager to find out what makes them tick. It’s your job to help them reach their goals and remove obstacles from their way. The right solution is the one what works in their environment, taking their needs and talents into account. You can’t just impose the way you think is the best way for all environments.” I was stunned, but after I swallowed my pride, I decided I should learn everything I could from him. The lesson that day (thanks to me), turned out to be on context, and to not settle on one solution, and then always use that one solution for every problem. That was at best naive, at worst lazy, and negligently incompetent. “Use the solutions that work right now, given the team, environment and culture you have.” Dr. Rutland said. “You can learn a lot of different techniques, but in the real world, things have a habit of not going according to plan. A good manager will learn as much about these tools as possible, but will adapt and adjust accordingly, using the tools that work for each unique situation.

Furthermore, there are cases where Quality theory has failed spectacularly, in real, live organizations. The real world has a habit of yanking the rug out from under us.”

I have never forgotten that lesson on how the context for what we do is extremely important. Years later, some people echoed similar wisdom, calling themselves the Context-Driven Testing School. Their ideas resonated with me, thanks in no small part to what I learned from Dr. Rutland, who had first taught me to be a contextualist.

Furthermore, I’ve been in situations where a flat, employee-empowered organizational structure was a complete disaster. Sadly, despite being prepared for it, I was shocked. I worked for an organization that had several business school case studies that holding it up as a model for an employee-driven organization. Once I was inside, I found it was a terrible place to work. I’d never before seen such bitter political infighting, deliberate project sabotage, posturing projects, coup attempts, inefficiency, waste and poor morale. When I moved on, I was so relieved to get out of that organization with its confusing reporting structure, paralyzing indecision (from so many competing employee committees), and general toxicity. It was a breath of fresh air to go into an organization that many would decry as being “Taylorist” or “Command and Control”. At least most of the decision making was in fact decisive, and I knew who had the decision making power based on the organizational chart.

I told Brian Lawrence a bit about this experience, and he simply said: “The hierarchy went underground.” I was pleasantly surprised by this bit of wisdom. In a top-down organization, at least you know the hierarchy more or less. The unpleasant “Taylorist” and “command and control” behavior did not really go away, even in a company that was founded with a flat hierarchy and text-book employee empowerment programs. It just went underground, and it got very ugly, having the opposite effect that the founders intended. I was reminded of Weinberg’s “Rule of Three”, which goes something like this: if you can’t think of three ways a potential solution can fail, you don’t completely understand the problem space.

I’ve learned from wise teachers, and I’ve been fortunate to learn from people like Dr. Rutland and Brian Lawrence. My learning has shown me that any kind of process, structure or tool has the potential to fail. The context is important, and it is foolhardy to charge ahead with a potential solution without fully exploring the problem space. Life is full of tradeoffs: any potential solution we suggest in an organization has the potential to fail. It’s okay to still go forward with a potential solution even if we can imagine it might fail. (I don’t even care if it is the “right” one, as long as we are prepared to adapt when needed.) To believe a practice, tool, process or organizational structure is unquestioningly right, in any context, will eventually lead to disappointment. When I read back over some of my TQM notes, I find that there are some great ideas there, but I don’t treat them as my hammer and every problem I see as a nail anymore. I hope I manage to continue doing that with other processes and tools.

So what do I do now that I’ve learned something? I:

  • resist jumping to a solution too quickly;
  • learn about the context;
  • talk to the people doing the work, and do a lot of listening;
  • do careful analysis before suggesting solutions; and
  • use Rule of Three to do contingency planning and raise awareness of the potential for problems to come up in the future.

In my line of work, it is common for people to immediately ask me if I’m going to do test automation once they learn I’ll be on a project. My answer tends to be something like this:

If, after careful analysis, we find that test automation is a good fit to solve the problem we need to solve, we’ll explore test automation.

That answer seems to surprise people, but I’ve learned my “test automation as problem solution” lesson several times over. I have seen so many test automation efforts fail because “test automation” was thought of as a solution to all testing woes. I’ve seen enough failures to know that test automation is a tool that requires careful thought and planning. As Tim Beck would say, “Are we solving the real problem?” My job is to work with a team to find out what the problem is, and work with them on a solution to that problem. Test automation, like employee empowerment may or may not help us solve that problem. In some cases it may just compound our existing problems with new and exotic ones.

post-agilism, tools

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.

agile, extreme programming, popular, post-agilism, TQM

Post-Agilism: Process Skepticism

I’m a fan of Agile practices, and I draw on values and ideas from Scrum and XP quite often. However, I have become a process skeptic. I’m tired of what a colleague complained to me about several years ago as: “Agile hype”. I’m tired of hearing “Agile this” and “Agile that”, especially when some of what is now branded as “Agile” was branded as “Total Quality Management”, or <insert buzzword phrase here> in the past. It seems that some are flogging the same old solutions, and merely tacking “Agile” onto them to help with marketing. It looks like Robert Martin was right when he predicted this would happen.

More and more I am meeting people who, like me, are quiet Agile skeptics. I’m not talking about people who have never been on Agile projects before that take shots from the outside. I’m talking about smart, capable, experienced Agilists. Some were early adopters who taught me Agile basics. While initially overcome with Agile as a concept, their experience has shown them that the “hype” doesn’t always work. Instead of slavishly sticking to Agile process doctrines, they use what works, in the context they are currently working with. Many cite the Agile Manifesto and values of XP as their guide for work that they do, but they find they don’t identify with the hype surrounding Agile methods.

That said, they don’t want to throw out the practices that work well for them. They aren’t interested in turning back the clock, or implementing heavyweight processes in reaction to the hype. While they like Agile practices, some early adopters I’ve talked to don’t really consider themselves “Agile” anymore. They sometimes muse aloud, wondering what the future might hold. “We’ve done that, enjoyed it, had challenges, learned from it, and now what’s next?” Maybe that’s the curse of the early adopter.

They may use XP practices, and wrap up their projects with Scrum as a project management tool, but they aren’t preachy about it. They just stick with what works. If an Agile practice isn’t working on a project, they aren’t afraid to throw it out and try something else. They are pragmatic. They are also zealous about satisfying and impressing the customer, not zealous about selling “Agile”. In fact, “Agile” zealotry deters them.

They also have stories of Agile failures, and usually can describe a watershed moment where they set aside their Agile process zeal, and just worked on whatever it took to get a project complete in order to have happy customers. To them, this is what agility is really about. Being “agile” in the dictionary sense, instead of being “Agile” in the marketing sense.

Personally, I like Agile methods, but I have also seen plenty of failures. I’ve witnessed that merely following a process, no matter how good it is, does not guarantee success. I’ve also learned that no matter what process you follow, if you don’t have skilled people on the team, you are going to find it hard to be successful. A friend of mine told a me about a former manager who was in a state of perpetual amazement. The manager felt that the process they had adopted was the key to their success, and enforced adherence to it. However, when anything went wrong (which happened frequently), he didn’t know what to do. Their project was in a constant state of disarray. I’ve seen this same behavior on Agile projects as well. (In fact, due to the blind religiosity of some Agile proponents, some Agile projects are more prone to this than we might realize.) Too many times we look for the process to somehow provide us the perfect answer instead of just using our heads and doing what needs to be done. “Oh great oracle, the white book! Please tell us what do do!” may be the reaction to uncertainty, instead of using the values and principles in that book as a general guideline to help solve problems and improve processes.

I have also seen people on Agile teams get marginalized because they aren’t Agile enough. While I appreciate keeping a process pure, (such as really doing XP rather than just calling whatever you are doing “Agile” because it’s cool right now), sometimes you have to break the rules and get a solution out the door. I have seen people be pushed out of projects because they “didn’t get Agile”. I have seen good solutions turned away because they weren’t in the white book (Extreme Programming Explained). I’ve also seen reckless, unthinking behavior justified because it was “Agile”. In one case, I saw a manager pull out the white book, and use a paragraph from it in an attempt to justify not fixing bugs. I was reminded of a religious nut pulling quotes out of context from a sacred book to justify some weird doctrine that was contrary to what the original author intended.

Here’s a spin on something I wrote earlier this spring:

In an industry that seems to look for silver-bullet solutions, it’s important for us to be skeptics. We should be skeptical of what we’re developing, but also of the methodologies, processes, and tools on which we rely. We should continuously strive for improvement.

I call this brand of process skepticism exhibited by experienced Agilists “Post-Agilism”. I admit that I have been an Agile process zealot in the past, and I don’t want to fall into that trap again. I’ve learned that skill and effective communication are much more powerful, so much so that they transcend methodologies. There are also pre-Agile ideas that are just fine to pick from. Why throw out something that works just because it isn’t part of the process that’s currently the most popular?

Test your process, and strive for improvement. Be skeptical, and don’t be afraid to follow good Post-Agilist thinking. Some good Post-Agilist thinkers are former process zealots who know and enjoy Agile development, but also don’t throw out anything that isn’t generally accepted by Agilists. Others are just plain pragmatic sorts who saw the Agile hype early on, and decided to do things on their terms. They took what they found effective from Agile methods, and didn’t worry about selling it to anyone.

Post-Agilist thinkers just don’t see today’s “Agile” as the final word on software development. They want to see the craft to move forward and generate new ideas. They feel that anything that stifles new ideas (whether “Agile-approved” or not) should be viewed with suspicion. They may benefit from tools provided by Agile methods, but are more careful now when it comes to evaluating the results of their process. In the past, many of us measured our degree of process adoption as success, sometimes forgetting to look to the product we were developing.

What does the post-Agile future hold? Will individuals adapt and change Agile method implementations as unique needs arise? Will “Agile” go too far and become a dirty word like Business Process Re-engineering? Or will it indeed be the way software is widely developed? Or will we see a future of people picking what process works for them, while constantly evaluating and improving upon it, without worrying about marketing a particular development methodology? I certainly hope it will be the latter. What do you think?

Edit: April 28, 2007. I’ve added a Post-Agilism Frequently Asked Questions post to help explain more. Also see Jason Gorman’s Post-Agilism – Beyond the Shock of the New.

documentation, popular, test scripts

Placating with Paper

Accountability. This is often a scary word for some people. Sometimes when we are fearful of the results of a decision, or of our work on a project, we will look at what we can do to offload responsibility. “At least I won’t be blamed if anything goes wrong.” might be the thinking. It’s hard to constantly offload onto other people though. After a while, we’ll run out of team members to blame, and we probably won’t be too popular. One easy way around this is to offload accountability onto an inanimate object: paper. Paper often comes in the form of specifications, design documents, test plans, test cases, or as I see more lately, proof of adherence to a popular development process. Paper might be substituted when we need to do something difficult, or provide reasons why a product isn’t working, or when we need to say something others may not want to hear. Paper with fancy words and jargon is often accepted as a short-term solution to project problems. Trouble is, what does it help in the long-term, when you are being paid to deliver software?

In one case, paper provided hope to end an unpleasant release. The development team had just come out of a meeting with our sales team and a couple of important clients. They were quite clear that we needed to deliver a particular feature in our next release. Unfortunately, it wasn’t working properly. Whenever we tested this new feature, the application crashed in a spectacular manner. There had been two attempts at redesigns, and everything else in the release seemed solid. The programmers were tired and demoralized, management didn’t want to hear about any problems anymore, and the testers were tired of testing and feeling the weight of the release resting on their shoulders. They felt singled out because whenever they logged a bug report, the rest of the team would accuse them of holding up the release. “Jonathan, why are we testing this feature in this way?” the test lead asked, and pointed to the specification document.

“We’re testing this because this is the most important feature in the release. Without this feature, our sales team is going to struggle, and our customers are going to be upset. Remember what we talked about in the meeting with both the customer and the sales team?” I asked. “Sure I do, but look at the spec. It doesn’t spell out what the customer asked for. If we test to the spec, we can ship! The tests will all pass if we only test according to the spec.”

The lead tester had found a loophole. The thinking was that if we tested only to the spec, and followed the document to the letter, we could pass the tests that were currently failing, and management would happily release the software. Everyone would be relieved, and furthermore the lead pointed out, who could blame the testers if anything went wrong? The design spec would be at fault, not the testers or developers. “But it flat-out doesn’t work!” I retorted. “Sure it does, according to the design spec.” they replied. “But the customer can’t use a design spec to do their jobs, can they? If our software doesn’t do what they expect it to do, are they supposed to print out the spec, clutch it to their chests and draw comfort and dollars from it? The spec is meaningless to the customer when they are trying to use our software. They need this feature to work in their context, to help them get their work done. They are relying on us to deliver software, not a piece of paper with a hollow excuse.”

I was a bit shocked at what this test lead proposed at first, but dealing with pressure in this way is not uncommon. A paper document can carry a lot of weight in an organization. People can draw a false sense of security from some official looking prose wrapped in corporate logos. I encouraged the tester to not fall for quick fix technicalities, especially if she wants to be a tester for very long. Fight the good fight, and while it may be hard in the short-term, the payoff in the long run is great. Happy customers, and the respect of your peers are just two payoffs. Being able to look at yourself in the mirror every day and know you have your integrity in tact is also something important, and no project deadline is worth sacrificing that for. A tester with a reputation for having no integrity will not be employable in the long-term.

On another project, paper was used in a different way. I was on one small team, and we met with other teams in the company periodically to share ideas. Another team came to a meeting and crowed about the “traceability” of documentation they were creating on a large project. We were on a small project at the time, and we were minimalists with documentation, preferring to deliver working software that could be deployed into production every two weeks. “That’s fine, but you don’t have traceability like we do!” they said. They bragged that for every method of code that would be written, there would be three documents generated as “project artifacts”.

They met with us again in a few months. We had delivered two projects that were helping the company make more money, and they were still talking about documents. “Can you show us the code?” we asked. “We’re still in the requirements-gathering phase”, they snapped. They were too busy to code, instead, they were writing documents — documents about the design, documents about a myriad of tools they could choose, and more documents documenting other documents. The company had spent several million dollars that year, and there wasn’t one line of code to show for it. They had so-called “traceability” though, with project documents, and committees reviewing documents, and committees reviewing other committees. An entire infrastructure to support this process was developed. There were literally teams of people working full-time churning out documents, but finding a programmer in all of this was not an easy task. Expensive tools to aid in paper generation were purchased, more people were hired to keep up, and project budgets were sacrificed on the altar of the great “project artifact” gods. (All stages of each properly documented and “signed off” on of course.)

Through all of this, management was placated with a blizzard of paper. “Do you have a demo yet?” they would ask, only to be inundated with mountains of UML diagrams, meeting minutes, decision matrices and vendor white papers. This satisfied management in the short-term. Look at all this paper – lots of work must be getting done.

In the end, paper didn’t deliver. There came a time when documents just didn’t cut it anymore. Management wanted a return on investment. They didn’t care about the development process du jour, detailed design documents, and requirements changes and budgets signed off in triplicate. They wanted to see the project working in production, helping them realize their business goals of a return to investors. There wasn’t much of a product there though – there were lots of documents, but precious little in the way of tested, delivered software.

The project went several years, and millions of dollars over budget. It was also a public embarrassment for the company. People identified with that project were blamed, and association with that project was an impediment to finding work with other companies who had heard about it through the grapevine.

What went wrong? The vendors, consultants and employees knew they could placate management with paper, and management didn’t demand a working solution early enough. This project could have done well, had they released working software incrementally, rather than churn out ever-growing mountains of paper. Instead of taking personal responsibility, the people working on the project placated customer demands with paper.

What were they thinking? Maybe they didn’t really know what they were doing. Maybe they hoped the programming elves would rescue them if they created enough documents. Maybe they got swept away in groupthink, and followed a process instead of working to deliver software. Maybe they collectively thought that a colleague would take responsibility. Maybe they just didn’t care. I don’t know.

The customer unwittingly paid people to generate a lot of paper, instead of getting them to write and demonstrate working software. They accepted paper designs instead of code that could be demonstrated. They accepted paper over skill, and they accepted paper instead of accountability and working software.

Accountability. Demand it from yourself, and from others. Placating with paper may get you through the short-term, but sooner or later you have to demonstrate your skill. Skill can be demonstrated individually as a programmer, as a tester, a technical writer, a project manager, and demonstrated collectively as a team. It will ultimately be demonstrated in your product. Does what you produce match your claims? If it doesn’t, a document and a nice explanation may get you out of a jam in the short-term, but in the long-term, you have to deliver what the customer needs. The customer won’t blame the document – they will blame you and your company, and move on to a competitor’s product. Where does that leave you?

process

Hiding Behind Languages, Frameworks and Processes

Clinton Begin recently did a talk at a local Java users group, called “Ruby Rebuttal“. While I like Ruby, I know that Clinton is tired of some of the hype surrounding the language, and the calls and predictions of Java’s impending death at its hand. I was unable to attend his talk, but I particularly liked this part of his abstract:

So what’s the problem? We’ve forgotten how to write good software. Instead, we choose to blindly follow “best practices” and “patterns” by simply stuffing what used to be good code into reams of XML and annotations.

I agree. I don’t really care about Ruby vs. Java, or vi vs. Emacs, or “Agile” vs. “non-Agile”, etc. etc. etc. debates. Furthermore, hype does little to impress me. Like Clinton, I find myself turned off by excessive hype, and it makes me want to run in the opposite direction. What impresses me are people who have a position on an issue and aren’t afraid to speak their minds. What impresses me even more are skilled practitioners with a track record. I know Clinton–we’ve worked together–and I have a great deal of respect for him. Reading that section of his abstract just raised him up a few notches in my eyes.

I would take what Clinton said one step further. We also stuff what used to be good practice for development teams into a process. We then hold this process up like some mystically-endowed talisman, and through ritual and jargon create a kind of priesthood. The process might be home-grown, it might be “Agile,” or it could be anything that seems fashionable at the time. There are the us, and there are the “unenlightened” them. (Sometimes, as the previous links show, the “enlightened” helpfully point out the “them” in the form of a joke. How this attempt at parody does anything constructive is beyond me.) I might like or dislike a particular process, but if it is working for the team, that’s what really matters. A process, no matter what it is, is our servant, a tool to help us realize our goals.

When we lose sight of the goals of the business, it’s easy to hide behind a process, a framework, or a language. “Yeah, the product sucks, but we followed the 12 Practices of XP! Look at this scatter chart! We did everything we could!” or or “It would have worked if we had used Java!” or “We used XML! It had to work!” Programming languages, frameworks, development processes and best practices can all be used as shields.

What Clinton touches on reminds me of a blog post by Robert Martin: I’d rather use a socket. Uncle Bob says:

I think the industry should join frameworks anonymous and swear off gratuitous framework adoption. We should all start using sockets and flat files instead of huge middleware and enormous databases — at least for those applications where the frameworks and databases aren’t obviously necessary.

The first time I read Martin’s blog post, Clinton and I were both looking at a design document. A challenge for the proposed system was performance, but it had so many options of distributed frameworks it looked like the latest ad for a Service Oriented Architecture consulting company. Clinton turned to me and said: “If performance is a big deal, why are they looking at a distributed system? Going to disk is going to be much faster.” At that moment I knew Clinton and I were going to get along just fine.

I see the same kind of behavior Clinton and Robert Martin describe when it comes to processes – Agile or otherwise. Paraphrasing Robert Martin: I think the industry should join processes anonymous and swear off gratuitous process adoption.

We should all start analyzing what our processes are doing for us, and only allowing the practices that work for your team, in your context to stick around. We need not hide behind “Agile this” or “XP that” or “CMM something-or-other”, but proudly display our skill, and more importantly, our handiwork to satisfied and impressed customers.

We need to write great software, and continuously improve on whatever languages, frameworks and processes get us there. Whatever we do, we must be aligned with the goals of the business, and take the skills of the team members, as well as the corporate culture into account when we adopt a tool. We need to use the tool that serves us, whether it is a programming language, an IDE, a framework or a process. Leave the religiosity to medieval scholars. If we lose sight of what we’re in business for in the first place, our processes will just end up as hollow ritual.