My brother owns a firm that builds custom houses. In his business the walkthrough is a critical quality and communication tool to ensure the customer and his build crews stay synchronized.

My brother owns a firm that builds custom houses. In his business the walkthrough is a critical quality and communication tool to ensure the customer and his build crews stay synchronized.

The most formal version of reviews and inspection are Fagan-style inspections.  Inspections are very rigorous in removing defects from any type of deliverable. However, the cost and overhead of these inspections have led to the development of a wide range of less formal techniques.  The goal of the less formal techniques is find a balance between the benefit and cost of inspections. The least formal and most common review technique is the desk check.

The roles:

Author – The author is the person that created the deliverable being reviewed.  He or she sends the deliverable (or link) to the person doing the review, answers questions (if asked) and reacts to feedback.

Reviewer – Reads the deliverable and provides feedback to the author.

Simple Desk Check Process:

  1. The author recruits one or more reviewers. It is common courtesy to always ask before you send a document to be reviewed.  When you ask, I suggest making sure that you provide the reviewer with any relevant context.  Context can include information like an overview of your assignment, relevant standards and when you need the review completed.
  2. Send the deliverable or link the reviewer.
  3. The reviewer reads and comments on the deliverable based on the agreed upon time box.  I believe it is a good idea that the reviewer write down any comments and defects to share with the author.  The only exception to this rule is if the author and reviewer are in close proximity (such as pair programming) AND the problem can be fixed on the spot. Don’t trust memories.

The desk check process is very simple and very compact. All of my writings are desk checked by one or two editors. 99% percent of the time the review and my consumption of the information generated is asynchronous.  They edit the document and then at some point in the future I make corrections.  If my editors did not write down the feedback and just left a voice message I would never be able to remember the things I need to fix (it would also have to be a long message).  On the occasions that we are in the same location the process is far richer because we talk and make corrections interactively (this is the power of collaborative reviews).

There is almost always no pre-work for this type of review.

A second type of less formal review is the Walkthrough:

The roles:

Author– Same as in the desk check, except when they act as the reader and scribe (see below)

Reader – Reads or presents the deliverable being reviewed. Almost always the author.

Scribe – Record comments and defects identified during the walk through.  Many times this role is filled by the author.

Reviewer – Attends the walkthrough and provides feedback to the author. In more formal versions of a walkthrough, the reviewer may be asked to pre-read or pre-review the deliverable before the walk through.

A simple walkthrough process:

  1. The Author recruits reviewers.  As in the desk check type of review, make sure that you provide the reviewer with any relevant context.  Context can include information like an overview of your assignment, relevant standards and when you need the review completed.
  2. Send a meeting request for the walk through meeting. When remote participants are involved you will need to leverage collaborative tools that allow the deliverable to be shared and so that participants can hear each other.
  3. Send the deliverable or link the reviewers so they can prepare for the walk through. (Optional)
  4. During the walk through the reader presents or reads the deliverable to reviewers. The reviewers consider the material being presented and provide feedback that is recorded. In order for walkthroughs to be effective they need to be time boxed. 45 to 60 minutes is usually the limit of attention spans.
  5. After the walkthrough the author will need to follow-up on the comments and defects generated during the walkthrough.

My brother owns a firm that builds custom houses. In his business the walkthrough is a critical quality and communication tool to ensure the customer and his build crews stay synchronized.

The desk check and the walkthrough are generally less effective than an inspection. However, they strike a good balance between degree of rigor and their ability to find and remove defects.  Rigor is highly correlated to cost and overhead. Informal and formal reviews and inspections can also be combined.  For example, I recently reviewed a process for an avionic firm that requires all designs and code to be desk checked before it is formally inspected. The firm’s goal is to remove 99.9+% of the defects prior to a production release on all life critical software. Just because a review technique is informal doesn’t mean that it is not valuable.

Inspections are the gold standard.

Inspections are the gold standard.


