Monday, September 07, 2020

Taking Agile Remote: Process and Tools
by Ron Lichty

“In-person is the gold standard,” I heard a colleague say. We were discussing the impact of the pandemic on team communications.

The impact of the pandemic, of course, is that there’s almost no in-person to be had. Our software development world is now almost entirely remote.

Our world was a long way from the gold standard prior to the pandemic. I was far from first to the party when, at Apple 30 years ago, I outsourced development to a programming team in Ohio. Despite the best intentions of the Agile Manifesto’s signers, when they stated, “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” the trend continued with organizations scattering teams around the world, and some - some I managed - entirely remote.

But let me step back…

I was first introduced to agile in the form of XP 21 years ago, 1999, when I was at Schwab, and I soon began managing, leading and coaching agile teams. My first consulting engagement introducing agile was 10 years later. It was 2009, and I was advising a startup trying to find its path. While it had been following a north star that had mostly stayed the same, the path had veered every which way - a real challenge for a product team trying to execute what had been a six-month waterfall plan that was now into its 15th month.

Even a modicum of agile practices, I thought, would help this startup and its team. The team already had the building blocks: feature names in a spreadsheet. If we just ordered them effectively and developed in short iterations, the team ought to deliver a cadence of product increments with much earlier customer outcomes.

Before ordering features, I facilitated discussion of what “done” should mean - a definition team members could apply to every feature. Then we transcribed their features out of Excel onto 3x5 cards so we could relatively size them, snaking the story cards back and forth on a conference room table until we had them in size order, waiting to make a second pass to add “points” numbers. The sizing was crucial to backlog ordering, in which we stack-ranked the features so they were ordered not just by value but, taking size into account, ROI. The ordered backlog then supplied fodder for the team to plan sprints, each of which would deliver a product increment - the highest-value features we could complete in two weeks. With customer-focused plans each targeting just two weeks, the team executed.

A colocated team plus practices and mindset. Relatively easy transition to relatively agile. Dramatically better than what they’d done before.

Lots of teams weren’t colocated, of course, maybe even most, but most of the ones reaching out to me, early days, were colocated in one or several distributed locations.

Scrum for Distributed Teams

When product development was in several locations, I sometimes found myself on the road, while other times was teaching remotely. I was soon delivering the presentation parts of training using some of Zoom's predecessors - Skype, WebEx, Google Hangouts and Adobe Connect. Jira and a ton of other tools provided a facsimile of cards on a wall. Definitions of Done could be collaboratively composed in Google Docs or Confluence. Wikis worked reasonably well for capturing retrospective observations and learnings.

But a key part of agile backlog grooming relies on ordering by ROI, or “bang for the buck”, which in turn relies on relative sizing of stories to supply the “buck” — the “I” in “ROI” — the relative investment required. I wasn’t much impressed with Planning Poker - I’d much earlier learned a technique much more powerful — the Team Two-Pass Relative Sizing method that Steve Bockman devised - snaking.

Snaking is a two-step process: first the entire team sorts the stories by relative time and complexity on a conference table, resulting in a snake of 80 or 100 stories in ascending order by how long they’ll take relative to each other.

Here is what sizing looks like, when the team is in the room: 120 stories in a snake, smallest to largest
Agile two-pass sizing by a colocated team: in a typical case, it takes a team 3-4 hours to snake 80-150 stories (in this case 120), from smallest story to largest epic and add points

Then, after labeling the smallest story card a ‘1’, the team continues to label stories 1s until there is a card that is clearly no longer a 1 but twice that, so labels it a ‘2’; and so on.

Less than half a day. Simple, fast, collaborative, and powerful when the team is in person. Even most distributed teams were in person - they were essentially groupings of in-person teams distributed from each other. But some weren’t. Some were entirely remote.

As simple as card-sorting and card-labeling seems, I’d found no tool to support it for entirely remote teams. I had been looking for years. Could card wall tools suffice? Nope, they’d never considered my use case. (No, not even Trello. Not even close.) Google Draw? Not really. Spreadsheets? Not on your life. List tools? Hard, very hard, to swap card order. PowerPoint, maybe? Put each story on a slide and switch to Slide Sorter view? But PowerPoint begins with cards in a grid - very different from starting from a stack of 3x5s and putting one at a time onto the sorting “table” in the relative position it belongs.

And then, an entirely remote team

I’d stopped looking for a workable tool when, in 2015, a team in rural Maine asked if I could fly out to help their product team be more predictable. One problem - while headquarters was in rural Maine, the programmers were not. At least most of them weren’t. Turns out there aren’t a lot of .Net developers in rural Maine. There lay the problem. The programmers were scattered across the country.

I described relative sizing to my new client - creating a snake of cards on a conference room table. And they described this tool called RealtimeBoard (now renamed Miro) that they  were using for retrospectives - virtual stickies on a virtual whiteboard - that they thought might do the trick.

I was stoked.

Miro was the first tool I’d encountered that really let entirely remote teams accomplish relative sizing.

