Category Archives: Agile War Stories

Agile Backlogs Redux

Spent some time today gathering together the many ways Agile Backlogs are wrong.

It was a painful journey — very sad to remember the different, many ways we screw up doing backlogs. But it was for a worthy cause: I have a new microsite positioned around Agile. Part of the site is a bunch of landing pages, part is a blog.

I’ve never blogged tightly around one subject before — quite frankly, the concept drives me nuts. But I’m wiling to give it a go. I have a lot of experience with Agile teams. Perhaps I can take some of my SEO/Microsite experience, some of my Agile experience, some of my e-book experience, and make something useful out of it. Who knows? Never know unless you try.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Perfect Agile/Scrum Stand-up

When people first arrive in Agile/Scrum, one of the first things they ask is “Doesn’t Agile mean we don’t need requirements?” followed by a close second of “Scrum is too rigid. We definitely don’t want something so restricting”

It seems like you’re either a cowboy or a Nazi. There are no in-betweens.

It’s like this: Agile is all about dynamic process tailoring. That means, yes, that teams control the degree of paperwork and process they need to accomplish. But it’s also like this: there are some “recipes” that the community has found over and over again that work. You’d be a complete fool to ignore them.

What happens with high-performing teams is that they have very few things they do that are defined and reproducible. But for those very few things, they are very disciplined. Being Agile, strangely enough, means being extremely disciplined about a very few things and leaving the rest of the details to make up as you go along.

The crux of all this ambivalence is, in my opinion, the stand-up. Since nothing proves a point like actually seeing it, in the video that follows, note the following things:

  • It happens quickly. Stand-ups are high-energy. People are standing-up, moving around. Nobody is sitting in their chair with their head in their notebook or cellphone.
  • Nobody is reporting to anybody. This isn’t a status report. There are no questions and answers.
  • We point at the things we are doing. It’s all about Visual Process Control. That means the things you are doing are publicly visible, they represent status at any time, and they are manipulable.
  • Decisions are made after the stand-up. The stand-up is a game of identifying tokens: what has happened, what is going to happen, what obstacles individuals are facing. After the tokens are all identified, the “real” work begins: the tokens are resolved. Technical discussions and ad-hoc discussions begin.
  • There is no Project Manager. If you can look at a stand-up and find a project manager, it’s a bad stand-up. Stand-ups are about team commitments, risks, and issues. Not roles.
  • Everybody is in the same room. Body language and other non-verbal communication channels count. A lot. Everybody isn’t standing around talking into a PolyCom.
  • It’s scalable. If done correctly, team stand-ups scale very easily. A manager could attend several stand-ups each day, get a close-up view of how the entre program is going, and still have most of the day free for coordination and planning activities.
  • The team is small. You can’t have an Agile team with 30 people on it. Do not do this. It does not work.
  • The story board is not that complicated. This is about the limit of complexity for a story board that I am comfortable with. Past this is drudgery. If your storyboard has the colors of a Christmas tree and a sufficient number of post-its to draw a 40-foot picture of Godzilla, you’re over-complicating things. Stop that.
  • It’s a problem-solving exercise. Immediately after the stand-up is over, the Product Owner talks to anybody with questions or problems and works them out.
  • We work out problems visually. Notice how they pull the story/task over to the flip-pad and work through the problem? See how the options and structures are all presented visually? Here’s a tip: doodling or drawing structures and flow on paper has about a hundred times more effectiveness that trying to write it down or vocally discuss it. Model things.
  • Big Picture is not present. Nobody is looking at long-range issues. Nobody is talking about things happening 4 months from now. Nobody is tapping their foot and asking “are you through yet?” The entire thing works on local optimization. That means that inside of sprints teams locally optimize to finish their commitments. It’s only at the boundary of sprints — demos, retros, and IPAs — that the big picture is important.

Finally, notice it doesn’t match the video. The perfect Agile/Scrum stand-up demonstration does not exist. Teams are different. Everybody has to adapt. As I said in the beginning, Agile is all about adapting. The point is to try things the “best” way — as the community has determined them — and then adapt for your particular situation. That way you don’t miss out on anything, and you also have good reasons for the way you’ve adapted.

Want to rock out your Agile team? Here are the e-books for you.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Tyranny of the Tools

As an agile coach, it’s been both a privilege and a pain to watch groups of extremely smart people blow themselves up.

The sad thing is that you can explain how this is all going to happen, you can plead with them not to head down this path, yet they do it anyway. What could have been a kick-ass team instead becomes a boring slog down old project management road.

