October 13, 2011
Never has a new trend annoyed me as much as Agile. Right from the get-go, the Agile Manifesto revealed the weaknesses and immaturity of the founding principles. The two most disturbing: “Working software is the primary measure of progress” and “Business people and developers must work together daily throughout the project.” These are cop-outs because:
- Using “working software as the measure of progress” is narcissistic. Rush to write code is oft the translation of this misguided principle. Software developers want to be measured on what they know — code — instead of what they don’t know: the domain, business requirements, and the user. The idea is that you’ve got nothing if you don’t have working software. The cop-out is thinking that code is the measure of everything. Software is always part of a bigger picture. It works in conjunction directly or indirectly with other software, technologies, the environment, business processes, and people to create customer experience and/or improve operational efficiency. Like most of the Agile principles, this one is developer-centric rather than user-centric.
- “Business people and developers working together daily” is lazy. This principle is a capitulation by developers who say it is impossible to understand the true requirements. Developers would much rather stick with what they know: typing class definitions, if-then-else statements, and looping constructs into glorified text editors. The absurd Agile solution to getting the requirements right is to meet with the business every day (or frequently). Often the business people who are involved are not the same as the users, and they are not domain experts or design experts. Seriously, can your best people be available to help developers do their job? The cop-out is thinking that great software can be developed through a process of dead-reckoning with business people. This is just another way for software developers to blame the business for challenged or failed software projects and a sure-fire way to propagate uncertainty and mediocrity. It is a false argument to say that developers cannot understand the requirements and anticipate changes. Development teams must understand the business and the users better than they understand themselves.
Yikes. I have used some strong words here, and I could go on and on. I acknowledge the good intentions of the Agile community. But, the lack of empirical evidence for the benefits of Agile methods is telling. My colleague Dave West, who covers Agile for Forrester, has seen the cracks in how Agile is implemented and written about them in a new research paper titled “Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today.” The report also shows Agile adoption at 38.6% in 2010 and notes that interest in Agile remains very, very high. Most of the evidence I have seen is anecdotal — of the “It’s a miracle. I can walk again!” kind. My take is that the Hawthorne effect is hard at work after years of brain-numbing sequential processes such as waterfall. Anything was better than the worst.
A New Thesis For A Better Approach To Software Development
For the future of application development to be insanely great user experiences, we need a new software development methodology. Agile is not it. Agile is a group of methodologies that came from asking, “How can we fix the software development mistakes of the past?” We need a new approach that asks, “What software development process prepares us to be experience creators?” I call this new approach: parallel, immersive software studio (I am well aware of the purely coincidental acronym P#SS. I just call it STUDIO). This new approach rests on four pillars:
- Parallel. Mature software development teams can chew gum, walk, juggle, and can learn new stuff as fast as Neo (aka Thomas A. Anderson) learns martial arts. Development teams must have the confidence and insight to do parallel streams of development. Jason Darrow explains parallel development: “As we get a handle on requirements we break off a piece and start work on it in parallel.” For example, if one of the requirements of a new software project is to provide CRUD operations on 27 fields in a legacy IMS database, then get to it. The fastest way to get faster is to run parallel streams of design, development, and testing. When you break the tasks apart, some are sequential and others may be iterative. Walker Royce from IBM is doing groundbreaking work he calls software econometrics to measure the effectiveness of software development. One of his key conclusions is that successful software projects reduce uncertainty. Parallel work streams can reduce uncertainty and the number of costly iterations.
- Immersive. Software is a means to an end. That end is to deliver applications that exhibit the seven qualities of great software: user experience, availability, performance, scalability, adaptability, security, and economy. All seven qualities are important and interrelated. But if you get the user experience wrong, then nothing else matters. Developers often blindly rely on businesspeople, business analysts, user experience designers, and customers to tell them what will make a great user experience. Writing code is the least of the talents of great software developers. Immersing is a domain that takes time and hard work. Software development leaders must deeply immerse themselves in their users’ domain.
- Software. That’s what we develop. That’s what we deliver. However, the future software development is experience. Blame Apple if you want. Thanks to the mobile revolution, user expectations for software, whether that software is mobile, web, or traditional, have never been higher. People use apps that are amazingly intuitive to use and that make them feel pampered. They quickly start to wonder why all their software experiences can’t be like that. The bar has risen — big time. My view is that software developers are much more than coders. Software developers are experience creators.
- Studio. Software development is not pure coding, engineering, architecture, management, or design. It is cross-disciplinary. Better yet, it is its own discipline. It is more akin to making a movie than to building automobiles on an assembly line. The studio revolves around talent. Great software talent means renaissance developers who have passion, creativity, discipline, domain knowledge, and user empathy. These traits are backed by architecture, design, and by technical know-how that spans just knowing the technology flavor of the day. Process is the studio; it has structure but is flexible enough to optimize talent and tools. Tools matter in the studio — not just management tools, but software development and design tools that go beyond programming languages such as Java. We need model-based and more-visual tools to make development faster and easy for more people to participate in the creative process of software development.
The parallel, immersive software studio is different from other methodologies in five important ways:
- Software is not code. It creates experience.
- Development teams are not coders. They are experience creators.
- Technical talent is table stakes. Great developers must be design and domain experts.
- Process is bankrupt without design. You get what you design, so you better get the design right.
- Software is a creative endeavor, not an industrial process like building automobiles. The methodology is structured to support the creative talent.
This post about parallel, immersive software studio (STUDIO) can’t compete with the 1,813 books about Agile Software on Amazon.com right now. It is just a new idea in a sea of many. But, the accelerating demand for applications that “wow” businesses and users will create new winners and losers in the world of software development. Agile-mania is ending. The evidence: the Agile gurus are now telling us what is wrong with Agile and how to fix it. I say: Throw the baby out with the bath water. Now it is time to get serious. Our craft of software development must be based on creating a continuous stream of insanely great user experiences, not based on the problems of our past. Our value as application development professionals depends on it.
I initially wrote about this new approach in December 2008. It is the result of countless conversations with real software development professionals; observations in many different software development shops, including software vendors, enterprises apps, consumer apps, and core technologies; and a large amount of research in adjacent disciplines such as product design, advertising, and movie making. This research is also based on interviews with business people, product managers, and executives as well as my experience as a software developer for 25+ years using a wide range of technologies and methodologies for small and very large applications including Z80 for operating systems and Java for enterprise apps.
- The Design of Design: Essays from a Computer Scientist by Frederick P. Brooks, Jr., 2010
- The Design of Business: Why Design Thinking is the Next Competitive Advantage by Roger L. Martin, 2009
- Bringing Design to Software by Terry Winograd, 1996
- Built to Love: Creating Products That Captivate Customers by Peter Boatwright & Jonathan Cagan, 2010