It was pretty easy to get started with Miro. Much as we’d transcribed feature names out of Excel onto a stack of 3x5 cards, now we were scribing them onto a stack of virtual cards in Miro. (A few months later, Miro and Jira had API integration, at which point Miro auto-generated a bevy of cards, each an instance of a ticket in Jira.)

Relative Sizing

To teach teams the sizing technique, I start with a warm-up exercise, asking students to size fruits. We start with 12 fruits. Agile stories typically have a “why” and the why for all 12 fruits is the same — “I want to eat some fruit” — it’s just the fruits that differ.

Fruit-sizing exercise — when teams are colocated

The exercise is for the team to put the 12 fruit cards in order: not based on how long to eat the fruit, but based on the effort required - the combined “cost” of preparing a serving of the fruit and cleaning up after eating it (much as, in software, we need to combine development and testing efforts). Twelve cards are a small enough number to get a quick first experience with snaking. I give teams five minutes to put them in order by effort, three more minutes to number them with the usual modified set of Fibonacci numbers.

It turned out that Miro was a pretty good tool for remote teams to snake the relative cost of 12 fruit.

Fruit-sizing exercise — 4 teams worked simultaneously, each on their own “sorting table”

The more complicated next exercise is a scrum-ified version of the XP Game, in which teams size then order a backlog of puzzle and game activity "stories" (for example, sorting cards or calculating a bunch of sums), then plan and execute short sprints, their goal to deliver the most customer value. Here, Miro was able to not only emulate conference-table sizing, but also a card wall from backlog to sprint plan to user-acceptance-test to done, as well as the activities themselves.

The Scrum Game —three teams working simultaneously, each with their own stories, sorting table and card wall

Finally, I facilitate workshops during which teams size stories from their own software projects. It’s common for a team to have fifty or eighty or a hundred or more stories in its project backlog. Provided we limit the number to a maximum of 150, we size them all.

The most recent Study of Product Team Performance - a survey of teams all over the world - revealed that higher performing teams tend to work from backlogs more than three months long. And those teams have sized not just the stories selected for the next iteration but all of their backlog’s features, epics and stories.

Comparing Miro with a real conference table

During snaking, when the team gets beyond a dozen stories and wants to insert a story somewhere in the middle, the difference between cards on a table and an online Scrum board becomes apparent. Making physical space on a table is something we learned to do as children. Whereas we have to learn the interface to leverage an online tool to move a bunch of cards at a time.

On a real-life table, we usually snake the cards back and forth. But I discovered that, on a virtual table, rather than snaking cards back and forth, it is easier to organize the cards in rows, one above the next, snaking from the end of each row of cards back to the beginning of the next row, each row arranged from smallest to largest, left to right.

Snaking a virtual team's stories is more easily done in rows

In my experience, where snaking is easier on a table, rows are easier in virtual space. If the team developing Miro ever delivers a feature to automatically insert a card into a matrix of rows of cards, it may make virtual sizing easier than real-space sizing! But for the moment, in-person - people proximity - the gold standard - still wins. But Miro is pretty good. It integrates with Jira. And I’m delighted to report that Miro is no longer alone in providing this functionality. A year ago I was engaged by a client already using a remarkably similar tool, Mural.

Delivering a Scrum experience

One of the things my clients love about my scrum trainings is that they're immersive. I run classes as agile projects. I put up a card wall with a backlog of relatively sized "learning stories" that have been ordered to always be delivering the next-highest-value learning. Much as we do with software project stories, my learning stories have relative story points. At the end of one-hour “sprints,” I update a Burn-Up Chart, yielding emergent velocity that predicts how many of the learning stories in our backlog we will likely complete by the end of class. This makes the class experiential — I’m not just teaching about scrum, but immersing my classes in it.

Setting all that up for real-world teaching is time-consuming. A few days beforehand, learning stories get handwritten onto scores of giant stickies for each class. Day of class, I arrive 45 minutes beforehand to transform a classroom wall into a backlog of learning stories poised to, one by one, march across the card wall, from “Backlog” through “In Progress” to “Done”. I prep a second wall with flipchart pages: one the burn-up chart, others blank to record students’ hopes and wants from the class, and later what they’ve learned and will take away.

While learning Miro and getting my first remote workshops set up was as tedious and slow as getting ready for my first classroom trainings years before, it provided a remarkable facsimile. Even better, it turned out downright handy for subsequent classes: once I'd set up my online Scrum board for the first class, I found I could save it off and reload the setup as the basis for subsequent classes.

Training scrum board of learning modules, each notated with a relative story-point size, as class begins
Scribing student hopes for their learning - and, hourly, updating a burn up chart - were similarly straightforward

Retrospectives, too

That first client five years ago that introduced me to Miro had been using it for Retrospectives. Bobbie Manson from Mingle Analytics had been leveraging Miro to run one of the best agile Retrospectives I had yet seen. (I emulate her approach when, at the end of my virtual classes, we retrospect on the training, both to help students cement their learnings and to get feedback on what I can improve.)