And it all begins with automation.

That may sound strange. After all, we’re technologists, damn it. Our job is to take repetitive manual jobs and make the computers do them, right?

When I train people, we use post-its and index cards. We use painter’s tape on a wall. If we have a token for work that is to be performed — a story or a task — we jot a title down and plop it on the wall. This is called visual process control. It’s the result of decades of research and experimentation.

Or to put it bluntly, when my wife wants me to mow the lawn, she can ask, she can email, or she can make a bright red note and stick it on the refrigerator where I have to look at it every time I get a snack. Guess which one gets results. Make me look at it — even when I’m doing something else — and I’ll figure out a way to make it go away.

We find that things we look at — even in a casual, off-hand manner — are the things we think about. We also find that as we see things, we work on them in our mind in the background. We make a lot more progress letting our subconscious mind work on things while we’re busy with more important stuff, like technology development.

Still, there’s nothing like the gleam in a programmer’s eye the first time he sees a story/kanban board and physical risk/issue list. Note cards! On a wall! It’s like 1960 or something in here!

Then the gears start turning. Watching, I feel a terrible sadness, as if thousands of man-hours all screamed out at once, then were suddenly silenced.

There’s a reason why there are 40-thousand software implementations of Scrum/Agile on the web. Everybody who’s ever sat in a team room looking at the wall wanted to “fix” it.

Obviously a spreadsheet could handle all these lists and totaling up of things. And it’s not too hard to make a replica of a storyboard using some HTML5 and AJAX tools. Heck, given a few days, we could make a thing of beauty out of this — and make it easier to use too! Hell, I could be adding and completing stories on my iPhone! Taking some old, cranky, ad-hoc system using bubble gum and bailing wire and replacing it with a database and a decent front-end? This is the entire point of modern life! This is what we do! Why suffer?


So then — if we’re lucky — somebody does up a spreadsheet. Then everybody has to update the spreadsheet. Notice how the focus has moved. Instead of sitting in a room doing other things while the status of our project beckons us on the wall, we’re sitting in our cubicles filling out a spreadsheet once a day. The focus is on remembering to update a tool, not thinking about the status of our project. The tool starts running the project. It becomes the central source for finding out things. Not the people.

If we’re not lucky somebody writes a check for a more “powerful” tool. “Powerful” Agile tools usually have all sorts of fields, checkboxes, and whiz-bangs. They promise all kinds of benefits for teams — track your actual time! Track code changes against tasks! Roll up dozens of projects in a single bound!

So the job becomes completing the tool. Stand up? Well, that’s a reason to verify the tool has everything updated. Sprint closing? A detailed check to make sure the tool is in sync. Retrospective? A time to talk about updates to the tool. Do we need new fields? New reports?

It’s not us working the project. It’s us working the tool. Meanwhile, we still have the project to deliver. Agile becomes just another way to micro-manage and control.

Of course, I’m no Luddite. I love tools — as a means to communicate. There’s no better way to look at a team from a distance (when you can’t actually walk into their team room) than some sort of easily accessible online tool. So the team still works like it always has, using bubble gum and bailing wire, and each day somebody takes the stuff on the board and transfers it to a tool. The tool is never used except my remote workers as a way to visit the team room.

This is all just extreme fantasy on my part, of course. I’ve never seen a company that bought a tool that didn’t end up servicing the tool instead of actually being Agile. But I continue to hope.

There are people who love tools. These are the people who build them, sell them, or have a full-time job to maintain them. To them, tools are the answer to everything. How could you not love something that organizes so much data so easily? Weird thing — these people are also not the people who are actually doing the work.

When we create Agile teams, we create teams of real, live people. That means our control and communication systems must be built around the qualities and capabilities of people, not robots. We are doing much more in a team room than simply transferring abstract pieces of metadata around about a project. We are gaining a common emotional understanding of the problems and the players, getting a deep feeling for what might go wrong and what we need to worry about, adjusting our work patterns, our communication techniques, and our problem solving skills to this particular team, this particular problem, in this particular situation. There’s a hell of a lot of things that don’t appear on the walls — but that the walls remind us of. An Agile team isn’t a team that moves stories across a wall. It’s a team that looks each other in the eye and talks about things the Product Owner wants and how they’re going to give it to them. It’s a team that munches down on hot dogs and the conversation reminds somebody of something important so they reach up to add a new task on the wall. The stories, walls, and data are all just props to facilitate ubiquitous in-person human interaction. We take the ubiquitous in-person human interaction part out of it, we’ve killed the very thing we’re trying to improve.

