Digital Growth Insights is pleased to publish this contributed piece from Steven Johnson. Steven is a recognized thought leader and storyteller within the technology product management community. As founder of Under 10 Consulting, he helps product teams implement strategic product management in an agile world.
In the old days, machine time was expensive and people were cheap. So developers spent days, weeks, even months designing solutions on paper before they put them into the machine. Programming in those days involved flowcharts, pseudo-code, and many, many reviews.
And then personal computers came along.
And overnight, machine time became cheap and people time became expensive. It was much easier to try something and see if it worked. It didn’t? Then try something else. Do it again. And again.
What evolved in the 1980s and 1990s was a move from up-front planning to “code and fix” programming. “Best effort” programming was born. Write a little code, hit F5 to see if it compiles, write some more code, and repeat. After a few passes, run the program to see if it’s really working, check the output, and then fix some more. Need a comma in the money field? Yeah, we can do that! Code. Fix. Code. Fix. Code some more.
Who needs planning? Who needs design?
Fast forward to today. The new generations of programmers have learned to “code and fix” like crazy. What they have not learned is how to plan and design.
And when it comes to programming, young people are cheaper. Sure, they don’t have much experience but you sure can throw a lot of ‘em at a problem. Free pizza for anyone willing to pull an all nighter.
In April 2001 a small group of engineers attended a conference in Colorado. After the conference sessions, they started chatting about their frustrations at work. In particular, they lamented the incessant meetings and the heavy documents. They felt their mandated product planning process interfered with actually getting products out the door.
They envisioned a new approach—described in the Agile Manifesto—and sparked a revolution. They wanted to spend more time building great software and less time sitting in unproductive meetings, less time writing documents that no one would read. Their idea was that we could all deliver more code faster using what are now called agile methods.
“Agile” refers to a family of methods that were developed throughout the 90s including Scrum, Extreme Programming (known as XP), Lean, and Kanban. Each method has its own nomenclature and key characteristics. You can learn more about these methods by looking at their Wikipedia pages.
But here’s the challenge: Those who are advocates of agile methods assume a high level of professional capability in the team members. Like me, they see programming as a craft. But too many leadership teams today —particularly those leaders with sales or finance backgrounds—see programming as factory work. Something that can be easily outsourced to the lowest bidder.
But software development isn’t factory work. You need someone to understand the needs of the market and develop a business rationale; you need someone to design a solution that customers will love; you need someone who ensures that the product is released on time and on budget. You need someone with actual work experience who sees software development as a craft, a profession.
Companies need help to truly become Agile, to develop new products that keep them competitive and can lead to consistent growth. They need a partner with business experience who can provide the vision as well as the timeline. Not a partner with the mentality of an assembly line worker.