Retrospective by students, after three days’ agile training & workshops

Because I think it’s been the stumbling block for distributed teams, though, it’s snaking - the agile relative sizing practice, in which we use cards on a virtual whiteboard in place of cards on a table - that makes using Miro and Mural so expedient. Relative sizing, because it forms the backbone on which velocity and predictability are based, is one of the practices I see teams continue to heavily leverage long after class completes. And the tools' usefulness is significantly enhanced by their integration with Jira: epics and stories are easily exported from Jira into Miro or Mural; when the team determines relative points and writes them on cards on the Miro board, they are automatically updated through the API to the tickets in Jira.

As Steve Bockman, relative ordering’s creator, has noted, the ordering technique is equally useful for relative valuing:
  • Product owners snake stories from most-value-to-customers to least. 
  • Product organizations snake project opportunities from most contribution to company objectives to least. 
  • Tech leads and architects snake tech debt and other technical product backlog items from most urgent and highest risk to least. 
  • Engineering leaders snake engineering, infrastructure and debt projects the same.
Relative value divided by relative size yields ROI - return on investment - bang for the buck. It’s a useful guide to seeing what to do first and next and next after that.

Prior to the pandemic, I had trained teams spread across as many as a dozen different geographies as well as remote teams on other continents. Then, a combination of Skype and Miro had not only let me train teams in remote locations and scattered across geographies, but also enabled those distributed teams to continue to use agile’s powerful, collaborative techniques and practices after I was gone.

Having five years of experience with a remote collaborative tool gave me a major headstart to serving suddenly remote teams with the onset of the pandemic. A combination of high quality conferencing like Zoom and virtual whiteboarding like Miro and Mural provide a serviceable stand-in for physical cards, card walls, sizing, ordering, charts and all the rest - for every team.

Saturday, May 30, 2020

High Performance Teams Know Where They’re Headed
by Ron Lichty

Our 2019 Study of Product Team Performance, released this month, reveals that high performance teams tend to work from backlogs more than three months long. And those teams have sized all of their backlog’s features, epics and stories, not just the stories selected for the next iteration.

Each Study of Product Team Performance - this is the sixth study we’ve undertaken - surveys team members on thousands of product teams around the world, asking them to characterize their team’s performance - high performing, low performing, or something in between - and to share their experiences and approaches. Our data analyst then looks for and identifies correlations between practices and team performance.

This year’s study - based on our survey that wrapped up in December - identified six practices and characteristics that highly correlate with high performance teams:
  • awareness of and alignment with their company’s business strategy (only a quarter of teams!)
  • accountability to customer satisfaction targets (barely more than half)
  • innovation process maturity company-wide (less than 10% report their companies are mature)
  • product managers spend at least 30 percent of their time in the field (only 11 percent do)
  • using profitability as a criterion to prioritize requirements (less than two-fifths do)
  • sizing all of the stories in a requirements backlog that is sufficient in size to represent more than three months’ effort (less than a fifth do)

The question we asked in the survey about the latter:
Do individual contributors size all the stories or requirements in the backlog or just those that have been selected for the next iteration?

Reading the chart from the right, the answers revealed that almost 16% of teams don’t size their stories at all. Sadly, 17.9% have only an iteration or two of stories in their backlog at any time. Two-thirds have quarter-plus-length backlogs, but only 17% size that entire backlog up front.

What stunned us were the correlations:
    ▪    the 17% that had quarter-plus-length backlogs and sized the whole backlog correlated with the highest performing teams
    ▪    the teams with only a sprint or two of stories in their backlogs correlated with the lowest performing teams

To the low-performing teams, clearly product managers and product owners providing their teams with a bare minimum of stories are struggling. By barely staying ahead of their teams’ development capacity, product people aren’t providing enough stories to be able to ensure the team is focused on the highest value work, there’s no ROI-based stack-ranking to be had, they’re likely guessing with regard to what to do next, and stories are likely not well-formed with their acceptance criteria likely incomplete.

To the high-performing teams, we have no way of knowing that they’re using low-cost, no-waste estimating techniques like Steve Bockman’s relative sizing method (also known as snaking, laddering, and the team estimation game). In fact, sizing a quarter-plus backlog seems counter-intuitive given we all know that few teams deliver much more than half of a backlog that long, what with estimates being guesstimates and particularly the introduction of new work and adjustments to work incumbent from getting early feedback and iteratively delivering the highest-value increments of the product.

But given the correlation with high performance, it’s clear that the cost of sizing the whole backlog is offset by product managers being able to fold size impacts into their thinking. They’re able to avoid the waste of stack-ranking unreasonably costly stories at the top of the backlog. And given that relative sizing takes less than half a day and doubles as an exercise during chartering to familiarize the team with where product managers think development needs to be headed, sizing the entire backlog can be a low-cost entry point to high performance.

