Bridge-building case study (“Factory Fridays”)

In early 2013, I was working as a technical writer and a facilitator for a startup company on the precipice of its commercial launch. The company had found a site for its factory and had begun to build it out, and the manufacturing team was gunning to spec, buy, and install equipment in time to hit the production launch date. Trouble was, the product was still very early in its development stage and thus not fully defined. This of course led to big frustrations between the teams:

“Can’t you just tell me what material you need this equipment to be able to make?”


“I cannot believe you’re considering buying that piece of equipment. It’s not what we need at all!”

I was in a really interesting position to tackle this communication gap, because I worked directly with almost every single person in the company at that time, and thus had a very high level of influence, even though I had no direct authority or power by title.

This case study steps through the scenario, my assessment of the problems, the planning work I did to bridge the gap, and how I evaluated the success of the project. It’s an interesting case, because there’s truly only one major deliverable: transferring enough knowledge to build out and standup a manufacturing plant (I’ll spoil it for you: the company did open a factory). But there were lots of interim projects, successes, and realignments, and I step through those as well.

One of the biggest realignments, which I reference in the case study, is that initially the two teams were operating in different working structures and methods. The development team had been using Scrum to great effect and was feeling really good about it (I was that team’s Scrum Master), and part-way through the knowledge transfer project, the manufacturing team switched to using Scrum as well. Here’s a short Scrum 101 post, which includes the presentation I made for the manufacturing team, to explain to them how the development team was using Scrum. It’s an interesting way to manage work in that context — it’s a framework designed for software development, which has no lead times, but product and equipment design can involve very long lead times — and requires a bit of adjustment.

This case study also looks a bit at why the approach was successful, which was matching the method to the situation. I talk a lot more about knowing which are tools and skills are necessary for which project, product, and company stage in this post about transitions.

Scrum 101: Using Scrum outside of software development

Scrum is a working method designed for software development. The Scrum Alliance published a quick but comprehensive summary of what Scrum is, and what its goals are, and that page includes this very condensed outline:

The Scrum framework in 30 seconds

  • A product owner creates a prioritized wish list called a product backlog.
  • During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
  • The team has a certain amount of time — a sprint (usually two to four weeks) — to complete its work, but it meets each day to assess its progress (daily Scrum).
  • Along the way, the ScrumMaster keeps the team focused on its goal.
  • At the end of the sprint, the work should be potentially shippable: ready to hand to a customer, put on a store shelf, or show to a stakeholder.
  • The sprint ends with a sprint review and retrospective.
  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

When I got my Scrum Master training, I was the only person in the room who wasn’t working in software development. That meant that I couldn’t use Scrum exactly as it’s intended to be used: It’s not designed for projects that have lead-times. Software doesn’t really have waiting periods, where you’re waiting for a manufacturer to make a tool for a part, or where you’re waiting on 12 weeks of cycle testing, for instance.

When you’re working in hard goods, you aren’t talking about a potentially shippable product at the end of a sprint, but you are still talking about the work being ready to show to a stakeholder. But once you wrap your head around how you need to scope out the work and break up the tasks, it’s a really useful framework. What you wind up doing is breaking up tasks into smaller pieces that are less time-dependent. For instance, the task isn’t “make parts” — it winds up being several smaller tasks, that can be divvied up into various sprints (“finalize tool design” and “submit purchase order for tool” and “complete first article inspection on parts made with new tool,” for instance).

We used the Scrum framework to organize the development and manufacturing teams’ work to build out and stand up a manufacturing plant. The development team had been using the scrum framework for about a year by that point. I was the team’s Scrum Master. (I wrote a bit about my thinking on the Scrum Master role as a Facilitator role.) During the knowledge transfer process, when the development team and manufacturing team were working very intensively together, the manufacturing team switched to using Scrum as well. One of the engineers got Scrum Master training as well, and I showed the manufacturing team how the development team had been using this slightly-modified version of Scrum. Here’s the quick presentation I made for introducing the method to the whole team:

I did some training with the manufacturing team to help them get up to speed (how to estimate effort for chunks of work, how to get unit-of-measure-loving engineers comfortable with the idea of completely subjective point values for effort, how to build a backlog spreadsheet with a burndown chart — straightforward stuff, but practical examples based on how the company was already using these tools).

Working as two aligned scrum teams had two really valuable impacts. One was that it became much easier to schedule work that involved both teams, because there was a lot more visibility into work scope and schedule. The other was that folks were able to support each other: folks regularly attended the other team’s sprint reviews to see the presented completed work, and celebrate each other’s accomplishments.


I’ve mentioned that being a generalist gives me a good vantage point to see similarities and differences across fields and thus to gather a lot of tools and skills to use. But equally important is knowing when to use which tool for which job — that’s based on understanding transition and recognizing where you are in it:

  • A product transitions through the phases of the product development process or software development lifecycle.
  • A project transitions through the project management phases.
  • An organization transitions through growth models, workforce, and management approaches. 

If you’ve got a deep enough tool kit, you can pick and choose what’s going to be most useful for the work at hand, rather than trying to use a cookie cutter approach.  What you need for working with an early-stage startup, for instance, will be very different from what you need in a more established organization — not just because the work is different, but also because the people are different. Personalities often self-select to different stages of project and company.

recent 99U article about using sprints very early in the product development process highlights a key reason for adjusting your approach based on the stage of development:

While you can spend longer building a perfect prototype, that isn’t the point of the sprint—it’s a learning process, not a manufacturing one. Knapp has found that teams can get 90 percent of a product’s user interface finished in a single day. And that timeframe is important. “After a day you are definitely willing to listen to what customers say about your product,” says Knapp. “But when your prototyping goes on longer than that, you become more and more attached to the idea.”

But sprints may not be a useful framework in a later stage in manufacturing, for instance, where root cause understanding is more critical than feature building. That kind of work may be more investigative and documentation-based, requiring different tools altogether.

Sometimes you need to be rigid and focus on diligence above all else, and sometimes you need to focus on individual autonomy, loosen the grip, and accommodate different working styles above all else. The key is knowing when to use which approach, and that really depends on where you are in the interplay of transitions.

Here’s a short deck I made to illustrate the interplay of these stages, and what tools come to bear. Click on the arrows or on the slide itself to advance the deck.

No matter what tools you use, or what approach you take, you’ll only be effective if you keep empathy at the core. Managing transition is managing change. Transition is hard and  can be emotional, but you can make it less painful by setting expectations, clarifying process, and making sure everyone understands how to hold each other accountable to the process — all of which are driven by empathy.


Scrum Master as Facilitator

Facilitation is rarely discussed outside the context of having meetings, but there are a lot of kinds of facilitation. Teaching is facilitating learning. Project management is facilitating work.

I’m a trained Scrum Master, which is another name for a facilitator within the Agile working framework of Scrum. (Scrum 101: scrum teams work together in a defined span of time called a sprint to complete a discrete and deliverable part of a bigger project. Then they review their working methods in an event called a Retrospective, adjust their process, and then in their next Sprint Planning meeting, they break off another chunk of work to be completed in the next sprint. The fundamental difference between traditional project management and the Agile/Scrum framework is the frequency of review and iteration on smaller, discrete portions of a project vs a focus on delivering an entire complete project all at once).

Scrum Master is an interesting role, rooted in removing obstacles from the working team, but also working to provide a supportive environment in which the team can work.  One of my favorite scrum tools is the daily standup, a meeting not owned by any one person but by the team, in which everybody is asked three questions:

  • What did you do since we last met?
  • What will you do before we meet next?
  • What roadblocks are in your way?

In a true scrum setup, the Scrum Master is the sweeper: removing the roadblocks and making the path smooth!
But that framework is really useful in non-scrum settings, too. I’ve adopted it for use in most projects I’ve worked on, regardless of team type. It makes the most basic and useful meeting agenda format there ever was!