Inspections are peer reviews by trained individuals using a formal, structured method. Inspections represent the GOLD standard for reviews.  According to Capers Jones, inspections are highly effective in removing over 97% of requirements defects. Data that I have collected supports the view that inspections are the most effective means of early defect removal. The issue is that very few people do inspections for two basic reasons.  The first is that inspections are expensive (they require time and effort) and inspections are uncomfortable for those being reviewed. Inspections require specific set of roles and a specific process.

The roles:

Moderator – The moderator leads the team through the process ensuring everyone participates and follows the rules.  The moderator will also ensure that metrics are collected and that the defects that are identified are correct and recorded.

Author – The author is the person that created the deliverable being reviewed.  He or she will participate in the inspection, providing feedback and developing an understanding of the defects being identified.

Reviewers – Reviewers read the deliverable and identify defects BEFORE the inspection meeting.  The pre-work is critical and needs to be turned into the scribe before the inspections meeting.

Scribe – The scribe insures that all participants have provided their feedback before the inspection team meets.  The scribe also combines all of the feedback to ensure that only unique items are discussed in the inspection meeting.  During the inspection meeting, the scribe records feedback on the defects identified during the pre-work  and records any new defects that are identified during the meeting.  After the meeting they keep track of the defects to make sure they are tracked to completion. The data collected by the scribe feeds the measures and metrics.

The Process:

  1. Plan the inspection process:  The plan needs to ensure that the process is followed and that need lead times are built in.
  2. Kick off meeting: The moderator explains the goal and reviews the plan for the inspection. The moderator will also ensure that all reviewers are aware of any organizational standards that need to be applied during the inspection. I suggest that during the kickoff meeting that the reviewer lets the moderator know if they will have a problem meeting the due dates and if they feel they are unqualified to perform reviews.
  3. Distribute the deliverable that will be inspected.  Note in today’s collaborative environments this may mean send a link to the document that will be inspected.
  4. Individual preparation:  Each reviewer read the material being reviewed and record all defects identified using the format identified in the kick off meeting.  Also keep track and record the time you spend on the review.  Send the defects identified to the scribe before the inspection meeting.  For large deliverables the scribe may need up a week to consolidate all of the feedback.  Collaboration tools can save time and effort to consolidate the feedback.
  5. Inspection Meeting: The inspection meeting is the core event.  Generally each reviewer goes over the unique defects they identified. As a moderator use a round robin process with each reviewer walking the author through an item.  The author can ask questions or point out why something identified is not a defect, but under no circumstance can anything identified be debated.  Moderators need to ensure that the feedback stays technical and not personal. Being told you made a mistake is never fun.  Reviewers that did not complete the pre-work are not allowed to participate. Scribes make sure comments are recorded and all defects that are really defects are recorded for follow up.
  6. Rework and Follow Up:  After the inspection meeting the author needs to resolve the defects found in the inspection.  Some organizations have rules about which defects must be corrected and which can be deferred. Major problems may require a further inspection. The moderator will usually make this type of determination based on organizational standards and the level of criticality of the project. The time required for rework is useful data for process improvement and determining whether inspections are effective.
  7. Retrospective:  Always do a retrospective on the process to improve how you are doing inspections. The moderator should ensure that the retrospective occurs (it should be part of the plan).
  8. Process Improvement: The data collected during the review process can be used to improve the process in the IT department, to identify training needs and to decide what types of work should be inspected. The moderator or process improvement personnel will do the analysis needed for process improvement.

Inspections are very effective if the team doing the inspection understands the process and the deliverable being reviewed.  For example, if you are doing a code review on a program written in Ruby don’t gather a group of reviewers that have never coded in Ruby.  They are not qualified. Everyone involved in the process needs to trust each other. All reviews, in general, and inspections (because they very formal), in specific, can be very stressful for the author. The level of stress can cause authors to avoid inspections or short cut the process which means that defects will be found later in the development process or in production.  Inspections remove defects in code or any other deliverable before they get into production or before lots of time is spent on building something that will need to be changed before it goes into production.

Reviews and Inspections: With Formality Come Rules

Reviews and Inspections: With Formality Come Rules