If you’re looking for more balance and traction in your Agile team, take a look at the book I wrote on beign a ScrumMaster.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Don’t Know Much

I’m having lunch with my oldest son today. He turned 25 this year! It was a big birthday for him, and a big moment for me too.

Looking over the last 25 years, I can’t help but try to figure out what’s changed. Am I the same guy I was at 21? Of course not.

A lot has changed. I think one of the most interesting changes has been in the last five years. I’ve decided I don’t know very much.

Up until then, I studied a lot, learned as much as I could about something, then dove in and took charge. In the last year or two, however, as my startups start taking off and I finish up my agile/kanban book, looking back over all of it, I realize how little I actually know.

Please don’t think I have a lack of self-confidence: I’m still the arrogant asshole I always was. But now I don’t automatically assume that the world is the way I suppose it to be. Looking at dozens of teams get more productive — and some fail — has made me rethink what it means to construct success.

In the western world, many of us are model-builders. Give us the specs, the shape of the system in question, and we will build a mental model that emulates it. Then we work the model to see what happens. If that works, we move to the real world.

As an example, if you were coding a large client-server system in the 2000s, the first thing you should do is talk about your domain model — which concepts are important enough to be in the system and which aren’t. Based on that discussion, identifying concepts and their relationships, you could continue down the path of development.

Or take playing a video game. As we play, we construct a mental model of how things work. Pull that lever there and the door opens. Do these three things in order and you can do the forth, and so on. As our mental model gets more detailed, we are able to play the game better. Life, it seems, is just a series of models that we learn to some degree of fidelity and then master.

All of this is true, but as I continue writing my book and looking back on teams I have led or coached, it occurs to me that successful teams were always rebuilding models, not elaborating even more on pre-existing ones.

If you ever worked in a successful startup, you’ve seen project managers do what comes natural to them: take what works best from each project and combine it into a master “cheat sheet” of how good projects should operate. I have seen this several times. These are all well-meaning efforts, but in the end they all fail. They hurt more than they help.


I think it’s because the human mind naturally models way far beyond anything that might be actually true. We can see a butterfly in a meadow in the morning and have a 3-page poem dedicated to it by lunch. Or — a much likelier scenario — we can observe 3 or 4 projects that do well, identify commonalities, then extrapolate that to the universe of projects.

But it’s not just technology teams, that’s the kicker. We all do this, and we do it in every part of our life, whether we realize it or not. It was learning about startups that taught this to me. You’ll have an idea, try to sit around and decide if it’s a “good” idea, then, based on that judgment, elaborate on it some more. Maybe you write some code. Maybe, if you’re new to this, you write a lot of code. Perfect code. Use a bunch of TDD and have a rock-solid architecture and implementation. Make sure you’re able to scale. Pick the best problem to solve. Use a data-driven implementation. Pick the right corporate structure. Hire a lawyer.

How can I say this nicely? There are a thousand things you can do in a startup that don’t amount to jack shit. There are very few things that are important. All of them directly relate to getting customers.

You see, it’s easier for us — it’s more natural for us — to construct these models and flesh them out, turn them into reality — than it is to actually see the real world. The real world wants an iPod app that farts when you push a button. You and I may want a super-colossal app that ends world hunger, but nobody else will buy or use what we make, so in the end it doesn’t matter. But — and here’s the crazy part — instead of adjusting our work habits to try to continually find out what the world wants, instead we create more and more complex models or what we think they should want. We love models a hell of a lot more than we love feedback.

That’s why I think being stupid and humble is probably the best attitude for having a startup. I don’t know what people want, I actively resist learning, and the best I can do is struggle with that truth.

The same probably goes for the rest of life as well, although most of us (including me) are uncomfortable looking at it like that.

I don’t know much.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Other End of the Telescope

Ran across a very insightful quote the other day that I’m going to mangle and paraphrase:

The main goal for a technology team isn’t the product, it’s the recipe for the product.

Many times we act like the way technology is put together is known: all we have to do is come up with a list of things that need doing — creating this list is where we add value. How we work together, how large groups create a dynamic, productive environment is simply a matter of learning something and repeating it.

The opposite is true. Creating technology to meet some random list of things is a trivial exercise — sometimes a painful, never-ending, death-march, but a trivial exercise. There isn’t a lot of creativity going on. Heck, most of the time there isn’t a lot of computer science going on either, just connecting up the wires. The part that we add creativity to is putting together all of the different people we have in this particular situation and with this particular problem in such a way that the solution happens quickly and people are pleased with the result.