Take a look at all of our survey results - and at the six correlations with high performance - by getting a copy of the study itself. My own web page devoted to the Study of Product Team Performance has a pointer to the study just released - pointers to several earlier ones - and summaries of all the earlier studies.

There are also callouts to correlations we found in each previous year’s Study of Product Team Performance specific to software development performance, among them these practices and characteristics that correlate with high performance teams:
    ▪    definitions of done crafted by the team
    ▪    effective standups held daily
    ▪    standout team onboarding
    ▪    quality product management
    ▪    cross-functional collaboration and trust

Read more!

Monday, December 16, 2019

Better Standups
by Ron Lichty

What makes a standup effective?

We know, from the Study of Product Team Performance, that the highest performing teams hold effective standups daily. Not every other day, not every third day, not occasionally. Daily.

But what constitutes an effective standup?

I’ve stepped into scores of software development organizations in the last seven years, between taking interim VP Engineering roles, advising business and product leaders on team effectiveness, and training and coaching teams and executives in agile. I’ve definitely seen highly ineffective standups: ones with no sense of urgency, no 15-minutes-or-less timebox (or no enforced timebox), no focus. Those are the egregious problems.

But there are several fundamental steps to high effectiveness I see all too few teams taking.

These days, while most teams have a notion of “the three questions” - answers to which each team member shares with the team each day - few teams address those questions effectively. And almost none have a sense of what underlies those questions - what the standup is actually for: How are we doing? Are we on track to successfully deliver the plan we set out at the beginning of our sprint? If not, how can we adjust?

Let’s start with the three questions: When the three questions are answered perfunctorily - as I’m sorry to say I mostly see - the standup is not a re-planning meeting. It’s just a status meeting. I’m even more sorry to occasionally find it relegated from face-to-face to Slack. I get it, when little more is happening than sharing status - but these teams are losing so much opportunity for it to be so much more.

Of the three questions, the one that is almost always dealt with effectively is the one about impediments: every day, every standup, sharing anything that’s standing in my way - with follow-ups by any and all who can help. Calling out impediments daily and responding to them actively will speed our team and our delivery.

But the other two of the three questions are too often answered with “What did I do yesterday?” and “What will I do today?” That’s not what I want to hear. What I want to hear is “What I accomplished yesterday” and “What I’m going to accomplish today.” “Did” and “doing” lend themselves to answers like “I worked on the subsystem yesterday” and “I’m going to keep working on the subsystem today” - which are wholly uninformative. They give our team much less insight than if we answer “What part of the subsystem did I accomplish yesterday?” and “What part will I accomplish by tomorrow?” 

The power of basing the two questions on “accomplish” is twofold:

1) It signals my team when I’m in trouble. If yesterday I told the team I intended to accomplish yy part of xxx, and I didn’t, that’s a heads-up that I’m not on track for my part of the sprint plan (and if anyone else on the team has time, maybe they might want to offer to help me).

2) By telling my team what I intend to accomplish, I’m exercising one of the core principles of time management: If I tell myself what I’ll accomplish a short time from now, I’m more likely to; if I tell teammates, I’m even more likely to.

The point of the standup - and the point of the two questions - is to see how we’re doing against our plan and to re-plan if necessary. Software can be wildly unpredictable - if we’ve hit a rough patch, we want our teammates to know that the work is more than we anticipated, that we’re likely now overcommitted, that maybe we could use help, or perhaps we need to re-think how we’ve divvied up the work, or to re-plan what we can reasonably finish by end-of-sprint.

Standups too easily devolve to be status meetings. Just this nuance begins to bring opportunity for teamwork back into the standup routine - opportunity for all of us to together consider how to keep our sprint plan on track.

But even with improved wording, just doing a go-round of the three questions can be all too status-ish and too me-ish, and not enough about us, about our plan, about how we’re doing as a team. To bring team and teamwork into focus, for the past few years I’ve been coaching a standup-closing practice I learned from Cathy Simpson, who learned it from Kalpesh Shah at the scrum gathering 2015: Cathy and I both got excited realizing that just by leveraging a simple fist-to-five, we could shift the conversation from “me” to “us” while getting a daily sense of the team’s confidence in its plan.

If you’ve never used fist-to-five, it’s a quick way to get the sense of a group of people in response to a question. On a given signal, each team member raises a hand and votes their answer with a number of fingers. In this case, the question is “How confident are we that we’ll make our sprint plan?” Five fingers signals total confidence we’ll make the plan. Four fingers signals high confidence. A fist is zero confidence - basically, I don’t think we have any chance of making our plan; one or two fingers not much better. 

If, in response to the question, there are any votes other than 4s and 5s, my practice is to ask the team to discuss what it would take to get all votes to 4s and 5s. Often it’s just one or two developers who are struggling - is there someone who can come to their aid, someone who is on or even ahead of schedule with the work they’ve taken on who can help. 

