Patrick Henry lithograph

Forecasting by “The Lamp of Experience”

https://www.loc.gov/item/2001700209/
No, this is not a planning-poker meeting.

Many people are familiar with Patrick Henry and his “Give me liberty, or give me death!” speech on March 23, 1775, whose closing line became the war cry of the revolution that led to independence, which Americans celebrated yesterday.

Less well known is Henry’s position on forecasting! But the wisdom of this American patriot is as prescient today for us in knowledge work as it was for the fledgling freedom-seeking colonies of the 18th century.

First, here’s that founding father on the idea of basing decisions on hopefulness:

…it is natural to man to indulge in the illusions of hope. We are apt to shut our eyes against a painful truth, and listen to the song of that siren till she transforms us into beasts. Is this the part of wise men, engaged in a great and arduous struggle for liberty? Are we disposed to be of the number of those who, having eyes, see not, and, having ears, hear not, the things which so nearly concern their temporal salvation? For my part, whatever anguish of spirit it may cost, I am willing to know the whole truth; to know the worst, and to provide for it.

I was once involved in a leadership group that met weekly to review its work board. The chair of the group would go card-by-card through the in-progress tasks and ask each responsible person when he or she thought the card would be done. “Oh, about two more weeks, I’m pretty sure,” was the inevitable reply. Two weeks was the time-honored estimate that the leadership group had learned was just right: Not too ambitious as to require an accounting at the following week’s meeting, but also not too much of a sand-bag as to call the boss’s attention. It was also, I suspected, largely based on hope.

But if not borne of hope, how would Henry propose we plan? He continues:

I have but one lamp by which my feet are guided, and that is the lamp of experience. I know of no way of judging of the future but by the past. And judging by the past, I wish to know what there has been in the conduct of the British ministry for the last ten years to justify those hopes with which gentlemen have been pleased to solace themselves and the House.*

Indeed! Henry was encouraging his fellow patriots to lean against the human optimism bias and use data to inform their decisions.

In my example with the leadership group, after hearing leader after leader parrot the “two weeks” estimate, I went through the archive of cards that had been completed. Sure enough, hope was hardly a reliable guide: I found that the 85th-percentile completion mark was 63 days! That meant that 85% of the time, work finished in 63 days. Even the 50th percentile was 35 days, more than twice the two-week estimate.

To paraphrase patriot Patrick, the group simply had nothing to justify those hopes with which they had been pleased to solace themselves and their chair. Rather, they could have used the “lamp of experience” to forecast when their work would be completed.

Ultimately, Patrick Henry’s data-driven argument held sway, and the colonies acted not by “hugging the delusive phantom of hope” but by seeing that the battle “is not to the strong alone; it is to the vigilant, the active, the brave.”

Fortunately, in most organizations, moving toward a data-driven way of making decisions isn’t a life or death proposition as it was in 18th-century America. It can, however, require vigilance (track your data!) and a bit of bravery (dare to offer your estimate in probabilistic terms!).

*The “data points” of British conduct that Henry enumerated:

Is it that insidious smile with which our petition has been lately received? Trust it not, sir; it will prove a snare to your feet. Suffer not yourselves to be betrayed with a kiss. Ask yourselves how this gracious reception of our petition comports with those warlike preparations which cover our waters and darken our land. Are fleets and armies necessary to a work of love and reconciliation? Have we shown ourselves so unwilling to be reconciled that force must be called in to win back our love? Let us not deceive ourselves, sir. These are the implements of war and subjugation; the last arguments to which kings resort. I ask gentlemen, sir, what means this martial array, if its purpose be not to force us to submission? Can gentlemen assign any other possible motive for it? Has Great Britain any enemy, in this quarter of the world, to call for all this accumulation of navies and armies? No, sir, she has none. They are meant for us: they can be meant for no other. They are sent over to bind and rivet upon us those chains which the British ministry have been so long forging. And what have we to oppose to them? Shall we try argument? Sir, we have been trying that for the last ten years.

Advertisements

Explicit Policies and Classes of Service

IMAG4717As I was driving today, I pulled up behind a car that was stopped at a light. The light turned green, but the car didn’t move. I waited a couple of seconds, then switched lanes and drove around it. As I looked in my rear-view mirror to see the car just beginning to move, I thought “What a terrible driver!”