We have shortcuts that sometimes work — a lot of agile is about creating and sharing those shortcuts — but sometimes they don’t work. I’m seeing a lot of Kanban being used in certain situations because sometimes it beats Scrum. Sometimes not.

The technical part of technology development turns out to be a no-brainer: any decent programmer can do a heck of a lot of things. The people and process part of technology — the part they teach you in various classes, seminars, and business schools — turns out to be so brutally non-trivial that huge organizations fail for lack of mastering it. I believe the reason why is that once we take the class or get the certification we believe we understand it when in fact we do not.

It occurs to me in technology development that most times we don’t even know what the important problems are that we are solving, focusing on the technical, easy-to-grasp instead of the social, difficult-to-work.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Goldilocks Agile and Your Grandma

Goldilocks was very tired by this time, so she went upstairs to the bedroom. She lay down in the first bed, but it was too hard. Then she lay in the second bed, but it was too soft. Then she lay down in the third bed and it was just right. Goldilocks fell asleep.

As she was sleeping, the three bears came home.

Let’s say you were writing a letter to your grandma. Would you get out the user manual to the word processor you use? Perhaps spend a few hours going over how to create a Table of Authorities? Those manuals can be huge! Modern desktop word processors deliver hundreds or thousands of features, but 99% of people use 1% of them. You’re not writing a doctoral thesis; you’re just writing a letter to your grandma.

Does that mean we should throw word processors out the door? Never use them? Of course not, it just means that we separate the tool from what we are trying to accomplish.

Being a good grandkid, you decide to write a letter to your grandma every day. After a couple of weeks of this, one day your word processor breaks — you can’t use it any more. Do you stop writing letters to your grandma?

Probably not. Not if you love your grandma and have decided this is an important thing to do for her. You’ll just pick up another tool — ye old pencil and paper has been known to work very well for this — and write a letter to grandma. The tool is replaceable.

Let’s say you are in an auto accident. For the entire day, you’ve been sedated and didn’t get to write your grandma. Would you then say that your plan to write your grandma was bad, broken, or somehow defective?

Probably not. Not if you love your grandma and have decided this is an important thing to do for her. You’ll just start up again tomorrow.

You change jobs and find yourself with a new spouse and life. One long day, after spending time writing your grandma instead of doing other things, you ask the key question here: why are you spending all this time worrying about your grandma? Don’t you have better things to do? Seems like you are focusing entirely much on something that is not important.

At this point, you may decide that yes, you love your grandma, but it’s not effective spending an hour everyday writing her to let her know that. You could accomplish the same thing with a phone call every other day.

So what the hell does all this talk about grandmas have to do with Agile?

Just this: that we consistently confuse the tool, the ritual, and the principles.

An underlying principle of agile is to aggressively attack communication risk in order to tighten the feedback loop. The tool (one of many) is the conversation. The rituals include the story conversation, backlog sizing, or the daily stand-up.

So what if you’re in a team that’s distributed? Does that mean that stand-ups are dead? I don’t know, because I’m not you. Nobody else knows either. What I know is that the principle of aggressively attacking communication risk doesn’t go away simply because people live in different parts of the world, no more than you stopped loving your grandma because your word processor broke.

What if you’re in a team that’s writing exploratory code for a startup? Should you still use TDD? I don’t know, because I’m not you. Nobody else knows either. What I know is that the principle is that the later we test the poorer job we do of it, and that by knowing exactly what the code is supposed to do, we can use tests to make sure we are only writing code to do what is necessary. I also know the principle from the startup world is that 1-in-20 startups succeed, and that coding is a very, very, very small part of making people happy — even in products that require massive amounts of coding. My guess is that in unfunded startups with no traction you’re better off focusing on finding users and a market than in writing tight code, ’cause most of the time it doesn’t matter anyway. But that’s just a guess, and it’s just for a particular type of programming in a very particular kind of situation. The principle of startups being a long-shot doesn’t go away because of the principle of verifying code to make sure you only write what is necessary. You just need to have a conversation about principles to get that sorted out, not tools or rituals. Would you still write your grandma a letter everyday if she lost the ability to read? Probably not — but perhaps so. You have to figure it out.

What about if you’re in a marketing team without hard deadlines or a fixed product? What can you do to work better? The principle of a tight feedback loop doesn’t require a product. What do you think you’ll do today? Did you do it? That’s not just a stand-up, that’s a feedback loop. Maybe that’s all you need. Maybe the other rituals and tools don’t help you very much. Then don’t use them. Never give up your principles, but always be willing to ditch rituals or tools that aren’t working for you.

