Scrum Needs More Than Just Chickens and Pigs

March 21, 2010 2 Comments

If you’re reading this, I assume you already know the “chicken and pig” roles in Scrum.  If not, go here to check it out.

Okay, pigs have “skin in the game”, and chickens…well…don’t. Since some people hate the chicken and pig metaphor, I’ve also referred to it is “committed” (pigs) and “interested” (chickens) (I didn’t come up with this, but I don’t remember who did).

The chickens are not allowed to talk in the daily Scrum meetings. They are only allowed to provide feedback in the Sprint Review (and of course at any time to the Product Owner, Scrum Master, or as requested by the Team).

I think there are two kinds of chickens. There is the kind that provide no valuable input. They historically have done nothing other than cause distractions. Whatever it is your building may have an indirect impact on their lives at best. These people are typically in some kind of management, or senior role.

The second kind of chicken are those folks we typically refer to as “SMEs” (Subject Matter Experts). We may or may not be building a solution for them. However, we rely on their expertise to enable us to deliver value. These kinds of chickens are usually are involved in legacy application development or re-platforming efforts. You probably won’t experience this group if you are doing new development. These types of chickens are needed when the Scrum team just does not have enough of the institutional knowledge needed to consistently deliver value.

Both of these types of chickens have one thing in common. They do not have “skin in the game”. If the project fails or succeeds, there typically will be little (or no) consequence for them. What they do NOT have in common is this; the involvement (or lack thereof) of the second kind of chicken can either bring a team to success, or to a miserable failure.

Teams will typically lump both types of chickens together and treat them the same way. It’s really insulting if you think about it. If I was *critical* to the success of a project but am labeled a “chicken”, and if I identify a risk, I shouldn’t have to wait to speak until spoken to (which is implied with chickens), or until the Sprint Review.

What do we call this third group? They really aren’t chickens as defined in the Scrum context. However, they aren’t pigs either since they aren’t the Product Owner, Scrum Master, or Team (those who do the actual work). We will fail without them.

Advertisement

Filed under Process, Roles, Scrum, Teams Tagged with ,

The Role of the Architect in Scrum

December 29, 2009 1 Comment

This question comes up over an over, so I thought I’d address it quickly.

Remember that in an ideal Scrum team, the team is completely self organizing.  There are no titles to worry about.  The team will discover the strengths and weaknesses of each member, and continuously evolve, i.e. inspect and adapt, to discover new ways of delivering high quality value to the business.

But, guess what.  In the real world, we have titles to deal with.  Now, I don’t think that’s such a bad thing.

As we all know, the title “Architect” in the context of software means very different things given the organization.  I’ve seen it range from really good coder to more of a project manager-y type of position.  I think this lack of clear role in the industry overall has lead the folks in this title to, at times, become “chickens” that like to cluck and flap their wings to distract the team.

So, what should the architect do?  Well, let’s remember that in Scrum, team are self organizing.  They collectively come up with the technical solutions.  They also come up with development standards.  If the team is generally not high performing, or are missing some necessary skills, then the architect should be a mentor and a coach for that team until they can fly on their own.

What if the teams are high performing?  If there is an organizational need due to a highly complex business need, i.e. insurance, taxes, financial transactions, etc., then the architect should focus on the high level roadmap to ensure that the backbone of the technology is strong.  This is especially true in a SOA environment.

Filed under Roles, Scrum Tagged with , , ,