Reviews and inspections are an integral part of building most everything. You find reviews and inspections in manufacturing, in construction and even in publishing. Software development and maintenance is no different. Reviews and inspections can be powerful tools to remove defects before they can impact production and to share knowledge with the team and stakeholders. They are part of a class of verification and validation techniques called static techniques. These techniques are considered static because the system or application being built is not executed. Instead of executing the code, the code or other written deliverables are examined either by people (generally called reviews and inspections) or mechanically by a tool (known as static analysis).  Reviews and inspections can be applied to any product generated as part of the development process, while static analysis can only be applied to code-based products.

Reviews and inspections come in various levels of formality to meet different situations and needs. Informal reviews typically do not follow a detailed written process and results are generally not documented for later review and analysis. They are often used to ensure knowledge sharing and training at a one-on-one level. One classic method used for informal reviews is called the desk check.  In a desk check, a team member emails a deliverable or code to another team member who reviews it and gives them feedback. Another form of informal review is pair programing.

Walkthroughs are a step up the formality ladder.  Walkthroughs are group sessions in which the author takes the group he or she is presenting to through the deliverable.  The attendees of walkthroughs generally include  team members and technical specialists. Walkthroughs can be very informal (an impromptu gathering) or the degree of formality can be increased by requiring meeting preparation and collection of issues and defects. Walkthroughs are used to discover defects, make decisions and to distribute information.

Technical reviews leverage a defined process for defect detection, and include participation by peers, technical experts and often management personnel. They are more formal than the typical walkthrough and are much more formal than desk checks. A trained moderator, who is not the author, generally leads a technical review (to enforce independence) comparing the deliverable to organizational standards. In addition to defect discovery, decision making and information distribution, technical reviews are often used as a formal approval mechanism. For example, I recently observed an organization where all projects go through an architectural review. Technical reviews are a type of technical review usually based on defined organizational standards. The architecture review in the example was based on the organization’s published standard architecture.

Inspections are the most formal of the review and inspection techniques. The most well-known inspection technique is based on the process defined by Michael Fagan of Fagan Reviews.  The inspection process includes highly defined roles such as moderator, author, scribe and reviewer. All inspection processes typically include required pre-work, logging of defects, collection and publication of metrics, formal follow-up procedures and, in many cases, the use of statistical process control techniques. The goal of inspections is to find and remove defects.

Reviews and inspections are highly effective and powerful tools for finding and removing defects from software and other deliverables. Review and inspections are used in all software development and maintenance methods. The type of review and degree of formality is usually a function of the type of project. For example, inspections are almost always used on mission critical applications, such as medical devices and weapons systems, regardless of whether they are using Agile or plan-based techniques. Reviews and inspections remove defects and share knowledge so teams can maximize the value they deliver.

Listen to the Software Process and Measurement Cast 286. SPaMCAST 286 features our interview with Brian Wernham, author of Agile Project Management for Government. Agile software development in government does not have to be an oxymoron.

Brian Wernham has more than 30 years of experience in adaptive change program leadership.  He is an independent consultant and works in both the public and private sector.  He has extensive international experience in the USA, UK, Canada, Hong Kong, Germany and offshore development in Bangalore.

By the time that the term ‘Agile leadership’ was first coined, Brian had already been successfully leading iterative, adaptive projects for over 10 years on both sides of the Atlantic.  He works as a hands-on program director and has real-world implementation expertise together with a comprehensive understanding of the related international research.  He has consulted for major strategic international organizations such as Deloitte, PwC, Gartner Group, the National Audit Office in London and Seer Technologies in North Carolina. His comprehensive public sector experience includes the Department for International Development (DFID), the World Bank, the United Nations (Geneva), and local government authorities.

Brian is a Fellow of the Association for Project Management, a Fellow of the BCS and has a MBA from Henley Management College.  He applies adaptive planning approaches as an offshore Yachtmaster and as a keen off-piste skier.  He is currently consulting for the UK Government in London.

Read Brian’s blog, visit his website and of course buy the book!

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay on Scrumban. Scrumban is the combination of agile (Scrum) and lean (Kanban) concepts that can be used to manage projects.