The part of the sprint where the team pauses and reflects is my favorite part of scrum, because the best work happens when you look at your own process and methods. What disrupts your ability to get work done? What disrupts the team’s trust in each other? It’s so important to stop and look honestly and openly at how the team is working together. It requires the team to be vulnerable with each other, to be able to receive and give criticism in a safe and productive way, and to think honestly about how the team is working.

A retrospective will not be productive if you haven’t made  space for people to be vulnerable, and there are a lot of tools and techniques you can use to help create that environment. Here’s an example of a retrospective agenda I’ve used:

  1. Reminder of the goals/objectives of the retrospective
    All team members reflect on the past sprint and make continuous process improvements. Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
  2. Check-in
    “How did the sprint go for you?” in only two words. Each person writes their two words on the board.
  3. Happiness Histogram (see below for examples)
    a) Review the burndown chart and sprint calendar to remember what happened during the sprint.
    b) Draw a graph with time on the x and happiness on the y axis, (Happy is above the axis, Sad is below, and neutral is the X axis). Label significant events e.g. planning, sprint review, and backlog reviews, important meetings, environment failures, branch merges etc. on the x axis.
    c) Everyone draws a line representing how they felt throughout the sprint.
  4. Gather data and generate insight
    Prepare sheets of paper for each team member each with one question:
    In this sprint, what things happened that were unusual?
    In this sprint, what things did we do well?
    In this sprint, what did we do that we should avoid doing in the future?
    Distribute the sheets. Each person writes something, then passes the sheet to their left, then writes something on the next sheet, in response to what has previously been written. Give 3-5 minutes for each round, then instruct the team to pass the paper to their left. Stop when participants have the sheet they started with.
  5. Decide what to do
    Ask people to read their sheets and write the main points on post-its, on the board. Ask people to read the post-its aloud. Distribute 5 dots per person. Each person votes by post-it (however they like). The goal is to select one or two things to actively work on in the next sprint.
  6. Close out (Return On Time Invested)
    (See Facilitation 105 for more info on how to use the ROTI tool.)

I love happiness charts. When we use these, we decide up front that we’ll use them, so we can define our rating system (-3 to 3, for instance, where 0 is neutral) and set up a table to track ratings. Every day during our morning standup meeting, each person gives a number ranking to how they felt about the previous day, the scrum master writes it down, and we map it out as we go (in a spreadsheet, or on a whiteboard, or on paper).

Here are some examples. You can see really readily when the team is in total alignment. Note the huge tank from everyone on the team at the same time, early in the sprint here: IMG_20130403_102712_958.jpg

It also reveals when the team is way out of alignment. Look how everybody’s lines are all over the place in this sprint:


The real value of happiness charts though, is going back through and identifying WHY folks felt great or terrible. Folks often feel more at ease talking about emotion when it’s rooted in “data” (as much as a gut-take feeling on a made-up scale is data) so it can be a lot easier to identify from a graph, rather than from conversation alone,  what the team is struggling with, and thus what you as the facilitator or scrum master may need to focus on. And it also provides a framework for people to point jubilantly at a peak and say what happened that made things go well. I’ve gotten to hear some really lovely and supportive commentary from the team about each other. In one of my favorite retrospectives, we learned that the highest points on the happiness chart were when the team was really struggling, but felt supported by each other and able to work through the struggle.




Facilitation 105: Close out your meeting

Part 5 in the Facilitation series.

Previous post: Facilitation 104

  1. Review
    Review any decisions that were made (make sure to document them in minutes), review any items that were tabled for discussion later if there’s time, and review any action items and make sure they’re assigned and have due dates. Review when the next meeting will be.
  1. Evaluate
    Make sure to build in time and space to improve your meeting process — do a debrief before everyone leaves. The least formal and easiest debrief to implement is a go-round at the end of the meeting, during which each person has a chance to speak up if there is anything important that hasn’t been addressed yet, or to give a thumbs-up or thumbs-down about how the meeting went. This is a good tool for ongoing, regular meetings in which the attendees know each other and the process well. For less frequent or one-off meetings, especially if they involve people who haven’t worked together much or a new topic, it can be worthwhile to do a more guided debrief. In that case, the facilitator can ask a few questions like:
  • “What worked well in this meeting?”
  • “What can we do better in our next meeting?”
  • “Did this meeting give you the information you need to do your job?”
  • “Did you feel prepared coming into this meeting? Did we give you enough information ahead of time?”
  • “Is there anything else you wish we had been able to cover today?”