On the other hand, we may face the situation where there’s no recovery possible. How useful to know that at this point, as opposed to discovering end-of-sprint that we didn’t finish one or more stories. Knowing earlier in the sprint lets our product owner be intentional about which story or stories we should put back in the backlog. It won’t be a random story that’s not finished at the end of the sprint, but one that has the least value for the sprint, and for which our product owner now has time to reset expectations with stakeholders that it will not be completed in this sprint. 

Once we’ve adjusted our plan to get it back on track, a fist-to-five should give us 4s and 5s. And we’re back on our way.

The nuances I’ve called out are the kinds of things we might call “hacks,” but they really ought to be referred to as making our standups more effective - getting standups back to their intended purpose.

If you look up the definition of “scrum”, you’ll find, in its rugby definition, that it’s a way “to restart the game.” No surprise, then, that the daily standup is itself sometimes called a daily scrum. It lets us re-start our “game” every day. But the standup only works as a restarting and replanning meeting when we’re all engaged together working as a team, focused together on making our software development hum.

Friday, June 29, 2018

Scaling Teams
by Ron Lichty

Ask any scrum coach about ideal team size and you’ll likely get the same answer: 7 plus or minus 2. That is, 5 to 9 team members doing the actual planning and work of the sprint: developers, testers, sometimes designer or writer or some other role in the 7 +/- 2, maximum-9-sized team (actually 11 with the scrum master and product owner).

So what do we do when we grow from maximum-9 to a 10th team member?

Splitting into two (or three!) teams seems fractious, siloing, so why do we want to cap teams at nine? Why would we split them?

First, let’s recognize that suggesting that the ideal team size is “7 +/- 2” is just plain wrong. Even the smallest of those is too many for “ideal.” By a lot.

The ideal team is much smaller. Software development is a team sport. Team sports are gated by collaboration and communication (the daily scrum: gee, a team sport, maybe we should all talk with each other once a day, huh?). So given communication is gating, what’s the ideal team size?

One. By that definition 1 person is the ideal team. When the team is a single person, all the communication is internal to a single brain - neuron-to-neuron.

But not much software these days gets built by teams of one! In fact, you can argue that one is not a team. My coauthor Mickey Mantle observes, from his dozens of years managing software development, that the number of programmers on an ideal team is 3-4.  “Assuming the teams are competent, a small team will usually outperform a larger team, hands down, and by a significant amount,” he notes. And former Medium VP Engineering Daniel Pupius, now co-founder & CEO of Range, protests that for team sports, diversity of perspectives is as vital as communication. “A sole genius isn't going to solve problems in the way a group can.” But to reduce the noise and friction while driving toward lossless communication, Daniel, like Mickey, would opt for teams of just 3 if 3 were enough to solve the problem at hand.

So agile’s “7 +/- 2” is a maximum “ideal” team size.

Where’d maximum-9 come from? Team theory. Again, team sports are gated by collaboration and communication, so think about the number of lines of communication required for various-sized teams: two people require only one line of communication; three people require three lines of communication; four people, six lines of communication; five people, ten lines of communication… Lines of communication are triangular. Somewhere around 8 or 9 or 10 people, and lines of communication have exceeded any and all likelihood that necessary communication will take place.

Mickey observes, “Rarely have I seen productive cross functional teams that number more than a dozen people.”

Daniel notes that his experience is more aligned “with 3 to 7, or 5 +/- 2 as ideal team size. And I think there are papers that suggest group dynamics shift at 8 people.”

So what do we do when we grow beyond our “maximum 7” or “maximum 8” or “maximum 9” team-size boundary – when we add one more team member?
There are several things that can be done:

1.    Keep the team intact
2.    Split the team
3.    Cell division
4.    Hybrid split

1.  Keep the team intact
First recognize that the “maximum of 9” is really just a guideline – it’s not a law!

In certain cases it may make more sense to simply add an additional team member. When this is done consciously, and recognizing the increased communication burden that an additional team member adds, you can take steps to make communication as effective as possible.

This may not be the best solution, but it is one to consider.

2.  Split the Team
How do we split into two (or three) teams?

There’s an (unfortunate) tendency to split by components. It’s a tendency because it seems to make sense to put like-minded, like-tooled, common-best-practices people together, and because it makes for a management model: We can have a team of database developers managed by a former database developer; a team of front-end developers managed by a former front-end developer; a team of business logic developers managed by a former business logic developer. In that way, each of those teams gets a manager, mentor and coach who understands them.

But our goal is not to deliver components. We were (almost every single one of us) hired to deliver customer functionality that delights users. Component groups cannot deliver features or epics or stories without multiple component teams working together to do so. The lines of communication within component teams are optimized for sharing best practices within the specialty; but the teams end up having fundamental dependencies on each other. The communications overhead - the high bandwidth communication required to deliver delight to customers - is between teams. Expensive. Ouch.

The most effective scaling models I’ve seen leverage cross-functional teams. Each cross-functional team has all the skillsets, from interface layer to business logic to data, all on the same team, to deliver customer functionality that delights users. While same-skilled folks are scattered across cross-functional teams, we still need managers who understand and can mentor and coach them, so we assign managers not to teams but to same-skilled folks.