Why did I think that? It’s because we expect certain levels of driving in a civilized society, minimal thresholds of competency, or, if you will, service. I quickly thought of my daughter, who is learning to drive and displays a PERMIT DRIVER sign in the back of our car. Of course, the reason that learners need to display such signs is largely to manage expectations, which is to say, to convey that other drivers should expect a lower class of service around this driver. For instance:

  • Longer reaction time at stop lights
  • Less predictability with stopping distances
  • Reduced average speeds
  • Greater variation in lane position

Which brings us to the idea of explicit policy and classes of service. The permit sign gives some indication of what other drivers can expect. It makes semi-explicit a policy: For people learning to drive, we are more tolerant of substandard driving service. Among other things, this means that we’ll give a greater berth for these cars and agree not to get too angry with them. For most policies, including this one, we should not only name the policy but also define what treatment or behavior that entails. This allows all participants in the system to know what is expected and how to tune their behavior accordingly. For a learning driver, she knows that she can drive more slowly than the speed limit, and it’s acceptable.

The same is true in knowledge-work systems. We make policies explicit and define them with classes of service, which are policies for selection and processing based on different customer expectations, relative value, risk or cost of delay.

Some examples in work might be:

  • Production-defect fixes are completed 85% of the time within two days.
  • Standard work is completed 85% of the time within 11 days.
  • We pull UI fixed-date work into Ready when it is within 30 days of due date.
  • High-risk due-date items are completed with 95% ontime performance.
  • We always have exactly one tech-debt item in progress.

These classes of service then enable a conversation around the fitness of the delivery system. We ask (at a Service-Delivery Review), is this an acceptable service level? How much are you willing to pay to increase it? Are we possibly over-delivering, in which case we might allocate capacity in a different way?

Going back to driving, we have only two policies, one for licensed drivers and one for learners. But in reality, we experience more, just as I dealt with the “distracted driver,” who had her own unique set of service expectations. As in knowledge work, I might not have been dissatisfied with her performance if she had made explicit her policy — I’m distracted and may have a delayed reaction at stop lights. I would merely have expected it (and sought to change it at the next Dept. of Motor Vehicles service-delivery review, if such a thing existed!). As for those learners out there, here’s my proposal for an updated sign:

new sign

Culture Add Over Culture Fit

You’ve probably heard of the culture-fit interview. Maybe participated in one. Organizations and teams rightly want to know not only does this person have the skills and aptitude for the job, but also “will this person work in our particular environment?” Prospective employees also want to know that. But by emphasizing culture fit — the assimilable qualities of the person — we may lose sight of an important benefit of bringing new people into our organizations: the person’s additive qualities — new ways of thinking and working, external experiences — that bring energy, creativity and improvement that we can’t simply bootstrap ourselves into from within.

Why Culture Fit Can Be Pernicious

First, don’t hear what I’m not saying — that seeking culture fit itself is unhealthy. Culture fit is absolutely an area of concern, and organizations and candidates should of course consider it in the mix of hiring and development attributes. However, we need a counterbalance, a corrective to it. That’s because culture fit is all too often a one-way concern: Will the person fit in with us? Lest we miss out on what our new hires have to offer, we need that to be bidirectional and mutual: What can we co-create that we couldn’t before?

The lure of culture fit can be particularly pernicious for organizations that pride themselves on their culture. And it makes sense: You don’t want to hire a person who is at odds with the group’s core values and principles. But the tribal nature of culture means a rejection to some degree of outsiders. No matter how much lip service we give to diversity and inclusion, we’re often satisfied with a superficial accomplishment: We’ve hired people who help us create a rainbow in corporate photos, but unfortunately that diversity is only demographic deep. The truly helpful impact is measured only insofar as we allow their ideas to penetrate the often impermeable boundaries of our culture after we’ve hired them.

For example, I once worked with a leadership team who had been in the organization for many years and typically managed their work through spreadsheets, which meant that the group tended to meander in their discussions and would jump from one priority to the next. When I joined their ranks and offered the idea of making the work more visible on a card wall, the group had a choice:

  • Reject the idea out of hand
  • Nod and passively acknowledge the idea but ultimately ignore it
  • Consider then either try or reject the idea

