Asynchrony’s First-Ever Internal Conference

Among the many exciting things happening at Asynchrony this year, one of my favorites is our first-ever internal conference, coming July 15. I’m a big fan of organizations that take time to learn and share their learning. Especially given that Asynchrony is growing and establishing new offices, it’s vital that we share learning across offices and invest in the personal relationships that make the organization what it is. The conference goals are:

  • Increase the value of the time invested by targeting information sharing.
  • Increase knowledge sharing and interactions between individuals and teams.
  • Provide opportunities for our employees to create and present a session for their colleagues.

The conference will be a mix of 50-minute sessions, an exhibit floor with 15-20 booths for delivery teams and functional groups (aka chapters and guilds) and open space. To fill the sessions, we made an open call for proposals in the organization, with a small selection team to decide which ones ultimately made the cut based on:

  • Good variety of information presented
  • Relevance to our current and future business success
  • Interest from the company in the presentation content (popular vote/survey)
  • Enough mix of technical and non-technical topics so there will be multiple sessions that non-technical people can attend and get value (this means that non-technical topics are probably more likely to be selected!)
  • Highlighting employees who have not already been featured in front of the company (expecting there to be a mix of both)
  • Promoting creativity of topic and presentation content/activities

We had around 40 people propose more than 50 sessions. The selected sessions are  intriguing — something for everyone, and certainly a conference I’m looking forward to attending!

  • Anarchism at Asynchrony: Lessons from the Left in Building Self-Organized Teams (Brian Coalson)
  • Asynchrony Culture and You! (Andrew Rauscher and Wes Ehrlichman)
  • Battling Unconscious Bias (Neem Serra)
  • Building a serverless backend on AWS (Eric Neunaber)
  • Denver: Self Management and our Future (Jim Mruzik and Don Peters)
  • DevOps Culture (Matt Perry)
  • Getting to know Node.Js (Josh Hollandsworth)
  • Go (Jason Riley)
  • Improving Communication Skills with Analogies and Metaphors (Rose Hemlock and J LeBlanc)
  • Intro to Unity 3d (Westin Breger)
  • Introduction to Functional Programming (Kartik Patel)
  • Mobile Monsters – Develop Your Mobile App Test and Quality Strategy (Linda Sorrels and Mary Jo Mueller)
  • Password Hashing and Cracking (Micah Hainline)
  • Plan Bee – Using The Raspberry Pi to Help Bees (Dave Guidos)
  • Risk analysis and RFC 1149 (Alison Hawke)
  • Scaling Staffing at Asynchrony (Nate McKie)
  • The Meaning of Dub Dub:  Where Apple is taking us in 2016 and beyond (Nick McConnell, Mark Sands, James Rantanen, Jon Hall, Henry Glendening)
  • UX Process (Lee Essner)
  • Who Matters and What Matters To Them (David Lowe)

Introducing: The NoEstimates Game

I’ve been play-testing a new simulation game that I developed, which I’m calling the NoEstimates Game. Thanks to my friends and colleagues at Universal Music Group, Asynchrony and the Lean-Kanban community (Kanban Leadership Retreat, FTW!), I’ve gotten it to a state in which I feel comfortable releasing it for others to play and hopefully improve.

The objective is to learn through experimentation what and how much different factors influence delivery time.

Download these materials in order to play:

If you’d like to modify the original game elements, here they are:

I’m releasing it under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, so please feel free to share and modify it, and if possible, let me know how I can improve it.


Software-Delivery Metaphors from Basketball

Basketball practice, circa 1925, courtesy Seattle Municipal Archives

Basketball practice, circa 1925, courtesy Seattle Municipal Archives. Then, as now, the WIP limit in the game is exactly one.

March has begun, and that means March Madness, when many Americans turn their attention toward basketball, with unbridled hopes in NCAA tournament brackets and the thrills of underdog upsets. Basketball offers not only the promise of nail-biting college tilts but also some helpful metaphors for software delivery. Read on for an assist for your team!

Practice Your Free Throws

I was never a star basketball player (I made it only as far as the high-school sophomore team), so I was keenly aware of my need to practice in order to build my skills. For instance, I always found that if I were having trouble making field goals (which was not infrequent!), it helped to practice free throws. With no jumping involved and no one defending me, this allowed me to simplify my form and focus on the basics. I reasoned that, if I couldn’t hit a free throw, I had no business trying longer-range shots in complex situations. Even now, I still can’t figure out why players who take most of their shots from behind the three-point line can’t seem to reliably make free throws.