I know several models that leaders and teams have found workable. All typically divide developers into cross-functional teams based on interface or functionality - most easily by how the interface splits functionality to present it to users.

Henrik Kniberg: Splitting teams based on how the interface exposes functionality.

Henrik Kniberg draws a picture of dividing up Spotify’s interface in just this way in his paper on scaling at Spotify.

Henrik Kniberg: Squads and Chapters

Notice in his organizational drawing that teams (which he calls squads) are vertical and don’t have managers; same-skilled folks (whom he organizes horizontally into “chapters” that span squads), on the other hand, are led by a same-skilled manager. So database developers are each assigned to teams, but all the database developers are also members of one of those chapters, and formally report to a database manager for mentoring, HR, best practices sharing, and assignment purposes.

3.  Cell Division
One approach to split a growing team is what my former Razorfish colleague Steve Gray calls cell division; as he describes the typical scenario, when a team has exceeded its effective size, a smaller area of functionality is identified that a smaller part of the team can be spawned off to address.

Former Medium VP Engineering Daniel Pupius notes, “I do feel the 9-12 person range is a really awkward size for an engineering team. I've had success with the "cell division" model, where instead of creating even splits at each point in time you peel off more stable islands, while a larger core group deals with a larger and less-defined surface area. In Medium's case it was a small team peeling off to focus on the needs of the professional publisher. That small team eventually grew to be 25 people and went through its own sequence of cell-division.

4.  Hybrid Split
When I was interim VP Engineering for a Portland company last fall, I inherited one of those larger teams and we invented a “team/subteams” hybrid model that both kept the larger team intact and split it into smaller ones. The team numbered half again more than the ideal max. Product management had identified three workstreams of customer functionality that needed addressing. The team divided into three sub-teams, each of which was (mostly) cross-functional and could deliver the three feature areas.

But it wasn’t clear that the three feature areas would be long-running streams of features that would support long-running, stable teams. Not only was stability at the larger team level, still, but team members were all working within a pretty monolithic code base. And large as it was, there was good sharing in a highly functional standup that the larger team held each morning.

So we kept the large-team standup for the sharing phase (the standup’s three questions, and identifying resolution discussions that needed to occur, particularly cross-subteam ones; this phase of the standup took the larger team of 15-18 typically 11-12 minutes). It was followed immediately by the (re)planning phase of the standup: a few minutes of (re)planning by sub-teams, each in front of its own physical card wall, in which each small team viewed its own backlog and discussed how it was doing on its sprint plan and who needed help, and moved cards across its board. The approach maintained the camaraderie and transparency of the larger team, while accomplishing (re)planning work in smaller teams.

The Take-Away
Given software development is a team sport, and team sports are gated by communication, we should all be constantly observing how our teams are communicating, and we should expect that we’ll need to evolve our team structures as we add (or subtract) people.

Have you seen effective models for splitting teams other than those I called out?

The models I’ve called out subdivide into cross-functional teams that take on lifetime ownership of functions users want to accomplish. By so doing, we give teams end-to-end ability to deliver those functions and avoid dependencies, handoffs and high-bandwidth communication overhead that is characteristic of dividing into component teams.

Regardless of approach, remember that it is communication that prevents siloing. Keeping the larger team intact while breaking out sub-teams - the hybrid model - is one mechanism that worked for one team. It will likely work for them for a while, until they grow their team too large for that model, too. At that point keeping communication flowing becomes a challenge both to product management (translating vision to features to stories) and to engineering management (translating customer wishes to design approach and architecture). Daniel Pupius notes, “The next super awkward phase hits around 30 persons.”

(Many thanks to Daniel Pupius, Rich Mironov, Steve Gray and Mickey Mantle for their insights and thoughts on this stuff!)

Friday, May 05, 2017

Novel Tech Truths
by Ron Lichty

stories, yarns and whimsy about making tech work “hum” 

Sometimes it takes fictional narrative (cleverly written to closely resemble the realities within which we all live) to drive home not so much the “how” of new ways of doing things – but the “why.” 

There's been a genre of engineering-lesson novels that share just such important principles and best practices in the guise of fun reads. Many of them are even beach reads. With holiday weekends and vacations coming up, with their promise of rare reading time, here are six fun reads worth taking along…

The Goal (Eliyahu M. Goldratt and Jeff Cox) is the granddaddy of them all - at least of this list. It turns out every manufacturing plant manager has read this book, and a lot of us in software, too. In my case, I had an SVP boss at Schwab who gave all his reports a copy. Despite it’s being a novel, you’ll learn the core principles of lean, starting with the Theory of Constraints.

Goldratt’s main character is the manager of a manufacturing plant with a seriously screwed up process—even as the guy’s marriage is falling apart, mainly for lack of attention, but in part for he and his wife not knowing their goal.

In the course of the story, the manager learns that trimming capacity to market demands actually reduces throughput and increases inventory - because of dependent events and statistical fluctuations. Then on the next day’s boy scout hike, one kid is the bottleneck. To puzzle out solutions to the hike - and the plant - the plant manager gets several scouts to move matches from bowl to bowl, testing fluctuations to see effects. He realizes - aha! - only by increasing throughput through the bottleneck can he increase throughput overall.

Interestingly, as manufacturing-centric as this novel seems to be, it’s hard to have a career in software without Goldratt, The Goal, and the Theory of Constraints coming up in conversation now and again.

The Deadline by Tom Demarco is the granddaddy novel of software. Demarco is the software process guru who wrote Why Does Software Cost So Much?, Waltzing with Bears, Slack, and Peopleware. This one embeds lots of principles of productivity and of teams:
    ▪    Don’t take chances on team jell if you don’t have to: Seek out and use pre-formed teams.
    ▪    Then keep good teams together to help your successors avoid problems of slow-jelling or non-jelling teams.
    ▪    Think of a jelled team - ready and willing to take on a next effort - as one of the project deliverables. 
    ▪    Why does the effect of pressure on programmers max out after only a 6% productivity gain? Demarco’s answer: People under pressure don’t think faster.
    ▪    The only real variable you have to play with to improve productivity is the proportion of work hours that are effective.... You must focus entirely on avoiding wasted time.

The Phoenix Project (Gene Kim, Kevin Behr, and George Spafford) took the decades-old The Goal (which the authors admire) and applied it to DevOps. If your job is keeping systems up and running, you need to understand the difference between planned and unplanned work (aka firefighting) - the latter the most destructive kind of work since it gets in the way of doing planned work - and is avoidable - and must continually be eradicated.

A kanban board helps everyone involved see (and limit) work in progress. And it may help you see your current constraint (aka bottleneck) - which you need to protect by creating "a trusted system to manage the flow of work to the constraint.”

Until you manage the flow of work to the constraint, the constraint is constantly being wasted, is likely drastically underutilized, is almost certainly not being applied to paying down technical debt, and is not contributing fully.

“Any improvement not made at the constraint is just an illusion…. Make sure the constraint is not allowed to waste any time. Ever. It should never be waiting on any other resource for anything, and it should always be working on the highest priority commitment." And be sure you reduce reliance on the constraint for unplanned work.

Then (Step 3 from The Goal) figure out how "to subordinate the constraint" - a la moving Herbie, The Goal’s slowest Boy Scout in the troop, to the front of the line to prevent the rest of the scouts from getting too far ahead. That is, set the tempo of work based on the constraint’s tempo.

You have to split your team’s time, spending cycles not just on features but also on "stability, security, scalability, manageability, operability, continuity." Then leverage your constraint, who very likely knows the most about where your technical debt is and how to build code designed to avoid unplanned work.

Always remember: “Outcomes are what matter - not the process, not controls, or, for that matter, what work you complete."

Predictability by Steve Bockman features, as its main character, a software development manager. In the opening paragraphs, he's walking down the hall when his boss, the VP Engineering, pops out of a meeting with the head of product to ask, "Bob, how long will this new project [that you've never heard of] take? I won't hold you to it." Yeah, right.

OK, there are way more issues than estimation to delivering predictably, but Steve Bockman invented the Team Two-Pass Relative Estimation method that is, for most of us who have used it, a big leap over Planning Poker (which itself is a big leap over what came before). Your biggest challenge, when you finish reading Predictability, will be realizing that its simplicity actually applies to your project. Trust me, it does.

Chapter 12 describes the relative sizing method that's become known as the Bockman Sizing method - the team two-pass relative sizing technique I teach every team I train. Steve also has a 99 cent ebook on Amazon that's just the method, if that’s all you need. But need or not, and whether you do agile or not, you’ll enjoy Predictability!

Outsource or Else (Steve Mezak and Andy Hilliard) takes on outsourcing. Its main character, a startup VP Engineering, is challenged to add massive functionality to his product with little additional funding and just six months until the VCs will shutter his company. Jason has been having no success hiring developers one at a time in Silicon Valley. But a recent spectacular failure has given the alternative, outsourcing, a bad rap. It gives Mezak and Hilliard opportunity to introduce their “7 Keys of Software Outsourcing,” many of which apply not just to outsourced teams but to distributed teams of all kinds.

There’s a secondary story in this novel. The VPE and his wife hire a landscaping company to do their backyard, only to realize that their misfortunes with the project are directly related to having followed none of the 7 steps above (and that the general contractor has failed them for having followed none of the 7 steps in hiring his help.)

Rolling Rocks Downhill (Clarke Ching) will clear up any questions you have about why continuing down the path of practices that repeatedly yield bad quality and missed deadlines is madness - and why the only sensible thing to do is (if somehow you don’t know about them already) to invent agile and lean practices.