Upcoming Events


I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast.

An ITMPI Webinar!

On June 3 I will be presenting the webinar titled “Rescuing a Troubled Project With Agile.” The webinar will demonstrate how Agile can be used to rescue troubled projects.  Your will learn how to recognize that a project is in trouble and how the discipline, focus, and transparency of Agile can promote recovery. Register now!

Upcoming DCG Webinars:

May 22 11:30 EDT – Agile User Stories
June 19 11:30 EDT – How To Split User Stories
July 24 11:30 EDT – The Impact of Cognitive Bias On Teams

Check these out at

I look forward to seeing or hearing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Overly Self-interested Behavior Is Bad For Teams!

Overly Self-interested Behavior Is Bad For Teams!

Hand Drawn Chart Saturday

Teams are an important concept in most IT organizations, regardless of their development philosophy. Philosophies like Agile may put more emphasis on teams, but even in organizations that do not embrace Agile philosophies, teams are important. Dan Ariely in his Ted Talk, “What Makes Us Feel Good About Our Work” suggested that overly self-interested, cynical behavior can negatively impact organizations by reducing their ability to communicate and innovate. The same problem can occur, albeit on a small scale, at the team level. In a recent presentation, a fellow Agile coach described a team engaged in overly self-interested behavior. He described a scenario in an organization that cuts the bottom 10% of all groups annually and stated vision that IT should maximize the value it deliverers to its customers. After losing a popular team member the previous year, the team had decided to make sure that his replacement was given the worst assignments in order to ensure he stayed on the low end of the performance scale in the coming year. Their goal was to ensure that the core team stayed intact during the next review cycle. In their mind, keeping the core team together ensured that they would deliver more value to their internal customers. The behavior of the team attempted to circumvent the idea that adding new and more highly qualified personnel would lead to improved performance. Viewed from the point of view of organizational policy, the whole team was acting in an overly self-interested behavior manner, but from the point of view of core team they are acting rationally and within their interpretation of the rules as seen through IT’s vision of value delivery. The team did not believe that their behavior was at odds with the behavior the organization wanted to incent.

What we perceive as overly self-interested at a team level is based on collective cognitive biases. Biases are powerful psychological filters that affect how both individuals and teams perceive the world around themselves and then guide how they behave. Biases reflect shortcuts in how we interpret and react to stimulus. In many cases, these reactions are valuable, however they can also cause problems (as many shortcuts occasionally can). Understanding how biases impact how individuals and teams perceive the world around them can help teams make better decisions and therefore deliver value more effectively. In the example, the core team had decided to protect itself by defining the new person as an outsider, which allowed them to hold them at arm’s length. In-group favoritism is a typical team level bias that causes teams to favor those inside the team’s boundaries over those perceived to be on the outside. This type of bias negatively affect how outsiders are perceived to perform. Negative perceptions of outsiders will effect whether we listen to their ideas and whether we trust them to deliver value.

Teams need to break overly self-interested patterns of behavior by striving ensure that they are pursuing a goal that is greater than team’s own self-interest. At a project level, product owners need to clearly identify and communicate the overall value proposition, so the team has something greater than themselves to pursue. When behavior goes off track coaching can help to identify issues that the team can’t see and diagnosis themselves. However, in many cases overly self-interested behavior at the team level can be a reflection of poor philosophies at the organization level. Organizational philosophies, like decimation or objectives that foster individual competition rarely support intergroup communication and innovation.

Crowds are susceptible to groupthink.

Crowds are susceptible to groupthink.

Brainstorming has been a staple in the business world since its creation in the mid-1940s.  Other forces have combined to reinforce the technique such as the mania over crowd sourcing and consensus management styles.  The problem is that the data shows that the technique is not as effective as we all believe, and in some cases can actually be unproductive – such as when groupthink occurs.  There are better ways to generate innovative ideas.

