Were you working in software development 14 years ago, when the Agile Manifesto was signed and published? Since the appearance of that once-controversial document, a majority of software development organizations have adopted some, to many, to most agile methods as a better way of meeting deadlines and satisfying customer demand for software. In a recent TechBeacon article, John Jeremiah even suggests that agile is "the new normal." While a few organizations cling to waterfall practices, and still fewer describe themselves as strictly waterfall shops, the trend is clearly toward agile, even "pure agile" development.
But what does "pure agile" mean, exactly? Zealously adhering to the development practices described by Kent Beck's Extreme Programming (XP) model, or Ken Schwaber's scrum? Abandoning practices like requirements management and planning, or software modeling based on the UML (Unified Modeling Language), all honed over years of doing large projects?
The question of agile purity made me return to the Agile Manifesto, which I hadn't read in years. Its 17 signers back in 2001 came from a wide variety of software development interests, yet they found common ground in the Manifesto's core statement:
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
That's the heart of it. The stuff on the right, after the word "over"—the hallmarks of process-heavy, activity-oriented, command-and-control thinking—needed to be replaced with a faster, more practical approach to getting things done. But as "purely agile" as this new thinking might be, the document says little (beyond its 12 supporting principles) about how the work actually gets accomplished.
That much-needed guidance would emerge over time through further work done by the signers themselves, along with many others. Within a few years of the Manifesto, terms like "pair programming," "stand-up meetings," "sprints," and "test-driven development" were creeping into software development discussions. Large process frameworks like the Rational Unified Process (RUP) began to emphasize tailoring its many practices to just what teams needed to be agile; on the other hand, small agile teams that needed to scale up to larger projects began using Disciplined Agile Delivery (DAD) and Scaled Agile Framework (SAFe) practices to fill in the gaps at an enterprise level.
Today, agile methods like scrum, XP, AM, Agile Data, and Kanban are still out there to be studied and adopted. But from what I've seen over the past decade, not a single one of these methods alone holds all the answers for any given development organization.
What the experts are seeing and saying
I decided to ask my colleagues from the former Rational Software why this is the case. More broadly, I wanted to know what they were seeing in the post-Agile-Manifesto era that might put into perspective some of the percentages—from pure agile to pure waterfall—that John Jeremiah reports (see the pie charts in his article here).
I think you can see the ghost of the Agile Manifesto (the "spirit of agile," if you will) in most of the SME responses covered below. I've tried to break down the responses from these specialists under differentiated subtopics, but honestly, there's a lot of agreement here. I grouped the various discussions under scalability, hybrid agile, the agile mixed bag, and finally the focus on success with agility. Here's what they had to say.
The "scaled agile" approach
Kurt Bittner, principal analyst at Forrester Research, sees teams using a mixture of techniques from scrum and XP, also SAFe: "A team might use scrum's approach to planning and estimating sprints, but also use pair programming [from XP]. Agile techniques from different approaches are broadly complementary. We see greatest adoption of scrum, but with lots of other practices folded in.
"The different agile approaches are best thought of as a set of practices rather than closed processes. They can be easily combined with other approaches. This is because the different approaches broadly agree on principles and differ mostly on which practices they think are most important."
Anthony Crain works as the agile transformation lead at Blue Agility. He has lived and breathed software development and development practices since the mid-1990s and is a passionate agile evangelist and speaker. He sees team culture as the primary factor governing the application of agile:
"Agile is very strongly about high-trust, self-organizing teams. The idea of strict adherence to any one approach directly contradicts those ideals. One of my personal goals is to increase innovation by teaching teams to say 'yes' to new ideas instead of the 'no' I so often hear—and sometimes accidentally say myself. I see no advantage in a single approach. You might say you'd get better metrics by using a single method, but we find metrics that work, regardless of lifecycle. My teams use practices from scrum, DAD/Agility@Scale, RUP, Spiral, and possibly others that we aren't even aware of and all benefit our team greatly. The team with the largest bag of tricks and techniques will outperform those lacking those techniques if all other factors are equal."
Hybrid agile: With enough agility, you can handle a little waterfall
Dave West spent several years at Forrester Research, where he coined the term "water-scrum-fall" while observing software development teams across an array of industries. He's now the chief product officer for Tasktop Technologies. "No one is doing 'pure' agile, and I'm not sure if that's possible," says West. "Agility is all about responding to change and building the right way for the situation—which includes team experience, the problem that you are solving, dependencies on other groups, technology being used, and even the culture of the organization. Thus, one man's agile might be another man's horror!
"What I see with our clients is a collection of different ways of building software with scrum as the primary way to organize the team. Around the scrum team is a collection of processes and practices determined by experience, context, and environment. Now, we do see organizationally most companies still putting these agile team practices in the context of a sequential or waterfall lifecycle. I wrote about this when I coined the term 'water-scrum-fall,' which means planning and release management are very waterfall-oriented, but development itself is very much like scrum. The solution to 'water-scrum-fall' seems to be the focus of approaches like Scaled Agile Framework (SAFe) and Disciplined Agility Delivery—not necessarily removing the sequential nature of the macro process, but at least enabling it to work with agile teams."
Dave has a lot to say, with his teams clearly focused on several incarnations of scrum.
[Also see: Is the Agile Manifesto dead?]
"Each of our five teams at Tasktop are an ideal size for scrum. We have clear problems to solve—business focus, even tool set, but we have three different implementations of scrum. Yes, they are similar, but the way they estimate, plan work, test, even design is very different. The end product is the same (definition of done), but the processes are very different. Here's why:
"I have three teams working on very well-defined integration connectors; one team working to support our existing products; and one team building new products. That's three very different contexts, and each is very natural and effective. Teams get to drive how they work—I impose constraints to ensure transparency and that dependencies are managed, but other than that I just support them.
"The reality is not to force one process, but instead provide the requirements that each team must support to enable it to function in the organization. Build out tools that support cross-team transparency, even if that means connecting slightly different process models. Empower scrum masters to drive change in the pursuit of delivering better software. Do that and you deliver on the dream of agile without creating dogma around any one approach."
Michael Rowe's comment suggests a similar sense of reality. He's currently a business development executive at IBM and cofounder and cohost of GamesAtWork.Biz.
"Understanding the specific business needs and development environment for your specific program or project, and being flexible enough with your methodology to achieve those needs, is more important than adhering to a specific methodology. Net-net, I see teams using hybrid approaches almost exclusively. While agile methods are a great foundation, most teams will use it, along with other appropriate methods for their product or application."
The agile mixed-bag scenario
TechBeacon contributor and quality management specialist Amy E. Reichert, currently with HealthMEDX, sees teams using a customized mix of agile methods. "They alter the process to fit their workflow. And honestly, this mixed-bag approach is more realistic. Development teams need the ability to use the pieces that work for the team and the business. Restricting teams to execute agile under strict guidelines reduces the positive impact of using agile methods and defeats the purpose." But she recognizes the appeal of "rules" for people well-versed in tried-and-true engineering principles, even hard science: "I realize many people get attached to following rules in order to champion a cause. However, in my opinion it's better to focus on what works to get higher quality applications to customers in a quicker, repeatable manner."
Martin Bakal, former product manager at Flexera Software and a former product manager focused on agile and embedded development at IBM, has a similar perspective: "Most companies claim they're doing scrum, which gives you a great structure day to day. But it doesn't give you all the mechanisms you need, like pair programming [which comes from XP]. You can adopt from other methods to make your own, to be agile. Personally, I think this is a good thing. One size doesn't fit all."
The focus should be success
Between 2001 and 2004, Gary Pollice, now professor of practice in computer science at Worcester Polytechnic Institute, wrote a regular column called "Theory and Practice" for The Rational Edge magazine, which I had the good fortune to edit. As a practitioner and methodologist turned academic, he brings a different perspective to this discussion:
"Almost none of the successful teams use any specific methodology as specified. I stress successful here. I have seen so many organizations and teams try to shape themselves and what they do into a mold described by the methodology and eventually end up failing because they are spending too much time on nonproductive tasks. Teams must realize that the appropriate way of working depends on the organization, the project, and the team. You have to continually tweak and reflect upon the process.
"If you don't let the team have some form of self-governance, they will not be as successful as they could be, and may not be successful at all. In the last five years I've modified my software engineering course to force the students to really reflect upon, and understand, how the team can succeed. They have to define and continually adjust their team processes based on the people and the project they've been given. The feedback that I've gotten from employers and the students who have graduated absolutely convinces me that it's the right way to approach things. The method has to be hybrid."
For years, Walker Royce, chief software economist at IBM from 2010 to 2015, has been a tireless advocate of iterative development, which is an underlying principle of agile. He advocates a steering approach rather than a rigid, planned-course approach to software development projects, and backs it up with concepts derived from Bayesian analysis and the work of Barry Boehm (based at the University of Southern California).
"Across a broad spectrum of projects, I have observed that more success is correlated with teams who apply a mix of methods and tailor them to the specific culture and context of the project at hand," say Royce. "Truly agile teams—namely those whose product pipelines exhibit freedom of change—are rarely attached to a narrow-minded process dogma, agile or otherwise.
"Instead, they adapt their methods, tools, measures, collaborations, and product designs to the evolving context. This includes the application context of the project as well as the temporal context within the project lifecycle. Adherence to a single agile method seems somewhat oxymoronic, since agility is such a context-dependent attribute and agile methods are typically written in a context-independent manner."
(Too soon for any) conclusion
If pure agility is the goal for your software development team, the experts I've heard from suggest that following a single agile method doesn't have to be part of the plan.
The basic ideas are 1) Understand your organization and the culture in your software development team; 2) Don't restrict your team to any one methodology, but find what keeps your teams moving toward successful outcomes that benefit your business; and 3) Adjust your approach to the project and the people you've got to work with.
As Anthony Crain says, "The team with the largest bag of tricks and techniques will outperform those lacking those techniques."
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
