What is Fitness for Purpose?

[Note: Lately, I’ve been talking a lot about fitness for purpose and fitness criteria. Other than David Anderson and a few others, though, not much material exists — at least not applied in the software-delivery space — to point people to for further reading. So I’m jotting down some ideas here in the hopes of furthering the discussion and understanding.]

tldr;

  • The first step in improving is understanding what makes the service you provide fit for its purpose.
  • Fitness is always defined externally, typically by the customer
  • Fitness for purpose has two components: a product component and a service-delivery component
  • Fitness criteria are metrics that enable us to evaluate whether our service delivery and/or product is fit for purpose
  • Of the two major categories of metrics, fitness criteria are primary, whereas health or improvement metrics are derivative
  • Examples of service delivery fitness criteria are delivery time, throughput and predictability

Fitness for purpose is an evaluation of how well a product or service fulfills a customer’s desires based on the organization’s goals or reason for existence. In short, it is the ability of an organization or team to fulfill its mission. The notion derives from manufacturing industry that purportedly assesses a product against its stated purpose. The purpose may be that as determined by the manufacturer or, according to marketing departments, a purpose determined by the needs of customers. David Anderson emphasizes that

Fitness is always defined externally. It is customers and other stakeholders such as governments or regulatory authorities that define what fitness means.

Fitness criteria then are metrics that enable us to evaluate whether our product, service or service delivery is “fit for purpose” in the eyes of a customer from a given market segment. As Anderson notes, fitness criteria metrics are effectively the Key Performance Indicators (KPIs) for each market segment, and as such are direct metrics.

As Anderson explains,

Every business or every unit of a business should know and understand its purpose … What exactly are they in business to do? And it isn’t simply to make money. If they simply wanted to make money they’d be investors and not business owners. They would spend their time managing investment portfolios and not leading a small tribe of believers who want to make something or serve someone. So why does the firm or business unit exist? If we know that we can start to explore what represents “fitness for purpose.”

For me, fitness is something that, like user stories, can be understood at varying levels of granularity. Organizations have fitness for their purpose — “are we fit to pursue this line of business?” — and teams (in particular, small software-delivery teams) also have fitness for their purpose — “are we fit to delivery this work in the way the customer expects?”

Therefore, the first step in improving is understanding what makes the service you provide fit for its purpose. Fitness for purpose is simply an evaluation of how well an organization or team delivers what it is in the business of (its purpose). Modern knowledge-worker organizations like Asynchrony often focus on concerns like product development or technical practices, sometimes overlooking service-delivery excellence. But service delivery is a major reason why our customers choose us. That’s why we attempt to understand and define each project team’s purpose and fitness for that purpose at the project kickoff in a conversation with our customer representatives.

Two Components of Fitness

Fitness for purpose has two components: a product component and a service-delivery component. That is, the customer for your delivery team considers the product that you are building (the what) — did you build the right thing? — as well as the way in which you deliver it (the how) — how reliable were you when you said you’d deliver it? How long did it take you to deliver it? We have useful feedback mechanisms for learning about the fitness of the products we build (e.g., demos/showcases, usage analytics), but how do we learn about the fitness of our service delivery? That’s the service-delivery review feedback loop, which I will write about later.

Fitness Criteria

Fitness criteria are metrics which enable us to evaluate whether our service delivery is “fit for purpose” in the eyes of a customer from a given market segment. These are usually related to but not limited to delivery time (end to end duration), predictability and, for certain domains, safety or regulatory concerns. When we explore and establish expectation levels for each criteria, we discover fitness-criteria thresholds. They represent the “good enough” or the point where performance is satisfactory. For example, our customer may expect us to deliver user stories within some reasonable time frame, so we could say that for user stories, our delivery-time expectation is that 85% of the time we complete them within 10 days. We might have a different expectation for urgent changes, like production bug fixes.

Fitness criteria categories are often common — nearly everyone cares about delivery time and predictability, for instance — the actual thresholds for them are not. While some are shared by many customers, the difference in what people want and expect allow us to define market segments and understand different business risks. Fitness criteria should be our Key Performance Indicators (KPIs), and teams should use those thresholds to drive improvements and evolutionary change.