The same is true in software delivery. For instance, before you can realize the goal of continuous delivery, you need to discipline yourself in automated testing and continuous integration. Be able to reliably answer in the affirmative Jez Humble’s three questions:

  • Does everyone check into mainline (at least) once per day?
  • Do you have a suite of tests to validate your changes?
  • When the build breaks, is fixing it the team’s #1 priority?

If your team aspires to continuous delivery, you can’t keep chucking up the same code or try to do it in the midst of delivery commitments and deadlines with a bolted-on “devops team.” You need to slow down in order to speed up — take time to write tests at the proper levels and integrate continuously. If your throughput is lower to begin, so be it. It’ll be higher in the long run.

Planning Flow During the Timeout

If I had scored a point for every standup with the report-to-the-leader anti-pattern that I’ve witnessed, I’d have made varsity. I understand the accountability idea behind Scrum’s three questions, but I have rarely seen it implemented in practice in a healthy way. The standup tends to be rote, individual-oriented, low-energy and low-value, with teams sometimes abandoning them for “real work.”

Contrast this with a timeout in basketball. It’s fast, full of energy and purposeful. Why? The timeout is focused on how the team can work together in the next short period of play. That’s it. Imagine if the coach went around the circle demanding that each player describe what he had been doing:

  • “Well, coach, I missed two jumpers but made a free throw.”
  • “I’ve been guarding #18. Still plan to guard him after the timeout.”
  • “I’ve been running up and down the court. No blockers.”

Anyone who has been watching the game knows these things! Likewise, we were all in the office yesterday; we know you’ve been working. In a timeout, individuals don’t report status; the team proactively solves its main impediments to flow:

  • “They’re double-teaming me, coach. That means someone is going to be free — let’s get Christopher or James the ball more.”
  • “I can’t keep up with #18 — Chike, can you drop down and help me guard him in the low post?”

In a timeout, conversation is lively and self-organizing; no one waits to be called on. When the timeout ends, the team runs back onto the court knowing the plan. Does your software-delivery team know the plan when standup ends? Treat standup (a.k.a. daily flow planning) more like a basketball timeout, and orient your standups toward the team and flow.

A Whole-Team Approach to the 7-foot Constraint

That brings us to one last metaphor from basketball: System constraints are like a defense that you have to dynamically figure out. The Theory of Constraints tells us that every system has a constraint that governs its output. In basketball, this constraint is sometimes easy to spot, whether it’s the 7-foot dude who is blocking everyone’s shots, or your point guard who keeps turning the ball over. In basketball, both on the playground and on elite NCAA courts, teams adapt to their constraints. It happens so fast in basketball that we don’t even think about it: If the 7-foot dude blocks shots from close range, a coach may deploy a lineup of better perimeter shooters or a player who is quicker and can draw fouls from the big man. Another example is a double-team situation: The team doesn’t expect a double-defended player to try to keep scoring — no, the team comes to help him, since one player is usually free. Basketball players do this almost instinctively, because they share a common goal: Score more points than the opponent.

In knowledge work, constraints are more difficult to see, and a lack of goal-orientation inhibits whole-team approach to the constraints. For example, if a person is “free,” it’s easy for a dev to pull in new work, heedless of how busy or “double-teamed” the QA is. That’s why we use WIP limits and make our constraints visible with tools like cumulative-flow diagrams. (In basketball, the WIP limit is one: It’s called the ball. When your teammate is double-teamed and you are unguarded in the open, you don’t grab another ball from the sidelines and start playing, do you?) Whereas basketball players naturally practice the art of work leveling by constantly taking a whole-team approach to constraints, we in software development can do the same. We merely need the help of simple job aids and a shared goal, which doesn’t mean staying busy as individuals, but means finishing work.

How to Facilitate a SAFe Big-Room Planning Meeting

IMAG6853I recently facilitated a two-day quarterly release-planning meeting for a customer. They were keen to use the Scaled Agile Framework-style “big-room” approach to the planning, so I attempted to support that as best I could. I’ll reserve commentary on SAFe itself (perhaps for a future post), but here I’ll describe some of the highlights and keys to the success of their meeting from my vantage point as facilitator.


This customer is embarking on a mission-critical project that includes teams (business and delivery) in no fewer than six locations, spans nine hours in time zones and integrates at least four legacy systems. Many business and delivery team members had previously not even met each other in person. And most are relatively new to agile ways of planning and delivering.

The Challenge

The main deliverable in a SAFe big-room planning session is a Program Board, which is essentially a sprint-by-sprint breakout of the work for all of the teams in the Program Increment. It can depict dependencies and assumptions, but it’s basically the plan for the quarter (five two-week sprints or so). As I remarked to the group in my introduction, the plan we would create would be wrong because we’re trying to predict the future. But we would plan in such a way as to be adaptable as soon as we realized that the plan was wrong. The plan would include the What — what we’re mean to build and why we’re building it — as well as the How — the technical approaches, working agreements and roles of the people doing the work. We mainly followed the SAFe-recommended agenda, though as facilitator I did add a couple of things (which I outline below) and shaped the form of some of the SAFe stuff.

In addition to creating a plan, the group really needed to establish a shared understanding of the business context as well as of each other. With so many different people — including different native languages — it’s easy to distrust and make assumptions, so getting the group to bond as a unified team was one of my “subversive” goals.



Closing retrospective.

We retrospected at the end of each day. Facilitating a retrospective for nearly 50 people requires adapting the approach from that of a typical small delivery team. At the end of Day 1, I invited the group to split into mixed groups of up to eight people (following the rule of “Up to eight, collaborate”) and gave each a easel-sized sheet with categories of Stop, Start, Continue and Puzzles. Then I asked each group to have one person facilitate a discussion and decide on a couple of actions that they would like to suggest to the whole group. I then called the entire group together and had the “lay facilitators” come forward and present their ideas. We did a simple Roman vote across the room for each and amended the working agreements accordingly. As is usually the case in any retrospective, the best part was the conversation that ensued through sharing.


Keys to success

From my perspective, as well as from anecdotal and retrospective feedback, the following were keys to our success:

  • The right people (a.k.a. business and technical implementation people in the same room): When you’re dealing with distributed teams and

    RAID bingo.

    trying to deliver important business value, having the business people there to contextualize and simply interact with the technical implementation people is as valuable as the plan that they create. Far more important than any delivery methodology is a foundation of trust and understanding, and this group laid that foundation by having the true business stakeholders and users in the room, and not merely for a token pep talk talk at the beginning. Business people were talking about Minimal Viable Product releases and interacted with the delivery teams throughout the two days. And technical people gave a couple of product demos to the business, which yielded understanding and new ideas.

  • Strong facilitation and self-managing: The group never would have made the progress it did without disciplined commitment to its Working Agreements, which we outlined at the beginning. They were:
    • Check-in, Check-out protocol: I can’t say enough about how useful this is for a meeting of any size.
    • “Hands” rule: Since we often had lots of concurrent conversations happening (in team breakout planning, etc.), we were frequently loud. The old “hands” rule, in which one person holds up a hand and stops talking and thus creates a knock-on effect whereby everyone else follows suit allowed us to come to focus within 15 seconds of when I raised my hand.
    • Be on time: To facilitate this, I projected a giant countdown clock during breaks, and walked around holding with a “5 minutes remaining” card while people were in lively breakout groups.
    • “Yes, and…”: Borrowed from the improv world, this was a simple attitude that disposed us toward active listening and affirming what the other person was saying, so that we might build collaboratively rather than shut down conversation. Since most people were not previously familiar with the concept, we did the “Yes, and…” warmup as our icebreaker on Day 1.
  • Setting these agreements out upfront and “enforcing” them early allowed the group to self-manage and own the agreements, so that I had to really “intervene” only a handful of times. (And yes, we actually finished on time.)
  • Variety: No one likes sitting through back-to-back Powerpoints, struggling to stake awake; two full days of intense planning and thinking is difficult enough. So we mixed up the style of presentations and planning sessions using a variety of formats:
    • Games (or as Luke Hohmann would say, “collaborative frameworks”) for quick, collaborative discovery, like RAID Bingo
    • Lean Coffee for working through the Parking Lot/Car Park
    • Open Space for topics like deeper dives into the business, working agreements and tradeoff sliders
    • Warmup games for initiating conversation and creativity
  • Rearranging the space: We started with round tables of eight, but throughout each day we reconstructed the space, moving tables to create a circle of chairs, moving a couple of tables out of the room altogether and creating standing open spaces that encourages movement around the room. And of course, we had a designated “checkout table” in the back.
  • IMAG6833.jpg

    We used star stickers to indicate dependencies. These were the notecards that served as legends for reminding what color went with each team.

    Informative workspace: As is typically the case in release-planning meetings, we used loads of information radiators on the walls. This allowed us to share and persist the decisions and questions but also to create an engaged group, because we were able to all collaborate (a group of 50 physically can’t collaborate around a monitor or even a projection screen). By having the Program Board on one wall, the Story Map on another and Team Board all around, the room had no “front” but became a “theatre in the round,” which itself fostered collaboration and engagement.

  • Celebration and fun: Music, photo slideshow at the end, appreciations (gratitude board).

For next time

One bit of feedback was that we could’ve used one more day. I think that’s fair but will depend on how much face-to-face time a group has with each other (in this case, it’s warranted). And as focused and on-schedule as we were, one improvement I’d like to make for next time is to state the objective/outcome and people needed for each agenda card. Other feedback was to ensure enough space in the venue (we were cramped at times, so we removed a couple of tables on Day 2).


If you do it right, you get the stated “deliverable,” which is the plan. It might even be a pretty good plan (though all plans are guesses and therefore wrong!). But you also get something much longer-lasting and equally as valuable: the team building that fosters trust and communication, which in turn fosters collaboration and shared understanding. I can’t tell you how many times — and how deeply gratifying it was — to hear people exclaim, “Wow, I didn’t know that you did it that way in North America!” or “That really clarifies things for me!” Having the right people in the room, strong facilitation and engagement are they keys.

From New Hire to Team Contributor, ASAP: How Asynchrony Prepares People to Deliver

inception.jpgHow do you help a new hire start contributing to an agile delivery team in as little time as possible? At Asynchrony — an agile software-delivery firm expanding and hiring rapidly — we embarked on an experiment exactly a year ago to bridge the gap for our new employees between orientation and the high-expectations of a real, billable customer-facing delivery team. What we tried we called simply “The Learning Team,” an ongoing internal team where new hires and veterans alike can safely learn new skills like TDD, pairing, continuous delivery and data-driven forecasting so that they can hit the ground running with external-facing teams.


Our current organizational context necessitated that we find a way to more effectively onboard people. We’ve been growing at a pace that has meant aggressive hiring goals, which increasingly means that we’re adding people who have the aptitude and attitude for but sometimes not the experience of agile delivery. That means that some new hires may not have experienced pairing, TDD or other vital practices for how we deliver quality software for our customers. We’ve found that, although pairing dramatically shortens the learning curve for new team members, new hires were not always able to go straight into that environment.


In the past, we had occasionally used ad-hoc and sometimes loosely run “bench projects” as places where new hires spent a few days before jumping onto a real project. But those were not designed to provide much in the way of mentoring or professional development; they were more a place to bide time. We had also recently successfully experimented with research teams, but those were more oriented toward R&D than product delivery.


Enter the Learning Team.


With the leadership of our CTO, Nate McKie, we envisioned it to be a permanent, first-class team, staffed by a full-time tech lead, a full-time product owner and a part-time agile coach. Following the first week of a new hire’s tenure at Asynchrony, which includes the same three-day agile overview workshop that we offer to our customers, he or she would join the Learning Team. Depending on the individual’s learning goals, the person might be on the team from a few days to a month or longer. It would also be a safe place for existing Asynchronites to acquire new skills or transition to a new role. (For instance, one colleague who has been with the company for a few years wanted to learn the skills of product ownership, so we made her the team’s product owner.)


Since the project would be entirely internal, we would have few, if any, dependencies outside of our control, so we could run the project in an exemplar way, focusing on learning through delivery. As an advisor to the team, I occasionally encourage the new hires to immediately apply the learning that they get in the agile overview workshop to what they’re doing in the Learning Team. The pattern should then be:
  • Implement in the Learning Team the good practices you hear about in Agile Overview, then
  • Implement in your future customer-facing team the good practices you experience in the Learning Team.
Our Crossing-the-Chasm-style elevator pitch looks like this:
For new hires and veteran Asynchronites
Who need to learn the Asynchrony delivery “way,” brush up on skills or learn new ones
The Learning Team is an internal delivery team
That provides a safe place to learn proven practices and experiment with new ones
Unlike being thrown straight into a team without knowing what great delivery practices look like​
The Learning Team is an exemplar team where people can learn healthy practices that they can take to other teams.
We kicked off the team with a proper inception, complete with “customers” and internal stakeholders. We added a twist to the typical visioning, chartering and release planning of inception: personal learning goals. Each person on the initial incarnation of the team took some time to write and share his or her goals with the rest of the team, which they would hold each other accountable for and encourage each other in.
learning goals.jpg

The Results

