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 counterintuitive as TDD – maybe moreso.
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.
