Scrum - Are you a chicken or a pig?

Since I just learned about Scrum, it seems to me that for part of the iteration, you can be a chicken, and then become a pig when the time comes to make your part. Then go back to the hens. Is that the right way of thinking? What will your iteration rate change during the iteration? if not how does it work? because when the software is built, it is planned, encoded, tested, updated, then it is done. Am I mistaken in my thoughts? Thank you

+6
project-management scrum agile methodology
source share
9 answers

If you are not in the team and stakeholder of the project, then you are not both.

Pigs - Scrum team members - product owner, scrum master, developers, testers, etc.

Chickens are people who need a product - customers, managers.

The only time I see where a person is is when the product is for the team. Then the team is not only pigs (doing the work, putting all this in a line), but also customers who want to get the product.

+13
source share

You are a pig if your ass is on the line regarding project success or failure.

+3
source share

During the iteration, you are either a pig or a chicken - you cannot be both. Since team members are participants in the sprint, they should always work on lagging the iteration.

Assuming that by the term โ€œIterationโ€ you mean the time period set by the team to create the potential gain in a profitable product (also known as โ€œsprintโ€).

+2
source share

Based on my experience and understanding of SCRUM, your role should not change during the sprint. Either you are a chicken or a pig.

A pig is the one who gets the job (for example, the developer), and the chicken is the one who gets something from the pigs doing their job (for example, the owner of the product).

EDIT: Just found this "definition" of chicken and pigs: The classic story of pigs and chicken

+2
source share

In my opinion, you are either a chicken or a pig, it does not change during iteration / sprint.

If your roles in the experiment change so, your sprints are probably too long, or the person is really a chicken all the time.

+1
source share

There is an article by a pig and chicken that states:

I would consider the roles of both Product Owner and ScrumMaster for being pigs on the team.

Wikipedia says that the product owner, Scrum master and team are pig roles, and the stakeholders (customers, suppliers) and managers are chicken roles.

Based on this, I would say that usually you do not change between a pig and a chicken.

+1
source share

Summary: swapping roles for pigs and chicken during Sprint may jeopardize the initial contract concluded before it began, thereby jeopardizing successful delivery.

The pig and chicken concept is just a Scrum metaphor for what is otherwise known in project management as the direct and indirect stakeholders of the product development cycle.

A short, memorable and funny story about a pig and a chicken.

to managerial fervor.

One of the greatest things about Scrum is that it makes current management technology available to non-managers. Delivering it in consumer or user form, as we talk about software systems.

So can a chicken (indirect participant) turn into a pig (of a direct stakeholder) and vice versa during the development cycle? Can a person be chicken and pig at the same time?

Responding to the latter, this is a definite โ€œnoโ€: a person can only be a chicken or a pig in the context of one project, depending on which rate is higher. The idea of โ€‹โ€‹a whole chicken and a pig is to give greater decision-making power and responsibility at the project stage to people who are directly involved and interested in a positive outcome (pigs), limiting interference from sometimes powerful external players (chickens).

Can a role change during a project? Yes, it is possible, but not during Sprint . Scrum is an Agile development methodology whose goal is to share responsibility for the outcome across the team. Agile (and especially Scrum) promotes "one-man and one-on-one." Not all structured methods do this, for example, one of the Waterfall drawbacks is that the responsibility of some team members ends as soon as an intermediate result (i.e. a functional specification) is accepted, which shifts the weight of any problems that penetrate the project much more on the shoulders of unhappy team members who are responsible for the successful implementation of the project at later stages of development (usually developers).

The Scrum iteration, called Sprint, aims to completely change the specification for a ready-to-use product, rather than some kind of intermediate result. The team makes a lot of contribution to the decision about what is included in the Sprint, and subsequently must commit to implement the changes. This creates a contract between the team and the outside world.

Changing roles during Sprint may jeopardize this contract. If the pig becomes a chicken, he or she is no longer responsible for seeing how Sprint completed the job, putting the burden of dealing with any imperfections in his work on the shoulders of the remaining team members. When a chicken becomes a pig during a sprint, they cannot really agree on what was agreed before they came on board. Therefore, it is best when the roles remain unchanged for the duration of Sprint.

+1
source share

In the team that makes the Scrum book, you can only be a chicken or a pig during the sprint. And, probably, most Scrum Gurus will tell you that Teams should not change between Sprints.

If you are part of a team, your bet cannot change during Sprint - because it is the whole team that is responsible for the piece of potentially supplied code that you made to produce. If you think like this: "I am responsible for the backend part of this function, which will be built in the first half of the sprint," you are on the wrong track.

However, doing Scrum on a book without thinking about what suits you might be the wrong decision - you may have some team members who are very valuable but also have other responsibilities (not very good, in my opinion).

0
source share

I work mainly with startups, including one of my own. In all cases, I play the role that Lean Development calls the "Chief Engineer" or "Product Director." I am a leading technologist, as well as product manager and customer voice. If you have such a person in your organization, then you may not need to separate the roles as strictly as Scrum Orthodoxy suggests, and you can start using methodological traditions and approaches that do not have to be blocked as often happens in Scrum.

0
source share

All Articles