“But that’s not real Agile!” I can hear you say. If by a pre-ordained set of rituals, nope, it isn’t. But guess what? I favor Individuals and interactions over processes and tools, even if the processes and tools are “the real agile.” I’m funny like that.

A very smart man named Nietzsche once said “God is dead.” By that he wasn’t declaring himself an atheist: what he was saying was that any structure — tools and rituals — we put around the necessarily fuzzy concept of “God” is inherently broken. it’s self-contradictory at best, and actually harmful at worse. [Insert long rant about the harms and evils of organized religions from Nietzsche here.] In his eyes, it’s our inclination to keep trying to create structures and rituals out of the things we don’t understand that is itself the cause of much pain and suffering, not what people actually believe by themselves. We create our own prisons.

Agree or not with the old philosopher, what he said resonates in a lot more areas than just religion. Building technology products is a fuzzy and unsolved problem. We are always seeking to locally optimize for performance. Because of this, over and over again people discover the same principles at work: focus on customers, tight feedback loops beat loose feedback loops, visible work tracking encourages problem solving, etc. These folks write up these principles into various rituals: pair-programming, sprint planning, release planning, etc.

Other folks come along and learn the rituals, never realizing that the rituals are just instantiations of the principles. Perhaps they feel like they’re not expected to know. Perhaps their bosses think they’re unable of working on their own. Perhaps they are afraid of being in charge of their own destiny. I don’t know — but I know it is very sad to watch.

This is what we call “Cargo Cult Agile” — going through the motions hoping that, somehow, by magic the rituals will make things improve.

They never do.

I wish this was the end of things, but it gets worse: other folks come along and take these rituals and turn them into tools. The tools have all sorts of shiny widgets and do all kinds of neat data processing. There are seminars, workbooks, how-to guides, contests, and all sorts of other things to do with the tools.

We have started reading the word processor manual in order to write grandma’s letter. We are so far removed from our goal; instantiating some kind of regular practice to show our love for our grandma; that we may never find our way back. The tool becomes an end to itself. We are lost in the weeds, and we become the enemy of the thing we’re trying to help. We’ve become the bears instead of Goldilocks.

The thing is, it’s not like you don’t need tools. If you have 100 teams, you can’t visit them all at the same time. It is useful for many reasons to have a tool. It’s also not like you don’t need rituals: having something to train and get people started with is critical. But it’s not an all-in or all-out question: to phrase it like that is to be dishonest. A little bit of tools and rituals is incredibly awesome: it lets you do a zillion times as much. But too much or doing something simply because it’s on a list? It’ll kill performance faster than anything I know.

Just like Goldilocks, it’s up to you to experiment and try things until it is just right.

Then hope the bears never show up.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Applied Agile: Theory and Practice

“In theory, there is no difference between theory and practice. But, in practice, there is.” – Yogi Berra

Last week I got to hear Dean Leffingwell talk about “Scaled Agile,” the way that some Agile teams-of-teams are self-organizing into larger work efforts.

Dean was playing the role of “flamethrower consultant.” where you come in, announce that this what folks should be doing, that you will adapt and change or die, then logically take on all comers with a spirited defense of your vision of the future.

I love this role, as I have seen it executed several times to perfection. I’ve even attempted it myself from time to time, especially with skeptical audiences. Sometimes you persuade by hand-holding, sometimes you persuade by being a passionate informed advocate for a vision of the future that you’ve personally seen and want for your audience.

The problem here — and Dean doesn’t do this — is that it is easy to step over the line between “passionate informed advocate” and just “passionate advocate” — that we confuse passion for value. it’s a common thing to see in the process world. The passionate person blind to the realities of implementing theory has even given rise to the term “Agilista.” I’ve seen it among Scrum folks, Agile folks, RUP folks, CMMI folks, Six Sigma folks, and many others. When you have a hammer and you are passionate, everything in the world is a nail.

Of course, each of these things brings value to the table, and each can cause great harm. So how to sort it all out? Is it a yes-no question? Must we either do one thing or another? It’s very common to hear people say you have to choose, and that once you choose, you must do this new thing to the ultimate degree possible — that if it’s not done perfectly, all will collapse.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Metrics You’re Not Supposed to See

Now that I’ve ticked off half the agile community, let’s be fair. I should offer something back. You guys can trash this, copy it, or ignore it, whatever works for you. Just don’t say I never gave you anything.

