|
|
… I am sorry if you have received bad links for the past two weeks.
In an agile fashion (smile?) I put up the initial links to the cartoons with bad headings. I am pretty sure it is all figured out. Please accept my apologies.
Here are the official links for the first two cartoons in the series:

Next, think about the following example.
I have had — and continue to have — the opportunity to work with some great people within the Agile Community. One of my main mentors is Scott Ambler (of Agile Modeling and other methods and practices). He sums up one aspect of Agile Modeling (AM) by stating:
“AM is not a Silver Bullet. Agile modeling is an effective technique for improving the software development efforts of many professionals. That’s it, nothing more. It isn’t magic snake oil that will solve all of your development problems. If you work hard; if you stay focused; if you take AM’s values, principles, and practices to heart; then you will likely improve your effectiveness as a developer.”
Let me see how his statement applies to Scrum… I will interject “Scrum” in the place of “AM” in order to show the power of Agile stuff in general [and of course, this is a good use of re-use].
“[Scrum] is not a Silver Bullet.”
What is a “Silver Bullet?” Wikipedia defines one as, “The metaphor applies to any straightforward solution perceived to have extreme effectiveness. The phrase typically appears with an expectation that some new technology or practice will easily cure a major prevailing problem.”
Can you see how Scrum can be misconstrued as a Silver Bullet? It is easy. Common sense stuff. C’mon Mike, give me a break [you may be thinking]. Read on…
“[Scrum] is an effective technique for improving the software development efforts of many professionals.”
As Scott says, “That’s it, nothing more.” This is a powerful statement in its total simplicity. Really. Think about it from a professional standpoint and which type of teams usually implement Scrum. Hmmm. See a common thread there?
“[Scrum] isn’t magic snake oil that will solve all of your development problems.”
If anything, Scrum helps you surface problems — development or otherwise — fast. Sometimes too damn fast. One of the things I tell teams is there is a learning curve for both them and the people outside the core team (remember, those people are called “Chickens”). Have you ever personally seen what happens to a chicken when it’s head is cut off? It keeps running as if its head was still on the body. Ummm… where am I going with that one? Work with me here [semi-tangential but relevant!].
I attended an Open Space Conference a few weeks ago and facilitated a discussion about the following topic:
“How to use the “F” word effectively in your organization.”
The “F” word I am referring to is this [drum-roll please]…. Failure.
But Mike, you say, my organization cannot afford to fail on any projects. Please hold. Listen to this thought all the way through…. Some projects fail. Say it with me now. Big or small, some projects may fail. Sometimes these are run as Traditional Waterfall projects and sometimes they are run in an Agile manner. This is real life stuff.
So, how can you use the “F” word effectively if you are introducing an Agile Methodology (for example, Scrum) into your own environment? First, convince yourself that the project can be a success. Then, make sure you communicate out to the various stake-holders that you are not planing on failing the project. Ever. However, what Agile (and in this case Scrum) allows you to do — and this is powerful — is to find out early in a project where the mistakes are hidden.
Does this mean the overall project will fail? Maybe. But, if I were responsible for delivering a large project in six months I’d really like to know EARLY and OFTEN where the land minds are hidden — and get them exposed as soon as possible. Clear them. Early and often.
This technique does, in fact, clear the way for delivering successful projects. And, you fail early and often. In a good way. Scrum is designed to do this for teams. Make sense? Think about it…. reflect on it. Why? Because by being clear on this concept, this can be an effective tool to communicate to others when they start asking questions about using the “F” word. You can read more about “Why Agile Works” for more information and background information.
OK… come back with me from my tangent to Scott’s final statement about AM.
“If you work hard; if you stay focused; if you take [Scrum’s] values, principles, and practices to heart; then you will likely improve your effectiveness as a developer.”
Scrum looks easy. Common sense stuff. Right? Then why do organizations — and the people within them — hire people like me to help them transition to this technique? Two words: “Change Hurts.” When I am training new Scrum Masters, one of the topic titles in my workshop include those exact words. When we first introduced the topic into the course material, we were not sure where it would lead. It needed to be discussed. So we did. Wow. I will get into some of those topics at a later date, I promise (smile).At the end of the day, take this away from the comic strip above. Scrum is not a Silver Bullet. It was never meant to be that. And as someone who is interested in practicing this technique — or for those of you who are practicing this on a daily basis — be a professional and do not promulgate this metaphor.
Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Forum to discuss this cartoon and other Scrum topics. Thank you!
September 25, 2006

|
![]() |
Welcome to the inaugural cartoon on www.implementingscrum.com. Since the original publication of this cartoon series (starting September 11, 2006) I have made a few updates to the content of this page.Nothing has materially changed since we started the series; if anything, I hope it adds clarification to the overall content! This story is the first in an ongoing series to help explain what Scrum “is.”
And.
What Scrum “is not.”
Will we get it correct all the time?
Probably not. And that is OK. The plan is for all of us to learn.
Your comments are always welcome.
So, why are we using a Chicken and Pig? The story depicted above, as weird as it is, helps me — and others — explain two of the main types of people in Scrum.
I am amazed that the Human Resource Departments of many companies I consult with have not shut down this example; it is probably only a matter of time. This is still the best example I know of to explain the roles, and this is what our cartoon series reflects.
The basic premise of the Chicken and the Pig can be seen from the cartoon example above.
Here is an easy definition of the Chickens versus Pigs.
A Pig is someone who has skin in the game. Mike Cohn aptly refers to the people in that role as, “Having their Bacon on the line.”
Pig roles are considered core team members. Performers. People who “do” work.
Get it?
I would consider the roles of both Product Owner and the ScrumMaster to be pigs on a team.
A Chicken is someone who has something to gain by the Pigs performing, but in the end, really do not contribute day to day to “getting things done.” Their “eggs” are a renewable resource, and many get laid (eggs that is).
I get asked the following question by many people when starting to use Scrum:
“Can I be a Pig and Chicken at the same time?”
No.
You cannot be a Pig and a Chicken at the same time.
This is something I work with middle managers who struggle with this on a daily basis. The concept takes coaching, and constant [gentle] reminders that they cannot be a Pig/Chicken. I call this a Pigkin… and it is something you do not want to see in any organization!
A video commentary of this cartoon can be viewed here (it was posted February 16, 2008):
Meet the rest of our cast in this series!
We will examine this and other issues in this series, as this is fun to see happen (sometimes sad WHILE it is happening, but funny to imagine).
I do hope the simplicity of the cartoon above gets the point across. Remember it. It will serve us well in the journey ahead.
Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Forum to discuss this cartoon and other Scrum topics.
Thank you!
Originally Published:
September 11, 2006
Updated:
May 1, 200
October 23, 2007
February 16, 2008 (with Video)
More:
November 29, 2006