Who Defines Fitness?

As opposed to team-health metrics, like happiness or pair switches, fitness and fitness criteria are always defined externally: Customers and other stakeholders define what fitness means. That means you cannot ask the delivery team to define its fitness. They cannot know because they are not the ones buying their service or product. We should be asking customers “What would make you choose this service? What would make you come back again? What would encourage you to recommend it to others?”

These are a team’s fitness criteria and these are the criteria by which Asynchrony should be measuring the effectiveness of our teams’ service delivery. Then we’ll be improving toward the goal, the greater fitness for our purpose, both as an organization and as individual delivery teams. By integrating fitness-for-purpose thinking into everything we do, we will create an evolutionary capability that will help us sense changes in market needs and wants and what those different market segments value. As a result, Asynchrony will continue to thrive and survive in the midst of our growth and growing market complexity.

Difference Between Fitness Metrics and Health Metrics

Fitness Metric Health Metric
Metric that enables us to evaluate whether our product, service or service delivery is “fit for purpose” in the eyes of a customer from a given market segment. Effectively comprise the Key Performance Indicators (KPIs) for each market segment. Metric that guides an improvement initiative or indicates the general health of your business, business or product unit or service delivery capability.
Direct Indirect/derivative
Examples: delivery time, functional quality, predictability, net fitness score Examples: flow efficiency,velocity, percent complete and accurate,WIP
Customer-oriented and derived Team-oriented and derived

A Food Example

I like to use food for examples (also to eat). Is a restaurant in the product or service-delivery business? That’s a trick question, of course: The answer is “both.” As a customer, you care about the meal (product) but also about the way you have it provided (service delivery). And those always vary depending on what you want: If you want cheap and fast, like a burger and fries at McDonald’s, you may have a lower expectation for the product (sorry, Ronald) but a higher one for delivery speed. Conversely, if you’re out for fine dining, you expect the food to be of a higher quality and are willing to tolerate a longer delivery time. However, you have some thresholds of service even for four-star restaurants: For example, if you have a reservation, you expect to be seated within minutes of your arrival. And you expect a server to take your order in a timely way. If you don’t have a reservation, the maitre d’ or hostess will perhaps quote you an expected wait time; if it’s unacceptable, you’ll go elsewhere. If it’s acceptable but they don’t seat you in that time, you are dissatisfied. The service delivery was not fit for its purpose, which is to say the reason why you chose to eat there.

A Software-Delivery Example

The restaurant experience is actually not too dissimilar from software delivery. The customer expects software (product) but also expects it on certain terms or within certain thresholds (service delivery). A team works hard to deliver the right features and demonstrates them at some frequency; at the demo, the team likely will explicitly ask “is this what you wanted?” What’s often missing is the “are these the terms on which you wanted it?” Whether in the demo or a separate meeting, we need to also review service delivery. This is where we look at whether our service meets expectations: Did we deliver enough? Reliably enough? Respond to urgent needs quickly enough? The good news is that we can quantitatively manage the answers to these questions. Using delivery times, we can assess whether the throughput is within a tolerance. One team used a probabilistic forecast and found that their throughput was not likely to help them reach their deadline in time. Conversely, another realized that they were delivering too fast and could stand to reallocate people to other efforts. Also, for instance, when we set up delivery-time expectations (some people call these SLAs), like delivering standard-urgency work at a 10-day, 85% target, we can then make decisions based on data rather than feelings or intuition (which have their place in some decisions but not others). These expectations needn’t be perfect or “right” to begin; set them and begin reviewing them to see if they are satisfactory.

Having an explicit review of fitness criteria, especially for service-delivery fitness, is a vital feedback loop for improving. Rather than having the customer walk away dissatisfied for some unknown reason, we can proactively ask and manage those expectations and improve upon them. Often these are the unstated criteria that ultimately define the relationship and create (or erode) trust; discover them and quantitatively manage them.


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.

Background

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.

Retrospecting

IMAG6886.jpg

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
    IMAG6875

    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).

Summary

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.

Challenges

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: