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

Thursday, October 13, 2016

High Performance Teams: Definitions of Done, Effective Backlogs, Agile, Tools Orientation matter
by Ron Lichty

Highlights of this year’s Study of Product Team Performance center around Definitions of Done, Requirements Backlogs, Agile, and Tools and Automation.

While it should seem as no surprise, team Definitions of Done matter - not only teams having one, but who creates it. Product teams that do not have (or do not know they have) a definition of done don’t perform well, we learned this year from the 2016 Study of Product Team Performance, our fifth annual global study of product teams.

But while not having a Definition of Done negatively correlates with performance, just having one doesn’t correlate with high performance. And that part may be the surprise. Externally written / externally imposed definitions of done don’t move the needle. Only organizations in which team members themselves create their definition of done - teams that have the team’s own product owner draft it or teams that develop a clear definition of done collectively - correlate with the highest performing teams.

While it should also seem no surprise, this year’s Study showed that effective backlog prioritization matters, too. Product teams that effectively prepare and prioritize their backlog of work correlate with teams performing at the highest levels. Conversely, teams that report their backlog is a jumble are negatively correlated to high performance - that is, they are unlikely to perform well.

What was disturbing was to see 37.9% of respondents report that their backlog is a jumble!

Other factors we found this year that correlate to high performance:
  • Teams that see a connection between Agile/Scrum and higher product profitability perform better
  • Teams that call out tools and automation as a route to increased effectiveness perform better
The 2016 Study of Product Team Performance, which we released two weeks ago, identified these new factors, adding them to 20 factors that emerged in previous years’ studies. These factors all correlate with teams performing at the highest levels.

As part of each year’s survey, we have also asked about development methods. This year, for the first time, teams using agile (48% scrum, 4% kanban) exceeded those using all other methods combined. And when combining teams using agile with teams using blends of agile and waterfall (31.9%), 84% of teams use enough agile practices for respondents to call themselves out as at least partially agile! (Teams using blends of agile and waterfall this year fell from over half, five years ago, and hovering not far below half in subsequent years, to below a third this year; the downward trend of teams claiming waterfall continued, to less than 9% this year, from 18% reported five years ago.) Remarkably, while agile use rose dramatically, teams identifying Agile as the route to product profitability continue to exceed those actually using agile. Agile’s value was and is widely recognized.

What else did we learn? When we asked respondents what would improve the effectiveness of their product team, the standout answer, at 45% of respondents, was “improved cross-department communication”; product development is fundamentally a team sport. Almost 60% of respondents report that their companies leverage distributed teams outside their country. For good or bad - and we didn’t see a correlation either way - more than two-fifths of first level engineering managers code. A quarter of first level engineering managers act as scrum master for their teams. Eleven percent of teams still have no product management. Nearly half of all respondents (48.2%) indicated that their organizations have no formal system or process for tracking, developing, and managing ideas from their employees, customers, and suppliers.

The Study of Product Team Performance is a self-reporting one. Team members are asked to identify if they experience their team as high performing and to share their experiences and approaches. This year 43% of respondents - the highest percentage in the five-year history of the study - said their teams were consistently delivering solid performance.

Returning to the four new factors that this year’s statistical analysis correlated with high performance teams, there is significant discrepancy between those factors and the numbers of teams actually achieving those factors:
  • only 45% of respondents report definitions of done created within their teams (they told us 15% are created by teams’ product owners, 30% by the team collectively; the good news: only 7.4% said they have no definition of done at all)
  • only 43.5% of respondents said their team’s backlog is effectively prioritized
  • only 32.4% of respondents recognized the connection between tools and automation, and effectiveness

Download the free 2016 Study of Product Team Performance - the earlier studies are no longer available, but you can, there, also take a look at my own short summaries that capture their high points.
It’s been intriguing and sometimes truly incisive stuff that we’ve learned. Thanks to all of you who share what you’re doing each year; downloading the study gets you an invite to participate in next year’s study. Many thanks to lead author Greg Geracie and my co-contributing-author Matt Jackson. And special thanks to this year’s study sponsors, ProjectConnections, Accelerance and Planbox!

Sunday, February 07, 2016

What makes teams high performance?
by Ron Lichty

This year's survey into what makes teams high performance needs you.

Take part. There’s an Apple gift card to be won. And more important to many of you, we’ll share the results with you when the survey is complete and they’ve been tabulated and cross-correlated!

This is the Global Study of Product Team Performance.

Results have been worth having. Take a look at my brief overviews of the past four surveys - it’s all free.
The insights have been intriguing and sometimes truly incisive.

For example, what if you were able to identify just five things that:
    ▪    if you do all of them, you have a 67% likelihood of high level team performance
    ▪    if you don't do them, you have just a 2% chance of high level team performance
The 2012 Study of Product Team Performance identified just that.

It’s only gotten more insightful with subsequent studies. What is it about positive work environments, nimbleness, user experience? The importance of executive engagement and product manager role definition. The impact of effective onboarding and effective standups. As a coauthor of the Study, I’m no doubt biased. But it’s why I became a coauthor of the Study.

The findings are free to all, each year. Take the survey and we’ll tell you where to get the Study as soon as results are available. As in prior years, there are a bunch of sponsors - partner companies and industry associations - helping us get broad participation and defraying the costs.

We would love hear your thoughts on these subjects. You can add your voice to hundreds of others by clicking on this link.

One of the reasons the study is so useful is that it can help get senior execs on board. One of the hard truths is that sometimes it takes studies (and consultants and other kinds of backup!) to sway disbelief. The need for outside support - for reinforcements - is what motivated my co-author and me to share 300 Rules of Thumb for managing software people and teams in the quickly thumb-able center section of our book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams (Addison Wesley). And it’s why studies like this one, the Study of Product Team Performance, are so important.

As always, we need your participation. (And you might win a $200 Apple gift card, courtesy of the study’s sponsors, Planbox, Accelerance and Project Connections! Just enter your contact information at the end of the survey to enroll in the random drawing.)

We particularly need developers, testers and UX practitioners. The product managers and project managers have, to date, overwhelmed our numbers.

The survey takes seven minutes to fill out and it’s crisp, even on your phone.

You’ll get first notice of this year’s findings by taking the survey right now.

We want to hear from you!

Monday, November 23, 2015

Programmers are not Software Engineers?
by Ron Lichty

This post was co-authored in November 2015 with Mickey W. Mantle, the co-author of our book Managing the Unmanageable.

This month’s Atlantic Monthly (November, 2015) contains an article for the (mostly) non-technical readers of that magazine that fires a shot across the bow of the vast number of would-be “software engineers” employed throughout the United States and the world today. Written by Ian Bogost and titled “Programmers: Stop Calling Yourselves Engineers”, this article echoes the sentiments that we ourselves discussed and debated when writing our book about managing software people and teams – Managing the Unmanageable.  Our decades of experience managing programmers led us to the conclusion that with few exceptions programmers are not engineers, for many of the reasons touched on in this article. We begin the first chapter of our book explaining why we choose the term programmer over software engineer throughout the book when referring to those who write code and develop programs:

"Programming as a serious profession is different from related engineering professions, such as electrical or civil engineering.  Since 1968[1] attempts have been made to apply the term “software engineering” to the art of programming.  But writing a new program from scratch is much more akin to writing a novel than to the established practices of civil or electrical engineering. New programs frequently begin with a “blank sheet” of paper, whereas engineering projects are typically assembled from libraries, components and rigorous codes of acceptability. Software engineering (or programming as we shall refer to it in this book) continues to be more of a craft than a rigidly defined engineering discipline.

"Second, anyone can be a programmer. You do not need a formal education to be a programmer and there are no required certification standards or tests. All you need is to get a job as a programmer.

"Third, and in part as a result of the first two reasons, though many steps have been taken to formalize the process of software engineering (e.g., CMMI[2]  Levels 1-5), these steps have had minimal impact.  Most of the software that continues to be developed by the legions of programmers does not follow such formalized processes.  And even when it has, the result has improved the process but has not resulted in making programming an engineering discipline."

Though we adopted this stance, we never felt it necessary to campaign to limit the use of the title Software Engineer.  Indeed, both of us have used it in our jobs when trying to hire programmers – the exalted title of Software Engineer was often necessary when making a key hire of a programmer.

But times are changing.  In the new environment of “lean startups” and “lean education”, 14 – 24 week Coding Bootcamps are considered all that is necessary to produce a programmer who may be competent in some small part of software development. But that programmer is far from being a “software engineer”. It appears that “fast and cheap” from that old adage “good, fast, or cheap – pick any two” is becoming the defacto answer to producing programmers.  With such a limited education and experience, “lean” graduates may be able to do some programming, but we fear many if not most may not even be programmers.

[1] It was in 1968 that the term was coined to describe “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.”  See Software’s Chronic Crisis, Scientific American, September 1994.

[2] Capability Maturity Model Integration (CMMI) is a process improvement approach developed by the Software Engineering Institute that provides organizations with the essential elements of effective processes that ultimately improve their performance.  See

Monday, July 27, 2015

The Skinny on Standups: Make them Effective, Hold Them Daily
by Ron Lichty

Daily standups are vital.

That’s what our 2015 Study of Product Team Performance reveals. Teams that hold effective standups are more likely to be high performance teams; and the more frequent the standups, the higher the performance: teams holding standups daily report the highest performance of all.

While standups aren’t ubiquitous, by any means, they’re the first practice of scrum that most teams implement, the last practice standing when teams revert to waterfall, and to have a life of their own even outside scrum: lean doesn’t mandate them but they’re common among kanban teams; and even teams using waterfall and spiral are embracing standups.

The Study tells us that organizations have been right to do so.

The group most highly correlated with high performance teams are those holding effective standups daily, and that’s 22 percent of teams these days, according to our survey.

Given that 26 percent of respondents are using scrum, that means at least four percent of scrum teams are off their scrum game - and missing out on a frequency that correlates to the highest performance.

Another 18.2% reported holding effective standups “regularly” though not daily, and their teams correlate to generally delivering higher performance than all but those holding standups daily. Added together, 40% regularly conduct standups that make for an effective cornerstone of the product development process.

These best-in-class organizations are followed by another 41% that report standups are effective, but irregular - not conducted on a regular basis.

While 19% of survey respondents indicate that standups are ineffective and for some of them even contentious and a waste of time, a remarkable 81% called their standup meetings effective.

Reflecting back on findings from past studies, we know that 20% of product teams report issues with cross-functional handoffs and transitions that are too often responsible for degradation in team performance - interestingly, almost the same number as are holding ineffective standups.

The regression analysis we undertook in this year’s study clearly demonstrates that standup meetings are vital to effective product team communication and help eliminate or reduce issues that impede high performance. It also shows that product teams that invest the time and energy necessary to make standups both effective and part of their daily routine will see significant performance benefits.

photo credit: By Michaelblinkpipe (Own work) [CC BY-SA 3.0 (], via Wikimedia Commons

Thursday, July 16, 2015

High Performance Teams: Standups, User Experience, Problem Recovery, Agile matter
by Ron Lichty

Standups matter - both effectiveness and frequency. Product teams that hold effective, daily standup meetings are more likely to be high performance teams, we learned this year in the 2015 Study of Product Team Performance, our fourth annual global study of product teams.

Other factors we found this year that correlate to high performance:
  • Successful Integration of User Experience professionals into the product development process
  • Quick Problem Recovery: all product teams experience unexpected problems, but team performance directly correlates with how quickly product teams can move past these issues
  • Strategic Decision-Making Aptitude: organizations that make strategic decisions - not just tactical ones - and have the discipline to stick with them tend to have more productive product teams

The 2015 Study of Product Team Performance, which we released today, identified these four new factors, adding them to 16 factors that emerged in previous years’ studies that correlate with teams performing at the highest levels.

In addition, we continued our survey of development methods. As in previous studies, we found more teams using blends of waterfall and agile than anything else - almost half say they blend waterfall and agile practices. But teams identify Agile as the route to product profitability - in numbers far greater than are actually using Agile. As has been true since we began asking the profitability question in 2013, almost half of the small percentage still using waterfall believe their product would achieve higher profitability using some other approach. Those trends continue in this year’s data.

This year we asked team members about their own gratification, as well as about turnover. While more than 63% of product team members indicate that they are either satisfied or extremely satisfied in their work, with only 12.3% saying they’re dissatisfied, nonetheless 54% of respondents have seen team turnover have a moderate to significant impact on their team’s ability to meet commitments and deliver products on time.

The study also revealed that product managers spend much less time in the field than their teammates believe they do.

Consistent with the correlation between user experience and high performance teams, product managers are held accountable for customer satisfaction more than any other metric.

The study is a self-reporting one. Team members are asked to identify if they experience their team as high performing and to share their experiences and approaches.

Returning to the four new factors that this year’s statistical analysis correlated with high performance teams, there is significant discrepancy between those factors and the numbers of teams actually achieving those factors:
    ▪    only 22% of respondents report holding effective standups daily
    ▪    a fifth of respondents don’t believe User Experience even reports into the right department in their organizations
    ▪    only 35.4% of respondents said their teams quickly rally and move past unforeseen issues
    ▪    only 36.9% of respondents said their teams are good at making and sticking with strategic decisions

Take a look at my own short summaries of prior year studies, as well as download the free 2015 Study here:
It’s been intriguing and sometimes truly incisive stuff that we’ve learned from all of you. Thank you.

And many thanks to lead author Greg Geracie and my co-contributing-authors David Heidt, Matt Jackson and Sean Van Tyne - as well as special thanks to this year’s study sponsors, ProjectConnections and SensorSix!