Tag Archives: myths

Video: Sprint Zero is Not Part of Scrum

Learn more about transforming people, process and culture with the Real Agility Program

Find out why Sprint Zero is a bad idea, and what you can do instead!

More Scrum and Agile videos to come!  Please subscribe to our WorldMindware channel.

Please share!

New Video: Myths of Scrum – A Public Retrospective

Learn more about transforming people, process and culture with the Real Agility Program

Although subtle, having a public retrospective can do terrible damage to a Scrum team.  In this video I explain what I mean by “public”, why it is so bad, and what you should do instead.  This is part of a video series on the Myths of Scrum that is meant to respond to some of the most common mis-information (myths) about Scrum and Scrum practices.  I will follow-up this video in several weeks with a written article complimentary to this video.  Feel free to let me know in the comments if you have any topics that you would like me to cover in my video series!

Please share!

New Video: Myths of Scrum – ScrumMaster Assigns Tasks

Learn more about transforming people, process and culture with the Real Agility Program

In a few weeks, I will be posting a more detailed written follow-up to this video.  This is one of the most damaging and most common myths (or pitfalls) that ScrumMasters fall into….

Please share!

Sometimes I Just Need to be Pedantic

Learn more about transforming people, process and culture with the Real Agility Program

Here’s an article that just drives me nuts: Using Agile Scrum to Manage Developer Teams. The problem I have with this article is that it is just crazy bad in its use of language and ignorance about the fundamentals.  Here are some examples:

Agile Scrum

This is not a thing.  Agile is a philosophy of doing software development.  Scrum is a particular instance of Agile.  Saying “Agile Scrum” is kind of like always saying “furniture table” instead of just “table”.  It shows a pretty fundamental gap in the writer’s knowledge.

As with any software development lifecycle (SDLC) framework…

Scrum is definitely not an SDLC.  Scrum is a framework (and the author uses the term correctly a little earlier in the article) but is deliberately missing most of the details that would make it an SDLC.  It is designed to be incomplete instead of complete.  SDLC’s are meant to be complete solutions for delivering software.  Scrum shows you the gaps and exposes the problems you have delivering products but doesn’t tell you how to fill in the gaps and solve the problems.

Next, the article mis-quotes Scrum.org by incorrectly capitalizing Product Owner and Scrum Master.  And in some sort of ironic error, puts “Scrum master” in quotes.  Yikes!

The conclusion of the article about when you might choose not to use Scrum is also a bit mis-guided.  There are lots of organizations successfully using Scrum in highly regulated environments: medical, banking, government, etc.  Some of them are even my clients!  I would be happy to provide direct references if needed.


Does your team work remotely? Despite advances in video technology and online collaboration tools, the requirements for structured daily contact makes Agile Scrum tough to implement successfully for virtual teams.

Yes, remote work is bad with Scrum.  But it’s also just plain bad.  Don’t do it if you can avoid it.  All that Scrum does with a remote team is show you just how bad it really is.

Please share!

Agile/Pervagile on Slashdot

Learn more about transforming people, process and culture with the Real Agility Program

There is a book review of “Becoming Agile” by Smith and Sidky on Slashdot.  I haven’t read the book (yet) so I can’t comment on the book nor on the review.  However, I did want to comment on the comments of Slashdot users.  Their experience with agile methods seems to be terrible.  Either that or they are incredibly ignorant and have pre-judged agile.  Since I know that (most) Slashdot users are pretty intelligent, I’m going to assume that they have mostly just had really terrible experiences with agile.

The Agile Manifesto values “Individuals and Interactions” over “Processes and Tools”.  Many of the comments were about agile being used as a cudgel to beat teams into submission.  No matter what anyone says, this is not agile.  This is perverted agile or “Pervagile”.  Pervagile is common.  Scrumbutt is one form of Pervagile.  Waterscrum is another form of Pervagile.  Scrummerfall is yet another.  But there are many other forms as well: the Pervagile Sweatshop where teams are forced to meet arbitrary scope in one week deadlines, the Pervagile Common Room where people on many different projects are forced to work in an open space, and the Pervagile Silo Team where only developers are doing agile and everyone else is in their normal functional silos.

On Slashdot we see some interesting comments like this one:

So we’ve gone from over-designing systems to under-designing systems.

How about right-designing a system based on the complexity of the scope and the key personnel involved?

Is that crazy?

No, it’s not crazy, and that’s what agile is trying to help us to do.  Pair programming, test driven development, potentially shippable software, continuous integration, agile modeling are all agile practices that help us “right-design” a system.  So this person must have experienced a team doing Pervagile Minimum Discipline where all good practices are not just done in small bits along the way, but actually ignored.  I’m not sure why they ignored doing good incremental design – perhaps someone told them that agile doesn’t require good design skills on the team!

Here’s another interesting comment:

The attempt to write a Python implementation in Python, PyPy [codespeak.net], turned into a death march. The project has been underway since at least 2003 (when they had their first “sprint”), never produced a usable system, and the European Union pulled the plug on funding. But the project limps on. There’s a released version. It’s slower than CPython. There’s supposed to be a “just in time” compiler Real Soon Now. (This is try #2 at a JIT, not counting the schemes for outputting Java bytecode and Javascript.) Six years in on a compiler project, and no product.

The PyPy project is very “agile”. They have “sprints”. They have “flexibility”. They have nightly builds. They have mailing lists and trackers. They support multiple output back-ends. They have about 50 contributors. What they don’t have is a usable product.

Hmm.  Sounds like they’re trying to do Scrum.  But they’ve missed a pretty critical piece: potentially shippable software at the end of _every_ Sprint.  I have no idea why they aren’t able to do that, but I imagine that if they really understood Scrum, they would be in a much different place at this time.  This is a clear case of Pervagile Valueless Deliveries where the team does stuff every iteration, but they don’t worry about delivering valuable results.

So.  Pervagile is pervasive.  That’s clear.

Why is it so pervasive?  There are two parts to this: one, agile is hard and two, agile is mistaken for a silver bullet.

Agile is Hard

Okay, I’m actually being a little dis-honest.  The real truth is that doing agile is extremely, exceptionally, agonizingly difficult (for most people in most organizations).  Why?  Because agile is not just another process to roll out.  It is, as has been mentioned in numerous places, a deep cultural change.  Agile is actually a liberation movement for people involved in software development.  Like most movements, however, it has been subject to corruptive forces.

Agile is Mistaken for a Silver Bullet

Agile is Hard, and therefore it cannot possibly be a silver bullet.  Many executives and managers hear about agile and want to do it in their organization because they have heard the amazing success stories (yes, they do exist – scroll to the bottom to learn about Wildcard Systems).  But what often is not effectively communicated is how much crisis, how much effort, how much radical change went into these success stories.  Here’s a hint: if you think a large organization can become agile in less than five years, you’re fooling yourself.  Even a very small organization should expect at least two years of solid effort before the changes really take hold.  Of course, if you are lucky enough to be starting from scratch, then you might do better than this.

I’m pretty tired of people mis-understanding agile methods.  But unfortunately this is the reality of our work landscape.  I would love to work with a client where the CEO has said something to the effect of “I’ve budgeted 10% of our operations and ten years to do our agile transformation.”  Of course, that’s pretty much a laughable wish.  Unfortunately it’s the reality of the effort involved for most organizations.

Please share!