Make sure the debrief doesn’t devolve into complaints. If somebody says, for example, “You talk too much and makes our meetings take forever and I never get to talk about what I want,” ask that person to re-state their comment in a constructive way (“Because time is so tight, let’s be mindful of how much time we’re taking when stating opinions.”).

A good tool for evaluating the effectivity of a meeting is the ROTI assessment (Return on Time Invested):


Here’s a link about how to use the ROTI tool (also the source of the image).

If you haven’t set an agenda and clear expectations, it will generally be pretty clearly revealed by a negative evaluation.

  1. Clean up
    Don’t forget that others may use meeting spaces — and not just your teammates. Vendors, auditors, and interview candidates also use shared spaces — make sure not to leave any sensitive information behind! But more generally, be a good neighbor. Use the camping rule: leave the site better than how you found it. Clean off the whiteboards, throw away any trash or post-its, turn off the projector and extra monitors, and take your cups with you. The person who called the meeting needs to make sure these things happen.
  1. Adjourn (on time!)
    Don’t allow the meeting to just passively dissolve! Formally (or informally) close out on a positive note. Offer a “class dismissed” and thank attendees for their time and effort. Let’s not take each others’ hard work for granted. Don’t forget to be kind to each other! Vacate the conference room before the next meeting is due to start. If there are other conversations happening, take them elsewhere. Lingering past the meeting time makes other peoples’ meetings start and end late.


Facilitation 104: Tools of the Trade

Part 4 in the Facilitation series.

Previous post: Facilitation 103

The specific tools you use for facilitation really depend on what kind of meeting it is, where it’s being held, and what kind of technology you need. There are three main kinds of meetings:

Status updates, which don’t really require much facilitation other than preventing off-topic conversation. One main tool for keeping these conversations focused is to only ask yes or no questions, and another is to follow a punchlist or dashboard, so the order of updates is routine.  

Decision making meetings, which require a strong effort to keep discussion focused on the end goal (the decision to be made). Reviewing meeting minutes at these meetings can be very valuable, because it helps remind everybody of the recent history — what led to needing a decision. It also reinforces the value of keeping minutes. This is another yes-or-no question kind of meeting.

Brainstorming, discussion, or planning meetings. These require the most active facilitation, because you need to walk a fine line between keeping people engaged and active, and open to participation, while keeping that participating focused and productive. This is an example of a meeting where it can be really beneficial to have an outside facilitator — someone who isn’t necessarily emotionally invested in the outcome, and can help the team see when they’re stalling out. Ask open-ended questions rather than yes or no when conversation stagnates.  

One brainstorming method is for all participants to first write down all their ideas on post-its, and then organize the post-its by topic or area. Typically then, participants will present and defend the topics, so that everyone in the group understands what’s been brought up. Then, each participant gets a few stickers to place on items they feel are highest priority. This is a really valuable exercise for clarifying priorities within a team.

Regardless of what type of meeting it is, a facilitator should always be ready to summarize points when the topics jump around, and address side-trackers, by mirroring, redirecting, and clarifying points without causing anybody to become defensive. Here are a couple of specific facilitation tools.

The “parking lot” is just a place to write down out-of-scope topics that pop up during the meeting — these are things that are worth addressing, but are outside the goal of the meeting. Writing them down means people feel their ideas have been heard and valued, and it means we don’t lose anything. You can follow up on parking lot topics outside of the meeting, or at the end of the meeting if you have time. Take care to avoid making decisions about a parking lot topic if you don’t have all the necessary stakeholders in the room — sometimes that’s why the topic landed in the parking lot in the first place.