Only the third option demonstrates that a) the group was intellectually curious enough to discover new ways of working and b) viewed their new colleague as having something to contribute. Unfortunately, this group’s choice was to ignore it. Only long afterward did I realize that it wasn’t intentional or out of malice but merely because the group had become so ossified that they couldn’t even countenance what it might mean to work differently. Partly because they had been successful on their own, they had no mental model for improvement that originated somewhere else. It’s the opposite of the “prophet without honor in his hometown” problem; it’s more like “Can anything good come from outside of here?”

And that’s the danger of culture fit: Without intentional and disciplined practices that keep us open to the new members of our groups, we will atrophy in our existing ways of thinking and working.

Culture Fit without Culture Add

Many new hires struggle to find and stay in the flow channel, psychologist Mihaly Csikszentmihalyi’s concept for “being in the zone,” or full engagement in work. I believe that much of the reason new hires find themselves languishing outside of the flow channel is attributable to a lack of mutual integration and intentional concern for knowing (a person feeling unknown) and putting to good use the competencies of the people we’ve invited to come work alongside us (feeling unwanted).

By paying attention to culture-adding behaviors, we can design our organizational and team experiences to bring people back into the flow channel.

How to Emphasize Culture Add

So we need to balance two goals:

  • Help the new person to fit into the organization and
  • Help the organization to create space for the new person.

Some organizations offer “get to know you” activities during orientation, which is a helpful start. But we should go beyond learning about the person’s hobbies and family. What special qualities and skills does he or she have to bring to work to positively impact us? This is additive or supplemental thinking.

Heidi Helfand talks a lot about dynamic reteaming and how a single change — someone joining the team, someone leaving it — means that you have a new team. We need to take a moment to acknowledge that, rather than carrying on as if nothing happened. We have a new team member; what does that mean for us?

When I led the coaching practice at Asynchrony Labs, one of the questions we coaches would always ask each other about each candidate was “What can this person teach us?” That is, what new or different ideas or competencies might this potential teammate introduce to our group so that we might collectively improve ourselves? Though we wanted someone who would generally share our philosophical approach, we also didn’t want to remain as we were. We explicitly acknowledged that we had a hole in our group, and though we may not know exactly what it was, we pursued filling it from outside ourselves. It’s the perfect culture-add question, because it ensures by its nature that you’re honoring and intentionally expecting the new person’s unique contributions.

Some other options for emphasizing culture add:

  • Marketplace of Skills activity 
  • Strengths Interview (from First, Break All the Rules), which is then shared with each of the new hire’s teams for the first year
  • Create opportunities for the new hire to teach his or her new team (or other group) something that he or she brings ; another option is to have each new person, as part of orientation or onboarding, actually have a spot in the agenda to share something about what he or she brings. This demonstrates the organization’s view not only that each new person is valued but that the organization has a need to learn and improve and that the new person in their midst is going to help.
  • Personal Best
  • The Ten Faces of Innovation activity
  • Follow him or her on Twitter, etc. What’s the Twitter-follower imbalance? That is, how many of your team does the new hire follow, and how many of the team follow him?
  • Give the new person point of privilege in retrospectives and other team meetings

Ultimately we need to be taking the disciplined steps each day to ensure that culture adding happens, because in our tribal ways, it’s unnatural. Build in a policy whereby someone from the organization — I call this role the onboarding concierge — helps the group to learn about the new hire to find out what the person loves, especially the stuff outside of the role you’ve hired him or her for. Even simple changes in how we talk about our approach can help, like how one company changed their approach from “culture fit” to “values fit.”

Herman Miller’s Ed Simon (as quoted in The Fifth Discipline) summarizes the challenge well:

Embracing change does not mean abandoning a core of values and precepts. We must balance our desire for continuity with our desire to be creative. We must learn how to not abandon that core, while simultaneously letting go of past ways of doing things… This requires a new paradigm, a new model of how organizations work — organizations that operate in a continual learning mode, creating change.

For further exploration:

 

Profiles in Cost-of-Delay: “Intangible Fixed-Date”

TL;DR
  • The “Big Four” cost of delay profiles (a.k.a. archetypes) — Expedite, Fixed-Date, Standard Urgency, Intangible — are usually sufficient.
  • In my personal kanban, I have seen a new archetype emerge, one that has aspects of both Intangible and Fixed-Date, which I’m calling “Intangible-Fixed-Date.”
  • This profile is less for the purpose of selection and more for scheduling.
  • So far, the main application of “Intangible-Fixed-Date” for me is for buying airfare, whose cost-of-delay curve fits none of the “Big Four” curves.
  • I use a couple of features in Kanbanize to deal with this new profile slightly differently from the other profiles, namely by creating a separate swim lane and using two dates (rather than one).
  • Takeaway: “Listen” to your data, patterns and behavior of work items and be flexible enough to adapt and create new profiles when they emerge.

