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)
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.
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.
I 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 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.
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
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.
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.
- 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.
For new hires and veteran AsynchronitesWho need to learn the Asynchrony delivery “way,” brush up on skills or learn new onesThe Learning Team is an internal delivery teamThat provides a safe place to learn proven practices and experiment with new onesUnlike being thrown straight into a team without knowing what great delivery practices look likeThe Learning Team is an exemplar team where people can learn healthy practices that they can take to other teams.
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:
- Antifragile (book), ALEConf
- Dixit (game), ALEConf
- Hanabi (game), ALEConf
- Thinkertoys, (book), ALEConf
- Indxd.ink (tool), Alison Hawke, Asynchrony
- IDEO Deep Dive (video), Rich Sheridan, Lean Agile Scotland
- Wardley (value chain) Mapping (technique), Will Evans, Lean Agile Scotland
- Barry-Wehmiller (organization), Rich Sheridan, Lean Agile Scotland
- Zara, My Agile Role Model (video), Clarke Ching, Lean Agile Scotland
- Amy Cuddy TED talk on body language (video), Chris Matts, Lean Agile Scotland
- Temple Grandin (movie), Sal Freudenberg, Lean Agile Scotland
- Crucial Conversations (book), Clarke Ching, Lean Agile Scotland
- Made to Stick (book), Clarke Ching, Lean Agile Scotland
- The Goal (book), Clarke Ching, Lean Agile Scotland
- The Phoenix Project (book), Clarke Ching, Lean Agile Scotland
- Strategy Deployment Canvas (technique), Matt Barcomb and Cat Swetel, Lean Agile Scotland
- Pawel Brodzinski’s flow-based road mapping (technique), via Matt Barcomb, Lean Agile Scotland
- Featureban game (activity), Mike Burrows
- Divide the group into multiple small teams of 3-5 people.
- Have each team draw on a wall/large-poster sheet a 4×3 grid* with column headings of R, A, I and D.
- 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!”
- When a team shouts Bingo, tell all teams to pause. Invite the winning team to announce and briefly describe each of their items.
- 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.
- The next team to shout Bingo must have all unique items (they cannot have the same items that the first winning team used).
- 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.
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!).