The 2013 Study of Product Team Performance by Ron Lichty

The 2013 Study of Product Team Performance is out! The results are not quite as across-the-board extraordinary as last year's study - that would have been hard to match - but it offers individual results that are every bit as eye-opening - and overall it's quite revealing.

What startled me in last year's study was that it named just five things that:
    ▪    if you don't do them, you have only a 2% chance of high level team performance
    ▪    if you do all of them, you have a 67% likelihood of high level team performance

I thought that was pretty remarkable. I blogged about the 2012 Study's five factors for success.

I also blogged about how the change 2012 survey respondents most wanted to make in their teams rang true in my experience - and how one team had achieved that challenging leap forward.

But I was struck by the fact that the 2012 Study's then-three authors had product and project and requirements backgrounds - but no developer viewpoint. When I pointed that out, they recruited me to be a fourth coauthor of this year's study.

We targeted this year's study to dig deeper into the factors that affect team performance and product profitability. We partnered with 13 professional associations and companies to recruit and survey almost 1500 members of product teams over 90 days at the beginning of this year. We provided the resulting data to statisticians.

The regression analysis the statisticians delivered deepened or expanded our understanding of four of the five factors of high-performing teams that emerged from last year's study (the fifth had been so strong it needed no clarification):
    ▪    An Aligned Strategy: the significance of the product team aligning with the company’s overall goals and objectives
    ▪    The Importance of Product Launch: successfully staffing and resourcing product launch activities
    ▪    Onboarding Processes: the surprising impact that emphasizing effective product team member onboarding has on the overall performance of the product team
    ▪    Executive Team Support: not only is unwavering executive team support linked with product team success, but so is close connection with the CEO or general manager.

A new factor emerged from the analysis:
    ▪    Product Manager Role Definition: the favorable impact that a well-defined product management role plays in product team success

The study also revealed four landmines: four statistically relevant factors that can undermine a team's ability to achieve high performance.

Remarkably, it also showed that members of teams using agile and lean and blends of waterfall with agile and lean, across the board, associate their methods with increased profits - but members of teams using waterfall believe that approach is costing them profits!

I'll blog about some of these factors (and at least one other intriguing result) in coming weeks, but you may want to read the 2013 Study of Product Team Performance white paper now (and the 2012 Study, as well, if you haven't already!).

Colleges: Teach the "How"! by Ron Lichty

We're at an inflection point.

Agile practices transitioned over the last couple years from "emerging" to "predominant". Companies are sampling if not wholesale adopting agile, from scrum and extreme programming to lean and kanban. Our study of product team productivity due out later this month documents an increase to 76% of teams incorporating at least some agile methods, up from 71% last year. Even more significant, 84 percent of teams still using waterfall think they could increase the profitability of their product by adopting agile practices.

But agile practices are not easy. Agile has a reputation as "loose" but, in my experience, the various forms of agile represent the most rigorous methodologies, frameworks and practices I've come across in my 30 years in software development.

Companies adopting agile soon discover what those of us using agile for a decade already know: there are all too few developers (and managers and scrum masters and product owners) with any significant amount of training and experience in agile methods and practices. Too few developers have practiced pair programming. Too few developers have tried test driven development (TDD). Too few shops leverage practices that support continuous deployment. Too few teams practice team "ownership." Too few developers and testers and scrum masters and product owners have spent time as part of successful scrum teams. And too few managers have insight into the critical contribution they could make to the success of their companies' transitions.

There's good training out there - I've taken some of it and my clients tell me I've given some of it. But companies sign up for too little training. Dean Leffingwell reports that factories don't even begin a transition to lean without having first sent their managers and directors off to lean bootcamp for a minimum of two weeks and often six. And companies sign up for too little coaching. Agile's wins don't come from learning drills and nomenclature in meaningfully applying them - which requires understanding the meaning behind the drills - application of agile's principles to the unique culture and challenges each team and each company faces.

I think the place to set meaning and understanding in place is much, much earlier: when students first learn to code.

But the education community has done little to incorporate agile into curricula. I was shocked when I interviewed Stanford computer science students for internships two years ago to find, to a one, that they had heard not a mention of TDD or continuous deployment or scrum and had only a vague idea of pair programming.

Earlier this year, I pitched community college educators, at the ICT Educator Conference in San Francisco, on the value of teaching not just programming languages, algorithms, and logic (the "what") but also agile methods and practices (the "how" now coveted by hiring managers). I titled my talk "Win / Win / Win with Agile" because this inflection point and the dearth of developers with agile experience provide unprecedented upside for educators, students and hiring managers alike. A video interview I did with the conference organizer just posted this week on the wins for colleges and educators and their students.

Teaching test driven development is at the top of my list. We called out TDD in our book, Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams. Valuable for the students? I can't express enough how highly I value resumes from programmers who can say they practiced TDD with every line of code they wrote.

TDD turns coding inside out: programmers are responsible for unit testing their code; before they write a single line of code, they write the tests that will prove the line works; they then run that test demonstrating that the test fails without the code; they then write the code and run the test again until the test succeeds. That cycle should take an experienced TDD coder between 30 seconds and two minutes. Rob Myers, who trains teams in TDD, describes a two-year effort writing a life-critical application yielding 9,000 unit tests that together made up a comprehensive automated regression test suite; the entire suite could be run in 10 minutes; and the team could make a change to a life-critical application and deploy the change, with confidence, within an hour.

I've found converting an entire team that has never used TDD is challenging. In my experience, no more than 1 in 5 programmers "gets it" - sees writing tests before writing code as an obvious way to improve quality, to ensure requirements are understood, and to enable later refactoring with impunity - with confidence in the outcome. The remaining 4 of 5 programmers find it not "natural" to write tests before writing code.

Unless they were taught from the beginning that writing tests first is the natural order of things.

As a hiring manager, I expect students who test first - who have incorporated TDD into their way of working so thoroughly that they do it naturally - will deliver a level of quality that matches or exceeds the best of what I can get from experienced programmers who have no experience with TDD. Students who can put TDD on their resumes - and speak to the practice with a level of confidence deeper than most experienced programmers - will win jobs.

But TDD is only the beginning. Bringing programmers (and tech leads and architects) into pair programming can be even more of a challenge. While pairing has been shown to result in higher quality code in comparable time than two programmers working separately, for many programmers it's as counter-intuitive as TDD - maybe more so.

Programmers need practice working in pairs and in teams to feel comfortable doing it. The good news - for both online learners and distributed teams - is that pair programming can be practiced by remote students and teammates, not those who meet to pair. It's slightly easier, in fact. In physical space, the two programmers share a single monitor and pass a single keyboard and a single mouse back and forth. In virtual space, they're connected via audio link so their conversation is the same, and they link their monitors so they're always looking at the same thing but each has their own keyboard and monitor - it's control of the cursor that, using conventions, gets passed back and forth.

Students who leave college having had to pair on assignments and having had to write tests first (TDD) would be dramatically more hirable. Industry would not only snatch them up but be enormously grateful to the colleges that taught students not only the what but the how. Such curricula would change the tenor of programming for the better - with regard to both quality and productivity - across their region. Institutions where curricula required students to learn Agile practices would see appreciation from students and hiring managers alike.

Colleges can deliver what we hiring managers are looking for, just by expecting students to:
    •    work in pairs (pair programming)
    •    write tests first (test driven development)
    •    partner in requirements elicitation (scrum)
    •    retrospect regularly (continuous learning)
    •    demonstrate facility with pomodoros (agile time management)
All the stuff that's so hard to teach and makes it so hard to transform organizations.

It's time for educators to step up, teach not just the "what" but the "how", and help transform this hard thing we do called software.