I routinely use cost-of-delay to assist in scheduling, selecting and sequencing work, both in professional settings and in my own personal life. The “Big Four” cost-of-delay profiles (aka archetypes) promoted in the Kanban community — Expedite, Fixed-Date, Standard Urgency, Intangible — are usually sufficient for the work that organizations, teams and I personally need to handle. However, lately in my personal kanban, I have seen a new archetype emerge, one that has aspects of both Intangible and Fixed-Date, which I’m calling “Intangible Fixed-Date.”

Basically, the new profile has arisen from the need to handle airfare purchasing, something that I do somewhat often. Since I’m not independently wealthy and I like to do right by my employer when I’m traveling on business, I care about the cost of airfare. Anyone who travels knows that there is some optimal time to buy airfare (even if he or she doesn’t know exactly when that is). I want to be able to research fares just-in-time to get the best deal. However, if I model the task as a simple fixed-date item, I either have to use the true date by which the cost-of-delay is unacceptable (that is, the day I need to be somewhere) or use a fake deadline. I typically added the task to my Fixed-Date lane with its true deadline, then would occasionally check it to see if it “felt” like I should act, but it was too easy to forget about it until past a responsible moment, even if it wasn’t the last responsible moment. Which brings us to the crux of the problem: This type of item has two last responsible moments, the financially last responsible and absolute last.
Let’s review the cost-of-delay curves of the existing profiles:

COD expedite
Expedite

COD standard
Standard Urgency

COD intangible
Intangible

COD fixed date
Fixed Date
According to the reliable Andy Carmichael and David Anderson in their Essential Kanban Condensed, Fixed-Date items “have high impact but only if you miss the deadline. The scheduling imperative here is to make sure you start before the last responsible moment and deliver before the deadline.” Also, you don’t get any economic benefit from completing the work before the deadline. In software delivery, this usually means understanding how long it can take you to complete the work (see your handy delivery-time histogram), then backing up from the deadline from there based on risk tolerance. However, booking airfare doesn’t take much time (I can do it in a few minutes) — so that’s not a concern. But the deadline only represents the absolute last responsible moment, so this curve is insufficient.

If airfare price increases were linear, I could use a standard urgency profile blended with the fixed-date. But some basic research shows that price increases have an inflection point somewhere around the 30-day mark, although the lowest prices may occur earlier:
airfare-prices-graph
CheapAir-2013-Domestic-AirFares2
Other factors matter, too, of course (seasonality, specific locations). But I don’t need to get too deep into modeling that yet — I just need a better solution. That means incorporating the Intangible curve, whose items “have an apparently low urgency,” but that indicates “a rise in urgency – possibly a steep rise – will happen in the future.”
My airfare purchases exhibit aspects of both curves, though neither is sufficient. Unlike a typical intangible item, I actually do know when that future date will be, along with a rough idea of when the “rise in urgency” will happen. And unlike a typical fixed-date item, there is some economic benefit from doing it sooner than the deadline.

COD intangible fixed-date
Intangible Fixed Date

Now that I understand the cost-of-delay curve, I need to be able to handle it in my kanban system. One approach that I’m trialling is to create a separate swim lane — “Intangible Fixed-Date” — and use a second date to signal readiness (the second date being my optimal time to commit).
Here’s how it works: Say I find out on Sep. 6 that have to be in Chicago on Nov. 6. That’s two months away. Given that airfare cost won’t typically rise until about 30 days out, I don’t want to worry about this yet, which is to say, I don’t want this card on my Requested column yet. So I set up a rule in Kanbanize (my work-visualization tool of choice) to keep it in the backlog until 35 days out (the five-day buffer allows me some flexibility), at which time it moves the card from the backlog to Requested.
It has the ultimate deadline — Nov. 6 — displayed on the card. But since it’s in its own swim lane, I have an explicit policy that I begin work on these items as soon as they appear in Requested.

Screen Shot 2017-10-05 at 12.52.01 PM