Frankly, the first half of the novel is too long. But the rest – once our hero finally realizes he has no choice but to change paths – is superb: highly engaging, and close to the truth of software development and corporate life in almost every way. It will also reassure you that changing paths, even dramatically, can be done in a step-by-step way.

(Worth noting: Goldratt is also a hero of this author's.)
I invite nomination of other engineering-lesson fiction!

Enjoy your summer!

Monday, January 02, 2017

Lean and Agile: Partners in Customer Delight
by Ron Lichty

Agile? Lean Startup? Lean? Are they related?

Lean Startup and Agile share common roots in Lean Manufacturing, the work begun in Japan by Deming and by Toyota beginning in the 1950s to increase quality and throughput through teamwork and eliminating waste.

For the better part of two decades, Lean was considered, in programming, as one of several approaches to Agile software development along with Scrum and Extreme Programming and Kanban, until the advent of Eric Ries’ book Lean Startup usurped the word.

Eric did agile both service and disservice with Lean Startup. The disservice to agile (aside from appropriating the word “lean”) was to cast agile as something that hadn’t worked for him when, by his own description, he had at best used a few agile practices but clearly never been agile (he failed to use frequent delivery and get frequent customer feedback and instead did entirely too much upfront design and undertook entirely too much upfront development).

Fortunately for us all, Ries’ disservice to agile was far eclipsed by his contribution: by providing a business-side view to agile - as lean-startup, a product process, a design process, and a business-side process - Ries made agile understandable, palatable and amazingly desirable to the business world.

While Lean Startup and Agile differ in areas of companies they impact, they belong together.

Lean Startup is a market experimentation system focused on maximizing long-term monetary value through short-term iterative experimentation and market feedback.

Agile is a product development value-maximization system focused on waste-reduction, highest-value-delivery and team-performance-optimization.

Both value iterative, incremental delivery and customer feedback. 

Agile, even practiced poorly, can improve product development substantially. When practiced well, agile results in teams emerging highly performant, delivering not just stellar process but team synergy - team results that are greater - in the best case, far greater - than the sum of the individual people and their individual skills.

Similarly, lean startup, even practiced poorly, can reduce cost (and thus risk) and improve value creation (and thus value delivery) for new products substantially. When practiced well, lean startup reduces up-front investment,  minimizes time-to-market, and dramatically increases the opportunity for success.

Agile backlogs are by definition ordered by ROI, by bang for the buck. Every developer knows that just by delivering the top backlog items, he or she is delivering the things that customers value most. By delivering them frequently, we have opportunity to get feedback early and often that lets us adjust our course to optimize for customer delight. By, as a team, defining “done” before we code a single line of code, we hold each other accountable to a level of quality for every feature that we’ll expect for the product as a whole. By writing stories that steer clear of the “how” but include not only “what” but “who” and “why”, we engage every developer and every tester in identifying the best possible solutions to our customers’ wants and needs. Mastering the practices themselves represents a level of discipline seldom seen in software development prior to agile. And by not only mastering the practices but embracing the values and principles - an agile mindset - we have the possibility of emerging high-performant.

Similarly, by embracing lean startup - by posing our proposed product as a series of experiments - we can get frequent, recurring feedback that ensures we’re delivering just what it is that customers most want. By repeatedly, iteratively testing a minimum viable product, a team can rapidly leverage market feedback to tailor or if necessary pivot the product concept to meet marketplace needs. Developing repeated learning experiments costs dramatically less than developing upfront, spec-driven, perfectly polished, finished products. And learning experiments dramatically reduce the time from ideation to market feedback - time otherwise lengthy for spec-driven product development; it’s market feedback that limits the risk of being wrong about our product concept - sometimes very, very wrong. By leveraging the lean-startup build-measure-learn cycle, we substantially reduce that risk for the products we conceive and dramatically increase our chances of success.

Whether agile or lean startup, whether we’re technologists or business people, we’re called to think, plan, try, deliver, get feedback, talk with each other, create experiments and hypotheses (and learn from them)… and fundamentally delight customers. Agile helps us build stuff right. Lean Startup ensures we build the right stuff.

In our book, Managing the Unmanageable, my coauthor and I collected hundreds of rules of thumb and nuggets of wisdom for managing software development. Among my favorites is this one, from San Francisco startup CEO Joe Kleinschmidt:

In the beginning, everyone will talk about scope, and budget, and schedule, but in the end, nobody really cares about any of those things.
The only thing they care about is this:
People will love your software, or they won’t. So that’s the only criterion to which you should truly manage.

What resonates for me is not so much that scope and schedule and budget are not important - we know that we have constraints, often in all three areas - but that we too often get lost in the maze of scope and schedule and budget and lose sight of the fact that, unless we delight our customers, we’ll not be in business long!

Whether we’re startups or mature companies, whether building devices or web products or enterprise software, by leveraging highly disciplined agile and lean startup approaches together, we pair development and design processes to ensure that what we ultimately deliver customers delivers delight!

This post was originally published by the Silicon Valley Software Group at