Has Agile Software Development Gone Mainstream? - Matthew Heusser, CIO From: www.cio.com August 12, 2013
http://www.cio.com/article/print/737980
April's Software Test Professionals Conference ended with a panel discussion about the future of the industry. Rex Black said agile methods were "picking up steam." His colleague on the panel, Cem Kaner, a professor of software engineering at Florida Institute of Technology, replied that agile software development is, on the other hand, already mainstream, and those not already doing agile are in danger of being left behind.
Who's right—and what does that mean?
Object Oriented Development Went Mainstream, and That's OK
In 1998, Alistair Cockburn authored Surviving Object-Oriented Projects; a year later, Robert Binder penned Testing Object Oriented Systems. Both books suggested that object-oriented programming was new and offered something wonderful—while being a challenge with massive pitfalls. The object oriented conference, OOPSLA, was changing the world.
Today, save for embedded and legacy systems, every single company I interview is using object-oriented programming languages (commonly Java, Ruby or C#). That said, the only place you'll find a book with "object oriented" on the cover is in a freshman computer science class. OOPSLA went through years of decline, too, before reorganizing itself in 2012 to essentially become a track in a wider event called Splashcon.
It's not that object-oriented programming failed. Instead, the opposite happened: OOP, like everything else, went mainstream.
The same thing may be happening to agile. It might surprise you to learn that the largest Agile Conference was back in 2008, with total attendance of 1,500 people.
Size, Barriers to Change Affect How Companies Develop Agile
Analyzing an industry is complex. The people who fill out surveys, for example, are most likely to be early adopters, open to change and "plugged in" to the community. That's why they get survey announcement emails in the first place. If the person works in an industry with its own websites, magazines and news sources—think aerospace, medicine or government—he or she may not realize that survey exists at all.
How-to: 3 Ways to Be More Agile With Software Shipping Decisions
Case Study: F1 Racing Team Speeds to Agile Development
Even after accounting for that, it's hard to discount reports such as VersionOne's 2012 Agile Development Survey, which has a 84 percent "Yes" response to the question "Does your organization practice agile development?" Among those, 54 percent claim to be using scrum.
To get beyond surveys, I looked for a company with a finger on the pulse of software development, one that both builds software and works to integrate it with other companies.
With 2,000 consultants working with external clients, Software AG CMO Ivo Totev is in a unique position to see how software is build cross-industry.
Software AG has more than 1,000 employees on its internal technical staff, along with several thousand more working on consulting and integration assignments. I met with CMO Ivo Totev to get a feel for what his clients were doing and how Software AG interacts with them.
Totev explains that one large barrier to agile adoption is the barrier to change. Large legacy projects, database projects and systems that protect services are all hard to change; they all require more coordination and communication and have slow test cycles. This extra overhead makes the agile idea of quick test, release and feedback cycles all the more challenging.
Dave Nicolette, an agile coach, is quick to agree. As he explains, "If your team is self-contained, without dependencies on others, you can go as fast and as smooth as you want. If you have to coordinate changes, you have to do more up-front and planning work. That doesn't mean you can't 'do' Agile. It just will require more overhead."
Commentary: Time, Distance Enemies of Agile Project Management
Case Study: Hotels.com Speeds App Development with Agile
The other big difference Nicolette sees is company size. Like Totev, Nicolette agrees that small project don't require a documented process. He continues: "If you have a 200-person company, with only a handful in software development, you might not need a process at all. Likewise, if you have a 2,000-person company, with several hundred in software development, with existing process and a legacy codebase, you might not be able to move fast enough to take advantage of what Agile has to offer."
After talking to Totev, Nicolette, I thought it was time to hear from the company with the largest customer base of software developers—Microsoft—about what it hears from its customers.
Microsoft Customers Less Agile Than They Think?
Microsoft Visual Studio Application Lifecycle Management is many things, but one of them is the process "wrapper" around Visual Studio. Karthik Ravindran, senior director of Visual Studio Product Management, talked to me about the latest release.
Ravindran agrees that software tied to version control and stories, working within a scrum framework, is a popular demand. Then he demonstrates the Scrum Template, a core part of tool. Within that template, work is defined in tasks, estimated and tracked in hours, and not adjusted to actual time.
This stands in contrast to most agile thinkers, who prefer to measure and predict based on past performance, ignoring time-on-task as a measure. Ravindran explains that predictive measures are possible with Visual Studio, but they aren't part of the "out of the box" template.
...
This gets me thinking about how object oriented programming has really been adopted.
The Real State of OOP Today: Form But Not Substance
Most of the people I talk to program in an object-oriented language. But there's a real difference between what they code and the kinds of programming advocated by Kent Beck in Implementation Patterns or Robert C. Martin in Clean Code.
That "brand" of OOP, the so-called "official" brand, has rules such as single responsibility and dependency inversion. These rules lead to extremely tight functions (think seven lines of code or less) and cyclomatic complexity of less than three (which means code is highly testable and therefore easy to fix).
Most people I interview are unaware that these rules exist. Instead, they write what's essentially procedural code plus inheritance and encapsulation, using an object oriented language.
Flip that around and look at today's "agile" teams. I see the same things: Cards flowing across a wall, "product owners," "sprints," daily standups and demo day. All are characteristics of agile. Still, in most cases, work is assigned by a manager, done by individuals and documented according to a company standard that can't be changed in a retrospective.
In the VersionOne survey—likely replied to by those most likely to embrace agile methods—only 43 percent of teams practice test-driven development and only 30 percent do pair programming.
We've come a long way with agile development, but the big risk is the same risk for OOP—that we'll have some of the form but lack the substance.
Move From Technical Agile Practices to Cultural Ones
Jon Kern, another agile coach, describes this risk as "human nature." It's something author Jerry Weinberg calls The Law of Strawberry Jam: The wider you spread something, the thinner it gets.
It's more than just spread thin, though. Practices such as project management, with stories, sprints and more frequent releases, have achieved better adoption than technical practices such as test-driven development and continuous integration. The technical practices have more adoption than cultural ones such as team ownership of process, multi-disciplinary, self-organized teams and constant pairing. All three of those categories are "agile," but you might call the cultural practices the "heartbeat" of agile.
Commentary: Why 'Agile Project Management Controls' Isn't an Oxymoron
The majority of market-driven companies today seem to be embracing the project management aspects of agile software. For everything else, there's room for improvement—which means room for competitive advantage.
That sounds, to me, like a good thing.
...
.END
No comments:
Post a Comment