Mirroring simply means letting the group know how they appear, so they can reflect and adjust. It’s a good way to get everyone’s attention, and to address disruptions. An example of a facilitator mirroring would be telling the group that they look tired and distracted, and asking whether the group needs a break. Another example would be pointing out that you’re seeing a lot of side-conversations, and asking whether there is something that needs to be put in a parking lot or addressed immediately before getting back to the objective.

Redirecting is a means of intervening when a person’s behavior in a meeting is disruptive.  In meetings where the rules of engagement are very clear, anybody in the room can easily shut down an interruptor (at daily scrums, for example, where the generally understood rule is that only the immediate scrum team is permitted to talk, though observers are welcome to attend). But it can be a lot harder in other meetings, especially where it’s a newer group of people who haven’t fully defined their own rules and dynamic. One technique for redirecting is to first describe the behavior (ie, “Emma, you’ve left the meeting three times already.”), and then make an impact statement to tell the participants how that behavior is impacting the meeting (“We had to stop our discussion and start over three times.”). Then you can redirect the behavior by asking the group for suggestions (“Would everybody like to take a short break so when we return, we won’t have any more interruptions?” or “What can we do to make sure we don’t have more interruptions today?”). This is a method that takes some care and practice — it’s a lot easier to set up rules of engagement early on, that everybody in the meeting can agree upon.

A Note on Formality
I tend to have pretty informal meetings, but lots of groups use more formal meeting procedures, like Robert’s Rules of Order or consensus-based procedures. It’s worth assessing how formal or informal a meeting should be — if everybody’s getting what they need out of the meeting, don’t sweat informality. If the meetings have been exhausting trainwrecks, consider formalizing the rules for a while.

Next post: Facilitation 105

Facilitation 103: How to run a meeting

Part 3 in the Facilitation series.

Previous post: Facilitation 102

Before the meeting, prepare the meeting space and send out the agenda.
Don’t waste your team’s time in setting up the space during the meeting time!

  • If possible, reserve the room ahead of the meeting time to give yourself time to prep.
  • Make sure you have enough chairs, post-its, markers, and whatever other supplies you need.
  • Make sure that the projector, videoconference equipment, conference call number, or any other technology is prepared before the meetings starts.
  • Build in breaks (and coffee!) — a good rule of thumb is 10 minutes of break for each hour of meeting.
  • Give people time to respond to the agenda and make changes in advance.
  • Make sure folks know what is expected of them:
    • What do they need to read or prepare in advance?
    • What do they need to bring to the meeting?

Which brings us to……
How to Facilitate a Meeting
Well-run meetings generally have three designated roles. These roles can usually be covered by the meeting attendees, though sometimes it’s wise to have a third party doing the facilitating.

  • Timekeeper
  • Note-taker
  • Facilitator

What does it mean to facilitate a meeting?
Why have a designated facilitator at your meeting? The function of a facilitator is to keep the meeting on track, keep the group focused on the stated goal, and guide discussions by asking key questions.  

Here are a few things you can do, to make sure your meeting goes well.

  1. Start and end on time. This is probably the thing we struggle with most, and if it happens once, it ripples out through the entire day, since the conference rooms are all booked back-to-back. Try to schedule 50 minute meetings rather than an hour, so you can make a graceful exit and let the next meeting start on time.
  1. Designate a time keeper, who will give time checks to the group.
  1. Designate a note-taker, and make sure that person understands where the notes are to be stored, and when they must be available and posted.
  1. Restate the purpose and scope of the meeting before beginning.
  1. Review the agenda. I like to have everybody in the room approve the agenda before beginning the meeting. It’s a nice way to make a social contract and build accountability in the team to prevent derailing. When you do an agenda approval, follow through: before allowing the meeting to shift focus, make sure the whole group has agreed to change focus.
  1. Make sure everybody understands the rules of engagement before the meeting begins. There are lots of things you can set up as rules (capturing off-topic ideas to be discussed later, approving the agenda, not permitting interrupting, not permitting phone calls or email checking, or allowing all of those things during breaks, using verbal or non-verbal agreement, for example) but the most important part is to make sure everybody’s clear on what is expected.

Next post: Facilitation 104