If you have been involved in an Agile/Scrum type project for longer than 10 seconds, it is highly likely that you have heard the term chicken and or pig. I will run the risk of being redundant in order to make sure no one is left in the dark about chickens and pigs, seasoned Agilers, bare with me. Once, a chicken and a pig were having a conversation. Let’s skip the fact that chickens and pigs don’t usually talk, much less t o each other. The chicken says to the pig: “Hey Pig, I have an idea. Why don’t we open a restaurant together.” To which the pig in all of his infinite piglike wisdom replies “Hmm, I don’t know, what we would name this restaurant.” The chicken replies quickly with “How about we name it –Ham –N- Eggs.” The Pig then says without hesitation “Nope, I’ll have no part of that thank you very much. I’d be COMMITTED, but you would only be INVOLVED!”
In football there are a group of people numbering in the millions who scream, jump up and down, wear t-shirts, paint themselves the team colors, have cookouts in the parking lots and generally act a fool during the game. It can be said that these fans are involved. But because a fan doesn’t have to take a hit, catch a pass, run the ball, make a tackle or take a cortisone shot for that for that matter, he or she is not committed. The fans’ stats are not updated at the end of the game, that don’t get another win/loss added to their record.
Agile is the same way, there are people who are committed to the delivery of your project and there are people who are involved in the project. Typically speaking the delivery team are the committed individuals and we call those people pigs. They are tied in every which way to the delivery of the product and will be served as bacon if the delivery doesn’t happen. Basically all other individuals are considered chickens. This concept really comes to light during your daily stand up meeting. During the standup meeting anyone can attend, however only the pigs can talk. This is something you want to make sure to enforce in your standup, or your standup meeting can become a runaway train. Because just like fans at a football game; chickens in a standup tend to make the most noise. Now, I will say it is imperative that you explain the chicken pig story to those newcomers. In these days of hyper political correctness, you want to make absolutely sure you all parties are on the same page before you call a grown woman a chicken, and God forbid – A PIG! Just be prepared to get looked at funny…. Just trust me on this one, you don’t want that!
Scrum teams have a tendency to discount the voice of the chicken because of the roles. I would encourage you to keep this in mind, while fans are not on the field, it would be foolish to think that they do not influence the outcome of the game. Both in the NFL (National Football League) and the NBA (National Basketball Association), statistically there is a difference in home team advantage for both regular season games and the percentage jumps 10 points or more for playoff games. While there can be numerous reasons why, the presence of the fans would have to be included in the overall equation. Simply put, fans (and chickens) are part of the team as a whole, they may not be directly responsible for the day to day outcome, they don’t write code, but they are very valid. How much fun would it be playing in the super bowl to an absolutely empty stadium? No screams, no cheers, no boos, no wave, no nothing. How much fun is that? None at all!
So the moral of the story is simple; pigs, value your chickens! They complete the meal. After all, you are the reason they crossed the street to begin with. Go marinate on that. Keep ‘em happy, keep ‘em involved and most of all…. Keep it Agile.
In Agile development the most often used opportunity for regular inspection into the project is the daily standup meeting. For those that are not familiar with a standup, this is a 15 minute DAILY meeting in which members of a delivery team gather, usually in a circle, to answer 3 questions. 1.) What did I get accomplished since the last stand up? 2.) What do I plan on accomplishing before the next stand up? 3.) What are the roadblocks I am currently experiencing that may impede my progress? I have personally seen several takes on this meeting as far as the timing. I have seen a weekly meeting, three times a week and twice a week. In my experience, having the meeting more infrequently does not help, it’s called a daily stand up for a reason. Deviating from the daily-ness of the meeting seems to have a dragging effect, so keep it daily if possible.
In comparison, a football huddle is not too far from this concept. In an American Football team huddle, a team gathers together, usually in a tight circle, to discuss strategies for the very next play, VERY quickly. The discussion is usually what happened on the last play – “Hey, good run on the outside, I think we have a mismatch with #30” What is going to happen on this play – “Let’s go straight up the middle on this one” and what roadblocks exist – “Watch #42 on the left side, we may need to double team him”
The purpose of both the huddle and the stand up are very similar, let’s get very pertinent time sensitive information out right now, we don’t care about the end of the game, or end of the project, we only care about what is coming up right now. We are only concerned about what we can see in the immediate future. This is not to say that Agile as a methodology is not concerned about the project as a whole, just that the stand up meeting is very focused on the immediate.
One common misconception is that a standup meeting can go beyond 15 minutes, or that it is not necessary to stand during the meeting. How would a 20 minute huddle with the players lying on the ground look? Well that’s exactly what your meeting would look like as well, sloppy, inefficient, lazy and unproductive. I should know because I tried it! I ran a standup meeting sitting down for over a year and converted the meeting to a true stand up in which all the participants were required to physically stand up during the meeting. The meeting went from roughly 30 minutes, to under 3 minutes in one day. We were later able to hold that standup meeting on an elevator in which we needed to be finished by the time we reached a certain floor. The psychological aspect of standing keeps people concentrated on the task at hand and thus standing is an integral part of the Stand Up meeting. Who would’ve thought!
So the next time you are wondering if you should actually stand for the meeting, picture Brett Favre playing in the super bowl lying down in the huddle for the last play of the second quarter, then go make the right decision.
I once had an individual tell me that their standup meetings ran about 30 minutes, to which I replied, you are not doing a stand up meeting, especially when there is only three people, there is just no way that can happen. Sure enough, upon closer inspection, the standup was actually a social event, with questions like what did you do last night, girl did you see that show and on and on. This is not what a stand up is for, three questions, nothing more and nothing less. It’s a huddle, keep it quick, you’ve got work to do. If your stand up meeting is daily, it’s simple: What task did I complete yesterday, what task do I anticipate I will work on and or close today and are there any roadblocks that are known at this point. No dinner plans and movie discussions in a standup meeting. This point is very important when you have a cross functional team and you are trying to convince them to come into any type of meeting ever day. If your organization is new to Agile, this is a hurdle you will inevitably have. “You want me to come to a meeting EVERY DAY? I just can’t commit to that; I’ll come when I have time…maybe” are statements you are certain to hear as objections on the onset of your standup meeting request. I can’t tell you how many times I have heard individuals make statements such as I don’t have time for a daily meeting. My current daily standup has 14 people in it and it lasts on average 6 minutes. Therefore when I hear the objection in the form of the statement “I don’t have time” my response is “it takes about the same amount time as a bathroom break and you have time for that right? Also, this is the most important few moments of the day, this 5 minutes will save hours in an update meeting”. Not that I recommend this, but there was a time when I told a contracting company, if your people do not have 5 minutes to spend in a standup meeting, I don’t think I have 5 minutes to write the check! Needless to say, their contractors where in the next meeting.
Imagine for a second that you are gearing up to watch the big game. You have your hot wings ready, all your friends are over to help celebrate, you rented the biggest big screen money could by and your whole block is decorated in your team's colors. It's moments before the coin toss and the commentators are wrapping up their pre game rhetoric. Just as you rally the troops to the living room to watch the beginning of this historic event, you suddenly notice along with another several hundred million people who are observing this game all over the world: WHAT THE HECK HAPPENED TO THE FIELD!!! You look in amazement as you become aware of the absence the 50 yard line..... and every other yard line for that matter. There are no end zones, NO NOTHING! It seems the field is more suited for a huge tennis tournament than a football game,let alone the superbowl! Imagine all the thoughts running through your head, the questions would be unending: How will they know they have a first down, or a touchdown..... or... wait a moment.... where are the goal posts? There are no goal posts?!
Ok calm down, take a deep breath, it was all a dream. This would hopefully never happen, but just thinking about it may give you heart burn. This example is there to show you just how important the field of play is. In some ways it is a measuring stick, a way to know how far you have come and more importantly how far you have left. Agile is more about managing the work left to do than anything else, similar to a football field. Even though the announcers of a football game may make mention of a drive, i.e. the cowboys have advanced 65 yards on this drive: what truly matters is that they are on the twenty yard line and it's second down. All that is really important is what is left, whether you drove 50 yards or 5 yards, you are still on the 20 yard line and it's second down. This is an important concept, since many people will put just a little too much stock in how long a project has gone on, or how far they have come, when all the truly matters is the question of what is left.
Your scrum board is just as crucial to showing what is left. The typical scrum board would have the following sections: Product backlog, sprint backlog, tasks, tasks in progress, completed and accepted. Each one of these sections would contain either a user story or a task associated with a user story usually written on a small post it note. If we look at the right side of the scrum board as the endzone or the end goal, we can gage whats left looking at what is not on that left side. As tasks and stories are completed and or accepted to move towards the right side of the board. Just like football though, close doesn't count, you don't get the story point for uncompleted tasks and stories just like you don't get the points on the scoreboard for incomplete passes on the 1 yard line. Close only counts in horse shoes and hand grenades. You can get close with a hand grenade and we'll call that a win!
A word on virtual boards vs. physical scrum boards, they both have their advantges and disadvanges. Some people prefer to keep the stories, tasks etc in a scrum tool such as versionone. This is great since it's in a digital format there is all types of automatic reporting that can be done across a sprint and across a project. Automatic burn down charts, burn up charts etc. The benefit of having a physical board is anyone can see at a glance where your project is. It just looks like your team is busy and that is benefial because if you are doing agile properly, you are REALLY busy. I have invited all members of the team including the executive team to come and take a look at the task board at any time. I taught them how to read it and gave them an open invitation. And guess what, they actually stop by and check it from time to time! Be carefull what you ask for because if your board is not organized and updated you could cause more confusion that progress. Another benefit is the mental win your team will get from physically grabbing a task and moving it to both the in progress area as well as the completed and accepted columns. I know this may sound a little silly, but your team will get small "wins" on the inside when moving items to the done column. This is especially important on large complex projects. Since agile breaks down the work into smaller pieces, team members can get a sense of accompishment in small increments instead of waiting months or even years for that feeling of completeness. Frequent gradification can also lead to greater inspiration to get the job done.
At the end of the day, it's truly a judgement call. You can use either, personally I use both. It is quite a chore to keep them both in sync but well worth the reward. It's personal choice on which to use, but I strongly suggest you use one of these and don't attempt to go without one entirely. Remember how you felt about the football field being set up wrong? Imagine how you would feel if there was no field at all! So get 'er done!
Keep Smilin', Keep Strivin', Keep Agilin'
In any team sport, there are persons who never score. They do not play defense or offence, never call a play, never take a shot or celebrate in the endzone. He does not coach or own the team. He does not cheer or keep stats. He has the best seat in the house even though he did not pay for a ticket! He never makes a first down but yet he is the most powerful man on the entire field. He has the potential to make or break many crucial plays. He has the ability take points off the board with one hand tied behind his back. That man is the referee. We never really pay attention to the ref until something goes wrong. Rarely do we keep our eyes glued on the ref unless they got in the way of a play or made a call. Yet, the refs are working on every single down. Not only that, the refs are hiding in plane sight, there right there in the mix taking care of business.
The persona is usually low key, they are able to take a mountain of abuse without so much as batting an eye. They are able to have an immediate affect on issues. This reminds me of a scrum master. A scrum master is an individual that is tasked with managing the process of agile. Some teams have the scrum master as part of the delivery team while others do not. A good scrum master is always there, enfluencing the flow of the sprint and or project. He/she is hearing issues daily, and removing road blocks. You may not notice how hard a good scrum master works. One may not realize they exists at all until the scrum master makes a bad call or gets in the way. A good scrum master is like a good ref, monitoring the flow, keeping people in line, enforcing the boundaries of the "game", keeping standups short and upright. Scrum masters also take abuse sometimes for something they did not physically do, such is a referee. A ref gets yelled at about what another player has or has not done. Even though usually the ref doesn't have any skin in the game, and doesn't receive the championship ring.
There are companies that intionally assign scrum masters to scrum teams that are in a totally different department to deter them from getting too involved in the minutia and focus just on monitoring the process of an iteration. The scrum master often facilitates the iteration review meeting, they also often oversee the estimation poker and sprint planning meeting. Even though the scrum master typically does not vote, they have a ton of enfluence over the process itself. Many scrum masters do not earn story points, but have the ability to influence the "score board" through the implementation of the process itself. A ref and a scrum master have the delightful pleasure of enforcing the rules and boundaries of the game. For a scrum master that may mean keeping a product owner at bay and away from the delivery team during a sprint, for a ref that may mean throwing a ruffing the kicker flag to help keep the kicker safe.
So whether its on the field or in the board room, these similar roles are created to bring order to the universe. Keep this in mind whenver you feel like arguing with any one them. I haven't seen people be successful in yelling at the ref, dito the scrum master. These people are created to take a lot of abuse like it's nothing, I should know. So in closing, love your scrum master, I mean they have enough to overcome with a title like scrum master already right? Show them that you love and appreciate all the little things they do that no one ever sees, and how you want to do their laundry every thrusday and wash the car on Saturday mornings! Ok, maybe that's a bit much....unless??
Don't worry.... be agile
In any project there are people who are very interested in the success of the project, however they are not part of the delivery team. These people can be considered chickens, but we are going to classify them as a special part of the chicken family. While these individuals are not the ones to put their hands to the plow, they are often the ones that sponsor the project, simply put: they pay the bills. We will call these people stakeholders and sponsors. In american football, the equivalent of stakeholders sponsors would be the owner and the fans.
The owner of a football team is very interested in every aspect of the team and the game as well. They are interested in the ticket sales, the concessions, the mood of the fans, the performance of the team and of course; the score. The team owner is financially tied to the success of the "project' in this case the game. Although he would like to see his team sell out, get high yardage,and send people to the pro bowl, at the end of the day, winning the game is the most important deliverable to his bottom line. Unless something is seriously disfunctional, you usually don't see the team owner on the sidelines calling plays. You also don't see him on the field catching touchdown passes and doing wild celebrations in the endzone. You see the owner in his box, typically high above the field and even though it may seem as though he doesn't have influence over the game, he is usually the one with the most to lose. He picked the coach and paid for the players, without his influence and support the team would cease to exist. Imagine what would happen to a team where the owner refused to pick a coach, won't pay the right amount of money for the players and generally does not want the team to succeed? What chance is there that the team would end up at the superbowl? Any worthwhile initiative should begin with executive sponsorship, just like a football team.
Likewise the fans of the team are also involved with the sucess of the "project". Some have spent money to see the game, traveled from far and wide, bought a ticket, purchased a beverage and some might have even placed money on the game. So the fans are invested physically, mentally and financially but most of them have no direct influence on the game other than to yell as loud as possible in the stands. These people are similar to stakeholders. There are people in your agile implemention who are interested and effected by the outcome, they may even have skin in the game, however they are not directly on the delivery team, and are not the product owner. Make sure that your agile project does not ignore these very important group of people. Don't hesitate to invite some of them to your significant iteration reviews and or release meetings.
Keep in mind that while the team is the one getting the work done, the sponsors are paying the bill and deserve to be treated as such. These peope need to feel as if they are part of the team in some way, even if they are 5 levels removed, unless you don't like funding for your next project, or you get a kick out of defending the viability of your team during force reductions! You may also be in an organization that has not fully adopted agile as a methodology. Don't think that just because you are being allowed to operate in an agile mode that your exeutive team and or sponsors know about, understand, support or even agree with the agile manifesto. Allowing them frequent inspections through the opportunity to see working software every two weeks in your iteration review meetings helps to further your cause. Most likely it would be rare for them to attend however the invitation alone could go a long way. Keep 'em happy, keep it agile. See ya.