Brainstorming is a process that through free association generates ideas to find a solution or conclusion for a specific problem.  There are a core set of tenants that define brainstorming.  It is generally a group activity that includes a focus on generating as many ideas as possible (quantity), which includes welcoming unusual ideas, combining and improving ideas and the avoidance of criticism.  Great stuff!   However, research[1] has recently questioned whether the process is as effective and efficient as the popularity of the method would suggest.  The research suggests that the reliance on groups and a lack of debate and criticism causes the technique to be less effective at generating creative ideas than other techniques.

Why do you and I care about this topic?  Developing new ideas and innovative solutions is an integral part of software development, enhancement and maintenance.  Using the most effective techniques, or at least knowing what the most effective techniques, is of more just of academic interest.

Groupthink happens when the desire for harmony in a group overrides a realistic appraisal of alternatives.  The after effects of a groupthink gone wrong might include the passive aggressive comment: “I knew this wouldn’t work but did not say anything.”  “Idea gravity wells” and the forbearance of criticism help to create the problem.

Brainstorming and other group techniques for generating ideas leverage the diversity of thought a well-defined group[2] can create. Groups that allow a single powerful individual to dominate can create an idea gravity well that curtails innovation or green-field thinking as new ideas can’t escape the status quo. The problem is that conclusions that have been influenced by groupthink may not hold up in the bright light of the marketplace.

The second criticism is the lack of immediate feedback.  Forbearing debating and criticizing ideas, like a critique in art school, avoids exploring the depths of an idea and deciding quickly what is relevant.  Critiquing ideas makes sure the good parts are honed and built upon and the bad stuff either refined or sloughed off.   Debate, discussion and criticism create a platform to provide immediate feedback, allowing a group to reshape the idea being examined rather than building on a poor base.

I have been experimenting with and honing a process that attacks two of the major criticisms of brainstorming.  The process begins by making sure you have the right team (see the well-formed team footnote).  I strongly suggest using video if you have remote participants.  Make sure you have someone that will act as the scribe and someone that will also act as the moderator for the session.  Second, provide the “team” with the topic being explored and all background information before the planned session.   Each team member is responsible for reviewing the data and developing a list of their best ideas . . . individually.  Generating the initial set of ideas helps to avoid the possibility of groupthink or idea gravity well occurring directly out of the box.  Note: The list of ideas from each person is the price of admission; lack of preparation should bar a potential participant from the session.

The ideation session begins with a round-robin presentation of ideas from each participant with discussion, debate, criticism and refinement (no fisticuffs or off-topic criticisms).  The round-robin presentation generally continues until everyone has put at least one idea on the table or until the initial set of ideas are used up.  I allow and encourage participants to switch to more of free-for-all for laying out and discussing ideas as soon as everyone has completed laying out at least one idea.  Get one idea on the table from each person makes sure all of the participants understand that they have permission to participate.

I allow the process to continue until team members’ lose the will to live, run out of ideas or reach a consensus on an idea or idea set.  I believe that the facilitator or moderator should push a team at least slightly past what is comfortable in order to generate potentially extraordinary results.  Pushing past what is comfortable is one of the reasons I ask interviewees on my podcast for two ideas to solve the problem presented at the end of the interview rather than just one, which would be far more comfortable (note off the record: many interviewees have indicated that one response to the “two things” question would be far easier).

My wife suggests that after the session is complete, give everyone twenty four hours to chew on the topic and then reconvene to make sure that reflection has not provided tweaks to make the solution or solution set better.  Remember that not everyone thinks at the same rate as everyone else.

Why do we think brainstorming works?  We all have experience with the process.  It is comfortable, it is safe and in many cases it generates good ideas . . . just not the best ideas possible.  To brainstorm or not to brainstorm, that is the question, perhaps not exactly Shakespeare, but relevant nevertheless.  As we gain a better understanding of what works and why, when it comes to generating innovative ideas isn’t it time to put aside preconceived notions based on hearsay?  The data from academia suggests that what we know is based on just that — hearsay.  Don’t let data get in the way, you might say; we believe what we believe.  This week I announced to a group that brainstorming was not as effective as other techniques in terms of generating innovative ideas.  You would have thought that I had insulted their children.  Everyone has a story about successes using brainstorming.  Those successes may well have helped us get out of tight situations, but because of those successes it is hard to acknowledge that there are better ways to generate solutions and new ideas.  This is true whether we are discussing idea generation, software development or Marigolds and Moonflowers (something absolutely unrelated). Brainstorming may still have a place at the innovation table, but it should no longer sit at the head of the table.  There are better ways to generate creative solutions and now is not the time to leave creative ideas on the table . . . maybe it is never time to leave creative ideas on the table!

