Well, actually…

Kanban board != any vertical surface with cards stuck to it

1. Kanban is the latest cool buzzword.
2. We want to be (perceived as) cool.
3. Therefore, our card wall is a Kanban board.

Well, actually…

No, it isn’t.

Architect != any relatively senior-level job title, even if it has nothing to do with architecture

1. Fresh out of Foo School: I’m a Foo One.
2. Two years later: I’m a Foo Two.
3. Two years later: I’m a Senior Foo.
4. Two years later: I’m a Foo Engineer.
5. Two years later: I’m a Senior Foo Engineer.
6. Two years later: I’m a Foo Architect.
7. Two years later: I’m a Senior Foo Architect.

Well, actually…

No, you aren’t. You just a Foo with a fancy title.

“Agile” or “Lean” != whatever we were doing (or selling) before, with a fresh coat of paint

1. Our Gantt Chart software supports agile project planning.
2. We’re doing agile big design up front.
3. Our project is using a waterfall process, but we’re doing it in an agile way.
4. We don’t need to use sound software development practices, because agile development is all about values and culture.
5. Our project team is agile. Every morning, we all stand up and give our status reports to the project manager, and he gives us our assignments for the day.
6. We found a Lean way to improve Process Cycle Efficiency: Ignore non-value-add time during process steps. Besides, as long as we’re thinking about working, we’re adding value to the product, right?

Well, actually…

1. No, it doesn’t.
2. No, you aren’t.
3. No, you aren’t.
4. Yes, you do.
5. No, it isn’t.
6. Gosh, you’re adding value to your product right now, aren’t you? Impressive!

Refactoring != any sort of change made to any sort of object for any reason

1. I’m refactoring my desk. It’s a mess.
2. I have too many emails. I’m going to refactor my inbox.
3. I want to refactor my old Volvo into a new Mercedes.
4. This weekend I’m going to grab the lawnmower and refactor the grass.
5. We’ll refactor the application so that it displays custom screens based on user preferences.

Well, actually…

1. No, you aren’t.
2. No, you aren’t.
3. When you figure out how to do Ferraris, let me know.
4. No, you aren’t.
5. No, you won’t.

Story Points != a euphemism for time-based task estimation

1. We’ve pegged a “story point” to one hour of clock time. It makes story sizing so much easier!
2. If we know how many work hours our team will be available next iteration, we can calculate how many story points we’ll deliver.
3. After we’ve done our bottom-up task estimation in terms of time, we can roll that up into “story points.”

Well, actually…

1. That’s not a “story point,” it’s called an “hour.”
2. If you know how many work hours your team will be available next iteration, then you know how many work hours your team will be available next iteration.
3. Yeah, roll it up and smoke it. Your iteration plan won’t be any worse, and you might feel better.

Velocity != a bludgeon for beating more work out of a project team

1. If we divide the total scope (in story points) by the number of iterations, we’ll know the velocity the team has to set in order to make the deadline.
2. If the team can’t achieve the velocity target dictated by management, it has to be because the team is either incompetent or lazy.
3. “Continuous improvement” means challenging the team to increase velocity by 20% per iteration. That will inspire them to try harder.
4. If Team A delivers 50 story points per iteration and Team B delivers 40, then Team A is better than Team B.

Well, actually…

1. Sure. They’ll just “set” the velocity and punch the “start” button. No problem.
2. It could be both, right?
3. Yes. They’ll try harder to game the numbers.
4. Be sure and remember that at bonus time. Team A will appreciate it, and so will your competitors, where the members of Team B will be working. And just watch Teams C and D adjust their estimation process. They’ll be delivering hundreds of story points per iteration!

Persona != a cool-sounding synonym for “actor” or “user type”

1. Our application has four personas: Member, Guest, Administrator, and Back-End System.
2. The only persona we need to satisfy is our boss…

Well, actually…

1. Okay, but how many personas does each of them have?
2. …and all he cares about is scope, schedule, and budget.

Productivity != effectiveness in delivering value

1. Our manager says she’s focused on business value, customer satisfaction, and product quality; but all she measures is productivity: Quantity of output per unit time. So, we generate as much crap as we possibly can.
2. Everyone needs to be 100% utilized at all times. If anyone is ever idle, it’s a waste of money.

Well, actually…

1. “Tell me how you will measure me, and I will tell you how I will behave.” (Goldratt)
2. True, if your corporate mission statement is “Keep all employees busy all the time, even at the expense of throughput.”

“Do the simplest thing that could possibly work” != build the easiest part of the solution first, then change jobs

1. There’s no need to handle exceptions, as that would make the code less simple.
2. If we keep delaying implementation of the challenging parts of the solution, maybe they’ll cancel the project before we need to worry about it.
3. If John spends 20% of his time at work searching for a new job, he might not find one before we get to the complicated part of the solution; if he spends 80% of his time searching for a new job, he can find one before things get too difficult around here.

Well, actually…

1. Obviously.
2. Hope is not a plan.
3. That’s a great example of the 80/20 rule. I hope John is a good multi-tasker.

Test-Driven Development != manually testing the whole application after the fact, or maybe just thinking about testing it, or maybe just hoping someone else will do it

1. I use test-driven development: After the users test my code in production, I drive back to work to fix the bugs.
2. I’m “test infected.” Whenever someone suggests I test my own code, I start to feel sick.
3. Test-driven development is just a cheap knock-off of design-by-contract.
4. I’m a socially conscious programmer. I don’t want to throw all those testers out of work. They have families to feed.

Well, actually…

1. Wonder if you’ll upgrade your software development practices once the price of gasoline hits $5.00 per gallon.
2. Funny thing, whenever you’re out sick the rate of technical debt accumulation declines.
3. Maybe so, but have you ever tried to enforce a verbal contract?
4. All hail Saint Bugger, The Prolific.

“Best Practice” != an excuse to stop thinking about improvement

1. I learned best practices in school. That means I already use the best possible practices.
2. I read about best practices on the Inter-Web. That means I already use the best practices currently known.
3. I’m an Ace Programmer. If I don’t already do it, it isn’t a best practice.
4. Your best practices might not be my best practices.

Well, actually…

1. You mean, you already use the best practices you know of.
2. You mean, you already use the best practices you know of.
3. You mean, you already use the best practices you know of.
4. You mean, you already use the best practices you know of.