Obviously, the biggest risk was whether the return would be worth the investment. After all, it’s not chump change to intentionally run a bench project, staffed with a coach and dev mentors. Nate had gotten buy-in from the rest of exec management to carry out the Learning Team experiment for a few months. Had it failed, we would’ve pulled the plug and tried something else. But we’re now to the team’s first anniversary, and we’re continuing because we’ve seen how much it has bridged the gap for new hires — less friction when they join new teams, and the added bit of confidence that they know something about delivering in the “Asynchrony way.” Moreover, we now have a couple of employees who have gained valuable experience as product owner and tech lead who are potentially able to do those roles in other teams. It’s true that we incur opportunity cost by “benching” our people to work on the Learning Team. But the tradeoff in reduced risk is worth it. People who are new to Asynchrony and our way of working — in which transparency and honesty are precursors to learning — aren’t always trained or made to feel safe to expose what they don’t know. The Learning Team helps them develop that mindset so that, when they start pairing in earnest under the delivery pressures of customers, they don’t feel they need to hide problems or take shortcuts, which can lead to messy delivery problems. With so many new people coming onboard, we need to invest in preparing them for success. It’s one of the necessities of fast growth.


Because the team composition is  always in a state of flux, we have to always be prepared for someone to leave. We’ve mitigated that somewhat by having three of the roles — product owner, tech lead and coach — be staffed by the same people, which provides some continuity. Also, because members don’t generally know when they’re going to be “promoted,” it can be disconcerting and inhibiting to team morale.  Along with that, we’re still trying to figure out the answer to the question “When is a person ready to move out of the Learning Team?”
We also learned that we need to choose the product and tech stack wisely. The product that the Learning Team has been developing over the last year was built on a legacy code base with a not-insignificant amount of a not-altogether easy language to pick up (Erlang). With dependencies on some business-facing concerns about the legacy code base (some real customers use it) and the steep learning curve of Erlang, we have decided to use a simpler, more straightforward product so that the team members can focus on Asynchrony agile delivery rather than some of the unnecessary distractions from our previous product choice.

In Summary

We’ve seen benefits for our new hires being able to more smoothly integrate into their delivery teams and for our veteran employees learning new skills and roles. One of unexpected benefits that I’m looking forward to in the new year as we emphasize exemplar practices in the Learning Team will be to the delivery teams themselves, getting infused with people who not only avoid a drag on their throughput, but provide fresh, innovative practices to invigorate the teams. My goal is to hear more things from Learning Team graduates such as “We were doing continuous delivery on the Learning Team; why aren’t we doing that on this team?”
 learning PO.jpg

Recent recommendations

I’ve recently attended a couple of thought-expanding conferences and met many inspiring people (including a few back at the Asynchrony St. Louis office), so I’m sharing some of the recommendations that I’ve picked up from keynotes, sessions, hallway chats and pub discussions. Here are a few things that people have been talking about, some of which have been around for a few years:

Make risks visible with “RAID bingo”

IMAG5949IMAG5950To help teams mitigate risks and other concerns — and make them explicit and visible — I like to do a RAID brainstorm, either at a kickoff/inception and/or at points after a project has started. (RAID is an acronym for Risks, Assumptions, Issues and Dependencies.) As with any sort of group brainstorming, the key is to facilitate cognitive diversity by allowing individuals to come up with as many ideas without being biased or inhibited by groupthink.
One technique I use to draw out as many unique ideas — and avoid the boredom and tedium that usually come with talking about risks — is RAID Bingo. Here’s how you do it:
  1. Divide the group into multiple small teams of 3-5 people.
  2. Have each team draw on a wall/large-poster sheet a 4×3 grid* with column headings of R, A, I and D.
  3. Instruct the teams to write risks, assumptions, issues and dependencies on post-it notes and place them in the appropriate columns as fast as possible. The goal is to be the first team to have three items in any column or four in any row. The first team to do so should shout “Bingo!”
  4. When a team shouts Bingo, tell all teams to pause. Invite the winning team to announce and briefly describe each of their items.
  5. Resume play! Have the teams keep their post-it notes on the boards and continue to try to get a(nother) full column or row.
  6. The next team to shout Bingo must have all unique items (they cannot have the same items that the first winning team used).
  7. Repeat until the teams have covered most of their boards (usually by the third “Bingo”). Then do the final Bingo “coverall” — first team to cover all squares wins.
Unified, final RAID list

Unified, final RAID list

After you’ve generated many unique project concerns, unify all teams’ contributions into one board. At this point, you can discuss them in more depth or simply defer the discussion and mitigation strategy until later (but hopefully not too much later!).

*Depending on time available and the number of people in the group, and therefore the number of small Bingo teams, you may choose to make the columns bigger (four blank squares for a smaller group) or shorter (three blank squares for three or more teams or less time).