If I want to really be disciplined, I can then set a service-delivery expectation that sets the bar for how well I handle these (e.g., 90% of Intangible Fixed-Date items will be completed within five days), and analyze my performance at my personal service-delivery review. But now I fear I’m exposing just how geeky I am (if that wasn’t clear already)!

So what’s the takeaway? Well, you might find value in this “new” cost-of-delay profile (if you need to book airfare, or to plan birthdays or anniversaries, which follow a similar curve). But abstracting out a bit, the idea is that it’s helpful to pay attention to — “listen” to — your data, patterns and behavior of work items and be flexible enough to adapt and create new profiles when they emerge. Pursuing incremental, evolutionary change is one of the underlying principles of kanban method; improve using models and experiments is one of its core practices.

Special thanks to Prateek Singh, Josh Arnold and Mike Burrows for their early feedback in the Lean Agile and Beyond Slack community.

 

Theory of Constraints in the Wild: Queuing for the Tube

Tube queuing after the Tottenham match at Wembley
Tube queuing after the Tottenham match at Wembley

When a WWT colleague invited me to the Tottenham – CSKA Moscow Champions League match Wednesday, he treated me to more than simply world-class soccer — he unwittingly gave me a chance to see Theory of Constraints in action: after the match, while we waited for a Tube ride.

Theory of Constraints tells us that every system has a single constraint — which is anything that limits a system’s performance relative to its goal — that governs its throughput. A particularly effective way of dealing with a constraint (aka bottleneck) is Eli Goldratt’s Five Focusing Steps, which I talk about this way:
  1. Identify the constraint
  2. Optimize the constraint
  3. Subordinate everything to the constraint
  4. Add supply to the constraint
  5. Goto 1
If you’ve ever been in London during rush hour, Step 1 is easy: The constraint is the supply of train cars. At busy times, London simply has more people needing to ride than it has trains to take them. Step 2 is fairly straightforward: We optimize the constraint by ensuring that the constraint is
  • always busy (Londoners are particularly adept at squeezing as many people as can fit into the car, so this is never a problem!), and
  • is only ever doing “value-adding” work, which in this case is moving passengers forward (as opposed to failure demand, which doesn’t typically happen in the Tube in the form of redoing work — going backward — but does often take the form of people getting their bags or themselves stuck in the doors).
That’s where Step 3 comes in. Only after we’ve properly satisfied the first two steps, we want to subordinate — which is simply to adjust the speed of things arriving to the constraint and departing from it to match the cycle time of the constraint. For the Tube, that means making sure that when a train stops, the platform has enough room for the passengers to spill out and leave the station. But the more vital subordinating occurs upstream — such as after the 62,034 fans emptied out of Wembley Stadium and headed for the nearest Tube station. That’s what happened the other night, as the photo shows: Tube security personnel created multiple upstream “batches” of people by holding up signs with either a red Stop or green Go (an indicator of capacity, a kanban). Only when the batch of people saw the green could they advance to the next “gated” area and finally onto the platform. This is exactly the “pull” behavior that an explicit  work-in-progress limit encourages in knowledge systems: Rather than pushing as much work forward toward the constraint, we wait to advance new work until we get the signal, which indicates we are now under our WIP limit and therefore have capacity.
The result was a very orderly movement of people through the station and into the trains, avoiding the evil of overburdening and its demon spawn of waste, unpredictability and delay (and in this case, possible physical harm). This was good enough for the problem at hand; Step 4, add supply, is likely too expensive because it means adding trains to the line for what is essentially an exceptional case (a mid-week soccer match at Europe’s second-largest stadium). In any case, the result is testable, in that we can review the three TOC measures to see if any improved:
  • Throughput (should go up)
  • Operational Expense (should go down)
  • Inventory/WIP (should go down)
Presumably, the London Tube officials have indeed tested whether the practice of subordinating has improved the situation. My guess is that the practice has increased throughput, while holding steady their operational expense and WIP (which is irrelevant in this case). It has probably also improved human safety.
Seeing flow in the physical world — especially when we’re personally involved! — is usually obvious. Knowledge work, on the other hand, is by its nature invisible, so we need special lenses to see bottlenecks in order to manage and improve flow. Thankfully, we have aids such as kanban boards and cumulative-flow diagrams that make visible the flow of work — work in progress, throughput and average approximate delivery time. It’s also helpful to be aware of physical manifestations — such as post-match queuing for the Tube — to train ourselves to look for flow, inhibitors to it and ways to manage it.

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: