While attending Declan Whelan’s session Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team at Agile 2009, he mentioned the Change Process Model introduced by family therapist Virginia Satir. Declan only touched on Satir’s model, and I found myself wanting to know more after I left. With Point2 going through a high degree of change in the last two years, I was very curious as to how the Satir Process Model fit in.
The Satir Process Model was initially introduced to help families deal with change, but coincidentally enough it was also used at an organizational level. It’s no secret that businesses have to change in order to stay competitive. However problems can arise as those changes are introduced, and what Satir’s model helps us understand is the natural stages encountered along the way. There are five stages.
Late Status Quo
- The subject group is at a familiar place.
- The group has a strong sense of identity, and are comfortable with each other.
- Behaviour of individual group members can be predicted.
- Something foreign is introduced to the group which requires some sort of response.
- The change is usually introduced by a small minority.
- The rest of the group sees this as a threat to how things work, and fear losing their sense of familiarity.
- The group will generally try to undermine the change, or avoid it completely.
- The group fully plunges into the change.
- Relationships may change.
- The group may no longer behave as they used to.
- The group will lose their sense of belonging causing them to become anxious and vulnerable.
- In this stage the performance and productivity of the group take a sky-dive.
- Something clicks and the group starts to embrace the foreign element. They see ways to use it in a positive way.
- The group begins to form new relationships, and a new sense of familiarity starts to emerge.
- Performance and productivity starts to climb.
- The group starts to experience genuine excitement.
New Status Quo
- The group now levels off into a new comfort zone with new relationships, and have a sense of stability again.
- Performance and productivity are now at a higher level than the Late Status Quo stage.
- There is an overall sense of accomplishment.
The image below does an excellent job of illustrating the model.
Being aware of the stages of the Satir Process Model, and looking back at some of the changes Point2 has underwent, I can definitely see this model’s relevance. A good example would be a recent shift from product-centric teams to feature teams. Up until this point Point2 has always had each team focus on one product (or suite of products), but this approach made it difficult to ensure that the highest priority work items for the company were always being worked on.
Feature teams seemed to be the way other companies were dealing with this problem so the change was introduced. Sure enough there was resistance (including from myself), performance and productivity were hit, and the teams could no longer function as they once used to. But the teams did not give up, and continue to push through their uncertainties. I believe we are still in the change process, but have recently started to fully understand and embrace the benefits of feature teams as the Integration stage implies. I don’t think it will be long before we reach that new status quo.
Understanding the Satir Process Model has given me a new perspective on change, and I look forward to seeing how Point2 copes with it in the future. I think it’s a great exercise, and recommend looking back at changes your organization has gone through while identifying behaviour that was encountered at each stage. Having that awareness is only going to make change that much easier in the future.
For an excellent post check out Steven M. Smith’s The Satir Change Model.
In a previous post I mentioned the ABIDE principle along with a cooking metaphor to explain a team’s flow. This was one of the topics during Joseph Pelrine’s Coaching Self-Organizing Teams workshop at Agile 2009. As Joseph pointed out, a team will be at its highest level of self-organization and productivity while they are in a so-called cooking state. The key is for the team to stay out of the other four states to ensure that they don’t get into trouble.
Joseph presented us with the Ideal Gas Law.
pV = nRT
For those who do not remember their high-school chemistry class, here’s the breakdown of that formula.
- p is the absolute pressure of the gas
- V is the volume of the gas
- n is the amount of substance of the gas
- R is the gas constant
- T is the absolute temperature
So if we were to apply this theory to how we run a team (to some extent) we should be able to find the ideal environment for a team to function in. This is where Joseph’s cooking analogy was introduced. Essentially there are five states a team can be in. The team can function in any one of these states, but each state has a different level of effectiveness.
- No energy to do anything.
- Usually highly bureaucratic.
- Very exhausting to keep a team at this level; lots of energy required.
- Team becomes neurotic.
- Very brittle, and it is not uncommon for things break.
- Little room for movement; People still feel stuck requiring a lot of effort to get things done.
- Requires a lot of energy to get out of this state.
Cooling (I like the word Simmering better)
- Heat is not high enough for cooking to happen.
- Things start to break down.
- Discipline starts to break down.
- This can be the most dangerous state.
- There is still a lot of flexibility for things to happen.
- Change can go in different directions.
- The energy level is high enough that people are interacting regularly.
- People get away from their ingrained behaviour patterns.
- Stress levels are low.
- This is the ideal level.
- When people are at this heat level, they experience too much stress.
- Fight or flight attitudes emerge.
- It is not uncommon for people to burn out.
- Things become charred, and you may turn into a solid once again.
I’m sure that many people have experienced at least a couple of these states throughout their career. Many teams just settle into their current state and remain there. It is clearly in the best interest of the team to get to the cooking state, but what can they do to get there? You need flow, which defines the optimum state of productivity.
As the above graph illustrates, when you are below the Flow Zone you experience boredom because your skills typically outweigh the challenges that you are presented with. And when you find yourself above the Flow Zone, anxiety sets in because the challenges are beyond your skillset. Over time we push ourselves to avoid boredom. As we get better at what we do, we naturally start looking for more challenging problems. Keep in mind that there are adrenaline junkies who like to be way outside of their comfort zone. The key is to find that right balance.
So how do you find that balance to get cooking while riding the Flow Zone? ABIDE gives you five things you can change to help you do just that. It is to be noted that these all can work in conjunction with each other. For example, changing the environment can be an attractor.
- These are the people, positions, situation, ideas, that others tend to be attracted or driven to.
- Who’s in, and who’s out?
- The boundaries of your team.
- The roles and responsibilities that people on the team have.
- The makeup of your team including skillset, culture, gender, etc.
- Keep in mind that a homogeneous system will not self-organize properly, and dominance will emerge.
- Bring in someone new and it will surely trigger change.
- Change the circumstances of the team’s environment, and they will have to change how they work ex) tear down cubicle walls and introduce an open work environment
If you know that your team is capable of cooking maybe some of these ideas of Joseph Pelrine’s can help. I believe he has presented some very useful strategies for making good teams great. We must realize that it is up to us however, to play with the ingredients and temperature dials, and to renovate the kitchen in order to find that perfect recipe for success. I think with a little creativity we can all be chefs.
In August I was fortunate enough to attend the Agile 2009 conference. I saw two excellent sessions presented by Pollyanna Pixton. I later found out that four other sessions (attended by Tefon) included recommendations of the book Stand Back and Deliver, authored by Pollyanna and 3 of her colleagues. These presenters were so convincing Tefon even purchased the book while still at the conference. It was a good read, but the chapter on the “Purpose Alignment Model” was by far my favorite.
The Purpose Alignment Model is a simple tool designed to do exactly that – facilitate an alignment of purposes. The underlying premise is all product features or development that a company performs can be placed on two scales: how critical and how differentiating they are to the operation or success of the company. With everything placed on these scales, they can then be combined into a graph.
This simple graph can make discussion about any number of product features or work processes significantly easier and more effective. When discussion about a feature starts by first placing it on the graph above, it is placed sharply into perspective.
What constitutes a mission critical differentiating feature? One simple method for determining this is to ask ‘Could this feature be the center of an advertising campaign for the product?’ These features are the driving force to a product’s adoption and define the identity of the company. If every feature gets a ‘yes’ answer to this question the model is being used wrong. Trying to differentiate with every feature will result in little more than a mediocre product. A select few features should be placed in the ‘Invest’ quadrant and these are the features that, naturally, should receive heavy investment. If these features aren’t the most polished and solid in the product, get to work.
If an honest assessment of everything about a product is completed with this model, the majority of what might initially have been placed in the investment quadrant will end up falling into the parity quadrant. The parity quadrant is interesting. Most of a product’s features will invariably not be differentiating, so why waste resources trying to develop them? These features are mission critical, make no mistake about it, they have to work and they have to work well. Parity features will drive the sticking power of an application, thus it is still critical to get them right. The key point, however, is that parity features only need to reach parity. No wheel reinventing required. Parity features aren’t innovative. Look at what the market is doing. What is the accepted best practice? Do that and nothing more.
If a feature is differentiating but not critical to the success of the business, find a partner. Don’t waste resources that could be spent getting parity features to parity and investing in mission critical differentiating features. Find a partner who is investing in the feature and use them.
If a feature is not mission critical and not differentiating, who cares? If a feature in this quadrant is being worked on, ask why.
If every feature to be worked on is placed properly relative to each other on this graph the result is an amazingly powerful communication tool. Suddenly everyone from the CEO to the developer implementing the feature can easily be on the exact same page. With an aligned purpose across the whole team, from executive to business to development to IT, more time is spent making a profit and less time debating about how to make a profit.
By: Dustin Bartlett
When you are in a position of leadership on an Agile team, there is no shortage of mistakes that you can make. Some of these mistakes may be trivial, but there are behaviours that can really limit the progress and efficiency of those you are supposed to be leading. While attending Agile 2009 in August, Stevie Borne gave a quick talk on what she felt were the top 10 Temptations of an Agile Coach. Whether or not you are in a coaching role, being aware of these temptations will help you identify them, and hopefully get them dealt with early.
- Interfering with the team’s activities when you shouldn’t.
ex) technical work, updating story board, writing stories, creating acceptance criteria, etc.
- Takes away from team ownership.
- Allow team to make mistakes.
- Make suggestions, but let the team experiment.
- Unrealistic progress expectations, and pushing the team to go faster than they can.
- The team becomes discouraged.
- The coach may burn out.
- End up spending unnecessary time and resources.
- Remember that change takes time.
- Find a coaching mentor to help with these situations.
- You have all the answers, so you freely give them out.
- The team fails to problem solve.
- The team become afraid to fail.
- It becomes your process, not theirs.
- Ask the team how they would handle it.
- Provide ways for them to solve problem, but let them choose what works best for the team. (guide through process of discovery)
- New idea every iteration giving the impression of constant change for no good reason.
- Team loses the chance to get the feel for new techniques.
- Become too focused on the how, not the why.
- Let the team try changes for at least 2 iterations.
- Make sure there is a good reason for the change, and make sure that it is well communicated.
- Believe there is only one way to do things. Worked good on one team, so it will work well on this one.
- Team loses sight of the value behind the practice.
- The team becomes alienated from you.
- The team allows the process to replace their own thinking.
- Learn new techniques to accomplish the same goals.
- Focus on principles, rather than practices.
- Take control of the team through work assignment. Often occurs when team faces delivery pressure.
- Injected work items.
- You start speaking for your team.
- The team is no longer empowered.
- The team team loses respect for you as coach.
- Force yourself to step back and re-engage the team. Give control back to them.
- Preach that Agile will solve all problems. It’s the only way to work, and everything will go as planned.
- The team loses faith in Agile principles.
- The team feels as though they have failed.
- The team is unprepared for potential disaster.
- Understand that discomfort during change is normal. Admit it and learn to be OK with it.
- You want everybody to like you.
- Can’t take negative feedback.
- Avoid being bad cop.
- Your feelings end up get hurt.
- The team stops being honest with you.
- Need to develop a thick skin.
- Stay objective, and only mention the facts.
- Problems are talked about in vague terms with no path towards a resolution. ex) “we have so many meetings.”
- Issues go unresolved and team becomes frustrated.
- The team grows apart.
- Ask the team questions. Use the 5 Why’s to find out what the real problems are.
- Name the issue and create an approach to attempt to resolve it.
- Avoid failure – unwilling to try new techniques.
- Avoid conflict – unwilling to challenge the team when things go awry.
- Your team misses valuable growth opportunities.
- You miss coaching growth opportunities.
- Understand that occasional failure is OK.
- Find a coaching mentor and ask for help.
When something goes wrong all humans tend to respond to the problem in the same way, no matter how big or small. At Agile 2009 Christopher Avery described what he called the Responsibility Process – five mental states that people naturally enter before reaching a true level of responsibility. But keep in mind that not everyone is able to successfully move out of all states of mind prior to responsibility, as Avery described. In order to be successful at this one must apply these techniques themselves, and recognize that they are in a specific state of mind. The graphic below illustrates the five states of mind.
After a problem is discovered a person will naturally try to account for the failure. They will try to externalize the cause as laying outside of themselves. Their first response is more-or-less, “there is no way that I caused this issues, so it must have been someone else.”
Once it is realized that the problem may have been caused by oneself, a person will try to justify why it happened. They are still trying to externalize the problem when they make excuses such as, “well there is no wonder that broke since I was being rushed to complete it.”
Once you move past trying to justify the cause of the problem a person will start to acknowledge that it was in fact their fault. While in this state of mind people tend to beat themselves up with statements such as, “oh I totally screwed that up. I can’t believe I made that mistake. It was totally my fault.” We must be careful not to confuse this with responsibility – it is actually self-shame.
After self-shaming oneself a person will start to feel that that yes, they caused the problem, but the circumstances they were in didn’t give them any other choice. People will make statements alluding to having no control, or feelings that they are in handcuffs. “Well, that is just the way we were told to do it so I did it”, is a telling statement.
If one can move past obligation a person will move above the “line” and reach responsibility. The previous four states of mind are considered non-learning states – or to put it bluntly, we are stupid while in these states. We are in a coping stage and any decisions we make will probably be poor. But as we move above the line into responsibility we will find ourselves back in a “learning state”. It is here that we can make good decisions, and can start to produce value. Hearing things like, “the problem happened, but now let’s figure out how to fix it”, is a key indicator that someone is operating from responsibility.
The two grey stages in the diagram are not states of mind, but are additional stages. We are usually in a denial, believing that everything is fine and no problems exist. However once a problem is identified some people will not be able to cope. For instance the mental anguish of shame and obligation can lead a person to check-out without reaching a proper resolution. By quitting, a person does not learn anything and will likely be faced with the same problem in the future.
In order to get above the line, there are three keys. Intention states that a person must be committed to doing something. A person must also be aware that they are in one of the levels. To do this we must look for it in ourselves, and ask for the help of others to identify where we are. Avery suggested recognizing how you feel in each of these stages, and use that feeling in the future to help identify your state of mind. And finally we must confront the problem – you cannot interact with something until you are able to face it.
Obviously this stuff is based on behavioural science and it can be easy for technical people to dismiss. But be honest with yourself and think about these states of mind the next time you face a problem (this works in all aspects of your life – personal and professional). I know that my first reaction to a problem is to assume that someone else caused it. The key is to realize this and get past it. As one gets better at identifying what stage we are in, the quicker we can move from state to state. We always want to be producing value, so the goal is to operate from responsibility as quickly as possible.
One session that I attended in Chicago at Agile 2009, and thoroughly enjoyed, was Alistair Cockburn‘s Blitz Planning workshop. First, Alistair is an engaging speaker and is full of great ideas. Second, it was the last day of the conference and I was eager to start trying some of these new tricks, tips and techniques I’ve learned about all week at home at Point2.
Blitz Planning results in “getting the contents of everyone’s head into a common space” and is meant to be speedy. In the 90-minute workshop we planned a non-technical workflow (the process of getting up in the morning and getting out the door), then we planned an information kiosk system start-to-finish, and identified the earliest we could do the initial rollout.
Ideas are recorded on index cards by all members of the team as they come to mind and are not subject to scrutiny by other team members. As a team member writes on a card, they call out their idea to help avoid duplication, and to spark more ideas from other team members. When the team feels the plan is near complete, the cards are laid out on a table in chronological order, the plan is checked for completeness and any dependencies are identified. At this time cards may be torn up, and more cards may be written to fill the holes in the plan or re-work it to remove dependencies and shorten the critical path to allow early delivery. Alistair introduced the concepts of the “technical walking skeleton” and the “business walking skeleton” which contain the bare minimum to make it work, and the bare minimum to provide business value, respectively. Your earliest possible delivery consists of both the technical and the business walking skeletons.
Unlike the information kiosk example at the conference, the project we planned touches existing systems and contains many moving parts. Instead of 20-30 minutes to design a system and discuss it, we took an afternoon to write the cards and discuss, and we have more discussions and card-shuffling sessions planned for the next few days. So far it’s been an interesting exercise and I feel like we’ve identified several potential problems early. I’ll keep you posted.
By: Tefon Obchansky
While at the Agile 2009 conference last week I had the opportunity to attend a session by Rachel Davies and Liz Sedley outlining some great tips for an Agile coach. Their presentation was based on their upcoming book Agile Coaching. They were approaching the topic as though they were an external coach brought into a company just starting Agile, but there was definitely some good take-aways that could be applied in any situation. I will do my best to regurgitate their discussion in hopes that you can make use of them in your coaching endeavors.
10. Get Introduced
- What are you trying to achieve, what is your expertise? Experience?
- Explain what you expect from those you are coaching.
9. Agile is not a Religion
- Try not to come out as a preacher – this will likely switch the team off.
- You must first understand the team’s circumstances before fixing things.
8. Show Respect
- Understand the team’s history.
- Do not tell them they are doing things wrong.
- Listen to them and find out how they started doing things the way they are.
- Understand the factors that led to the circumstances they are working in.
- Be mindful of your language – use names and not labels (refer to people individually)
7. Step Back to See the Big Picture
- Do not get caught up in individual interactions.
- Look at the “system” as a whole – the way people are acting is usually a reflection of the forces acting upon them.
- Do not fix the people, fix the pressures that are acting on the people.
6. Ask Questions to Spark Ideas
- Improve the team’s thinking so they can think for themselves.
- Well raised questions challenge people – allow people to discover their own solutions.
- When a team is struggling, ask them about it – how can you guys make things better?
- Do not ask why, rephrase the questions.
- Ask a “thinking” question.
- How long have you been thinking about this?
- How do you think this will help?
- Use the Five Why’s (RCA)
- Root cause analysis asking “why” five times.
- Explain why you are asking why five times – tell them what you are doing.
- Do not ask a question if you really want to tell the team something – you will lose the opportunity to ask it.
5. Take Time Out to Reflect
- Do not react to everything right away – do not rush into an answer because you are the coach and feel it is expected.
- Better to think about it and come up with a calm solution, than to panic and provide an answer you have not fully thought about.
- Agile Retrospectives is a good time to go over these things.
4. Introduce the Elephant
- If you notice an elephant in the room, casually mention what you see (maybe in a retro).
- This hopefully will spark conversation – do not push the team into talking about it if they are not ready to.
3. Make Change as an Experiment
- “Let’s try something for a short period of time and see if it makes things better.”
- Enable them to evaluate the results and decide as a team whether to continue.
- Getting the team used to small changes. It becomes easier to introduce larger changes later.
2. Go With the Energy of the Team
- What is the best problem to tackle first?
- The one the team wants to solve – it may not be the most important, but it will get the team going.
- Give the team ownership, and get them going on devising a problem solving solution that will be pertinent in the future.
1. Have Courage in Your Convictions
- Understand that you are introducing change, but people generally do not like changing.
- Have faith in your own ability to help the team.
- Be passionate about what you are trying to accomplish with the team, and be clear about what you are trying to accomplish.
- Ensure that they do not feel like you are pushing too hard – do not push until they are ready.
Day four at Agile 2009 was the last day for regular sessions. My morning started off with Coaching Self-Organizing Teams by Joseph Pelrine. This workshop was very interactive, and was littered with activities that Joseph was hoping would get us self-organizing ourselves. He proposed a number of hypotheses and defined five different states of a team’s flow using a cooking metaphor.
In order to move teams to the ideal “cooking” state, you need to control the amount of “heat” that you apply. Apply too much and your team will “burn” out. Don’t apply enough and they team will “cool”, and maybe start to turn into a “gel” where they become very constrained. Using his ABIDE principle he identified things you can do to control the heat, thus initiating change.
I went into Min-Gu Lee’s session on Executive Leadership Challenges for Agile Adoption with fairly high expectations. Unfortunately it geared itself towards the government sector or huge organizations riddled with bureaucratic overhead. Many of the things he mentioned could be applied or at least thought about in smaller companies, but I think most of it could be considered common sense.
I wanted to get as much information as I could on making feature teams function properly so I took in Andre Frank’s session Feature Teams – Collaboratively Building Products from Ready to Done. He gave an experience talk on how his company LiquidNet moved their Scrum teams down the feature team path. I think the title was a little bit misleading since the focus was more on the Scrum process they put together with little discussion around how they overcame challenges associated with feature teams.
Declan Whelan from my old stomping grounds of Guelph, Ontario gave an interesting talk, Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team. I was eager to see how Point2′s approach to creating this environment correlated with his findings. A lot of what he presented could be considered “touchy-feely”, or as Declan put it “all “rainbows and flowers”, but everything he said made sense.
Not getting into the details of the “rainbows and flowers”, he did speak of changes we made to facilitate this at Point2. Such things included changing the work environment, setting up workshops or study groups, implementing an e-forum, and making it a recurring process. He also recommended a number of books with one catching my attention called The Fifth Discipline by Peter M. Senge.
The day was wrapped up with a banquet where they revealed an iPhone application that was built during the LiveAid sessions over the week (in which Ryan had a hand in). The application provides a way to make donations to Mano a Mano International, a charity for “creating partnerships with impoverished Bolivian communities that improve health and increase economic well-being.”
The keynote by Jared M. Spool titled The Dawning of the Age of Experience was awesome. The industry examples he used around Netflix, Apple, and Southwest Airlines made everything he said so clear. By the end of his talk it was obvious that all companies need an experience design to, “not build crap.”
That wrapped up Agile 2009 in Chicago, Illinois and I think I can speak for all of the Point2 crew that the experience was incredible. It was great to be around so many great minds in the software development industry and participate in the discussions they ignited. I came here with a goal of learning as much as I could from other attendees while passing on my experiences to others. I think I can leave Chicago feeling I did that.
The conference is pretty much wrapped up. The banquet and keynote put the finishing touches on a wonderful week of learning, collaboration, and meeting people who share the same passion for how to create awesome software.
In the coming weeks I’ll be posting about the things I’ve learned and how we can make our company better. I need some time to absorb how all of the different sessions tie into each other. It didn’t seem to matter if the session was about UI, project management, distributed teams, or coaching – everything kept coming back in some subtle way to the Agile Manifesto.
Once my subconscious has some time to mull this over and make sense of it, I’ll post. I’m going to do it just in time because as they say in Lean, JIT happens.
By: Ryan Shuya
Day three at Agile 2009 started off with the great experience report Shock Therapy: How to Bootstrap a Hyperproductive Team. This session was ran by Scott Downey an agile coach for 68 teams at MySpace, Bjorn Granvik, and Scrum co-creator Jeff Sutherland.
The three of them spoke about crucial criteria for achieving a hyperproductive state in a Scrum team. A few examples included implementing one week iterations, introducing a few non-negotiable rules (can only be changed if the team can provide a business reason for it), and a definitive meaning for done. They presented real world data of teams they had worked with that managed to reach this – a 240% minimum velocity increase. My only complaint about this session was that it was limited to 45 minutes.
My next stop was down the HR track hearing Esther Derby speak on the topic, Performance Without Appraisal-What to do about Performance Reviews. She had strong feelings that yearly performance reviews that rank or put people at certain levels are not effective. Research has shown that people are unable to gauge ways that they can improve with infrequent reviews that rank them.
Esther was certain that we could do better, arguing that constant feedback is the way to ensure people are growing and learning – feedback should be business as usual. It was great to see her making suggesting that Point2 has already adopted. She did a decent job of relating the subject matter to the software industry, and more specifically agile shops since they introduce different challenges. She also spoke about an interesting law.
The Law of Crappy Systems: a crappy system will inhibit the ability of the most talented person to perform brilliantly
Scaling Scrum with Feature Teams by Bas Voddewas a look at how to get multiple Scrum teams working on the highest priority items in the backlog. To get to this state Bas proposed that you need to change your component teams into feature teams that are able to work on any item in the backlog. Sound familiar? It should because this is exactly what we are trying to do at Point2. Bas says he has managed to scale this up to over 2000 people projects, so our instance is small in comparison, but the techniques are the same.
The only problem I had with his discussion was that he identified some of the major challenges (ones that we are currently facing at Point2) of making the transition, but no real concrete way of working through them. For example his solution to having multiple teams working on the same codebase could be remedied by using something like SVN merge. Another problem of reaching a level of collective code ownership over a large product was mentioned, but no real-world, take-away ideas were presented.
My afternoon was filled with a three hour workshop Getting People to Take Responsibility and Demonstrate Ownership led by Christopher Avery and Ashley Johnson The two of them explained the states of mind that all people experience when they are presented with a problem or crisis. The workshop provided techniques on how to identify when people (including yourself) enter these states of mind in hopes of moving past them.
The theory is that while you are in these states of mind you are completely unable to make responsible decisions – in essence, we are not very smart during these times. The point is to get to the responsible level as quickly as possible, and then solve the problem at hand. This workshop was excellent and I would recommend it to everyone. It applies to all aspects of life.
Following the daily sessions the Point2 crew went out for some Chicago Style pizza at Giordano’s. Ryan convinced us that we needed two fourteen inch pizzas between the five of us. Some of us disagreed with this estimate, but in the end we went with his plan. Needless to say none of us felt very good after eating the pizza. We nearly polished off the two pizza in their entirety, but at what price?