Let me count the ways metrics have been presented to agile teams.

  • Agile Metrics don’t exist – Metrics are for waterfall teams
  • Nothing to see here, please move along. – Metrics for agile teams is just like metrics for regular teams
  • They’re like regular metrics, only cuter – Look! We use colored pens!
  • What we really need is an agile checklist – We need to know if people are doing agile the way they’re supposed to be doing agile. If so, there won’t be other problems
  • It’s all in there – Existing agile artifacts give you everything you need

Let’s cut the crap. The only metrics I really care about is: is the team worth the money they are getting paid? Do things get delivered in a way that the customer is ecstatic about? Is the team happy and productive?

I can make the obvious statement that if you’re worried about something, you should track it — at least until you’re not worried about it any more. But I’m not going to do that.

Or I can give you another platitude: you can’t manage what you don’t measure, you can’t measure what you don’t define, and you can’t define something without a common vocabulary and grammar.

But I won’t do that either.

Instead of defects-per-hogshead, or man-hours-per-story-point, let’s get down to brass tacks. Let’s make it personal. What do I use to measure teams? Certainly when working with a dozen teams or more I have to have some kind of insight into what’s going on. Something I can share with others. Some way of telling if I’m doing a good job, what the real problems are.

Well, what is it?

I’m about to show you two metrics. One is mostly useless. The second is terribly vague and confusing. Put together they do a pretty job of nailing down how to keep an eye on the agility of several teams at once. And most folks don’t want to see them.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Ruined My Life

I read the reply to my comment on a popular hacker board with sadness:

(disclaimer: Agile consultants ruined the software group I work in.)

Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up

Reminded me of an email I received back in May:

[We] started working on [agile technique X] when [author]‘s [famous book] was just a draft. I was on that project and worked on Agile Projects for a decade. (Next time you meet [famous guy], ask about me, I just finished reviewing his forthcoming [another famous book]). I am a founding member of the Agile Society of [place] and have organized conferences on Agile. I’ve attended XP Conf as well. I’ve probably worked in more agile projects than you ever have (not that it particularly matters). So let us first dispense with the notion that your notion of what constitutes “true” agile and its scamsters is somehow the only standard….

Do you deny that the whole Scrum Master idea is a scam within the Agile Camp?

Scamster? Ron Jeffries the guru/founder of Agile couldn’t write a Sudoku implementation with his favorite technique “TDD” and refactoring over five weeks. Fraud.

Robert Martin (another “guru” and agile consultant) claims that any code not written with TDD is “stone age ” code including such things as Unix and such people as Norvig and Linus and Zawinski who’ve built more code than he can dream of. Dalke poked holes in his TDD “kata” which never got answered Fraud.

I could go on and on. And these are the gurus. But that isn’t the point. i *saw* “agile consultants” evolve from some naive but well meaning people (like Kent) to scamsters like X and co and tose are just at the top. Practically every single “Scrum MAster” is a fraud. The more intelligent among them admit that two days of listening to a higher level shyster teach nothing and it is just a signal to dumb managers to improve their chances of getting a project. Yet they go along. That in my eyes is a scam like chiroproctors or reiki people claiming to be doctors. Agile was amovement founded by scamsters and propagated mostly by scamsters.

I’ve had many such conversations over the years.There are some seriously pissed off people about Agile out there. Why? Isn’t agile supposed to be warmth, apple pie, motherhood, goodness and all of that? Why so much anger?

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Project

In the Beginning was the Project

And then came the Assumptions

And the Assumptions were without form and void

And the customer conversation was completely without substance

and the darkness was upon the face of the workers

and they spoke among themselves, saying

“It is a crock of shit and it stinketh.”

And the workers went unto their Supervisors and sayeth,

“It is a pail of dung and none may abide the odour thereof”,

And the Supervisors went unto their Managers and sayeth unto them,

“It is a container of excrement and it is very strong,

Such that none may abide by it.”

And the Managers went unto their Directors and sayeth,

“It is a vessel of fertilizer, and none may abide its strength.”

And the Directors spoke amongst themselves, saying one to another,

“It contains that which aids plant growth, and it is very strong.”

And the Directors went unto the Vice Presidents and sayeth unto them,

“It promotes growth and is very powerful.”

And the Vice Presents went unto the President and sayeth unto him,

“This new project will actively promote the growth and efficiency

of this Organization, and in these areas in particular.”

And the President looked upon The Project,

And saw that it was good, and The Project continued many generations, and many were overpowered at the size, ineptness and illogic of it

And this is why you are here

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.