[2] Well-formed means that only the minimum number of people should participate and that those that participate include a range of experience and backgrounds.

Mind maps can be useful for note taking.

Mind maps can be useful for note taking.

Mind mapping is a technique for mapping information. A basic mind map typically emanates from a central topic with subdivisions branching out from that topic. The process for mind mapping has few basic rules and suggestions for constructing and formatting mind maps, which makes them highly flexible. Mind maps have a wide variety of uses based on one central theme: learning. The uses of mind maps include:

  1. Note taking: Most lectures tend to follow a more linear outline with relationships and linkages between topics inferred. Standard note taking is generally a reflection of how the lecturer thinks rather than how the note taker thinks. Mind mapping helps the note taker to capture the branches of the topic and then to visualize the linkages. Structuring notes based on how the note taker thinks makes memory recollection easier. Note: I occasionally use this technique to restructure standard notes as a means reinforce my memory.
  2. Planning: Few plans are linear. Mind maps are useful tools for planning and visualizing program-level backlogs. The branching attributes of the map provide a tool to show how functionality breaks down and then visualize the linkages (dependencies) between the entries. While every story should be independent, story and task independence is generally a goal rather than a fait accompli in many organizations. A second use for mind maps in the planning category is as a tool to capture sprint planning results. The sprint goal serves as the central theme with stories radiating from the theme. Activities and task branch from stories. Relationships can be added to show predecessors and successors (or as a trigger for re-planning).
  3. Research: Using a mind map a tool in research is very similar to how mind mapping is used in note taking, with a few subtle differences.  The first is that the mind mapper is generally gathering data from multiple sources while looking for gaps or unnoticed relationships as data is acquired. I often use mind maps as tools for gathering and reorganizing information that I collect (the ability to reorganize data is a strength for most tool-based mind mapping solutions). Many tools support clipping URLs and information for bibliographical entries.       The real power of using mind maps as a research tool is the ability to visualize the data collected, which generally makes gaps obvious and can be useful when looking for relationships between branches of the research.
  4. Presentation Tool: In the entry Mind Mapping: An Introduction, I recounted the story of Ed Yourdon using a mind map to direct his presentation. I have developed mind maps as a precursor to building a classic PowerPoint presentation. When developing or giving a presentation from a mind map, the flow of information reflects how you have visualized and reflected it on the map.
  5. Organizing thoughts: This is my favorite use for a mind map. I begin the organization process by generating my central theme and then using the theme as a hub add each separate item I can think of based on that theme. I generally do this on paper without worrying about spelling or whether one or two items are duplicates. The goal is get everything that is known around the central theme. A starburst pattern will be generated. A simple example:


Once the starburst is created the map can be mined to establish major subdivisions and to indicate area where more research is needed. Walk through each entry and gather related items together. From the items you gather together, the name of the subdivision will emerge. For example, in our mind mapping mind map, when I gathered note taking, planning, research and other together the major subdivision titled “Uses” emerged.


Every Daily Process Thought essay begins using this type of mind map. Many people use the term brainstorming for this type of mind mapping activity.

Mind maps are tools for visualizing data. Seeing your thoughts put into patterns that represent how you think makes it easier to remember the ideas and concepts being mapped. Mind maps also help the mapper see gaps in the data or to jog creative thoughts by exposing relationships that do not jump out when processed linearly. Mind mapping is an extremely flexible tool, therefore there are an enormous number of uses. There is a saying that “if the only tool you have is a hammer, everything will look like a nail.” Given the varied number of uses for mind maps, perhaps they might be an information-visualization Swiss Army knife.


Get every new post delivered to your Inbox.

Join 3,305 other followers