13:42
Juan MC Larrosa
What Every Company Should Know About Agile Software Development
By Eric Wittman, General Manager, Developer Tools on July 7, 2014 | Provided by Atlassian
MIT Technology Review
Does your company make medical devices? How about cars? Or appliances? Or mobile applications? Do you have an external website?
If you answered “yes” to any of these questions, then your company is a software company. As more and more businesses enter this category, the adoption of agile software development practices is becoming mainstream—and not just in the high-tech sector. Across industries, businesses are realizing that, even if their only foray into software is a corporate website, that software is the organization’s public face—and increasingly so, in this digital age of ours. Best to make a good first impression.
Agile software development is no longer a “bleeding-edge” approach. Nor does it mean that a bunch of rogue coders are riding roughshod over the roadmaps, timelines, and standards that are very real for businesses. In fact, the agile software approach requires a cultural embrace and commitment from the corner office all the way to the smallest cubicle.
Agile’s value is well-documented. The approach has helped teams at both large enterprises and small startups deliver high-quality software—on time—for more than a decade. If your organization is not already employing agile software development practices, now is the time to adopt them to maintain a competitive edge and deliver the best possible products to customers.
Waterfall projects generally begin with a bevy of requirements documents, amassed over several weeks or even months: functional requirements, technical requirements, marketing requirements, product requirements—the list goes on. The actual coding doesn’t start until all these documents have been approved. Once development begins, it continues until all requirements have been coded to spec, then the quality assurance team takes over. Stakeholders and end users typically don’t get to see or try the results until the very end, often months or years after the project’s inception.
Meanwhile, changes in the market inevitably cause customer needs to change as well. But the specs were locked in months earlier and much of the development budget has been spent, so pivoting to meet the evolving competitive landscape is painful, if not impossible.
Worse, when a waterfall project falls behind schedule, that squeezes the final two phases, quality assurance and customer testing. Too often, the result is an application that functions poorly, no longer meeting the customer’s—or the business’s—needs.
The key words here are early and continuous.
Agile doesn’t mean a complete lack of documentation and scheduling. Indeed, agile software development projects also start off with a vision and a set of initial requirements. The difference is that, rather than spending months detailing exhaustive specifications, an agile project will begin development as soon as the requirements are fleshed out just enough for the coders to begin building the initial core pieces of working software.
Throughout the project, product managers, often called product owners, work one step ahead of developers, cultivating a prioritized backlog that includes granular tasks to tackle in the near term and coarsely defined items for later on. For their part, testers work in parallel with developers, focusing on automation so that changes can be fully tested within minutes of being checked in.
As a gardener, I like to compare agile to landscaping. Very few homeowners tear out the entire backyard and replant the whole thing at one shot, the way it’s commonly done on the makeover shows on TV. Instead, most people landscape in stages, putting a lawn in first, along with a tree or two, later adding some bushes and shrubs, and finally planting the small perennials that will provide seasonal accents. Software, like a garden, is a living, breathing entity that will grow over time.
An agile team’s goal is to deliver narrow, fully-functional slices of the project at the end of each iteration (usually one to two weeks in length). Perhaps a website’s basic login functionality—from the user interface all the way down to the database—is built during this iteration; next iteration, a “forgot password” feature might be added, and so on. Each slice is demonstrated to end users and stakeholders at the end of the iteration so they can provide feedback on what’s been built so far and guide priorities for future iterations. As you can imagine, this approach makes adapting to the changing marketplace a whole lot easier and makes your software more relevant for customers.
This cultural shift is what makes adopting agile so challenging for large companies with established rules and procedures. Managers have to get comfortable with letting development teams self-organize around their work during each iteration—not just who does what, but how much the team commits to delivering. Developers, testers, and operations engineers must learn to work side by side throughout the project, sharing responsibility for quality, stability, and performance instead of just “throwing it over the wall” to the team downstream. And everyone must embrace the idea that shipping fewer, high-quality features is better than shipping a bunch of features that don’t quite work right.
Fostering a climate of rapid feedback and continuous improvement brings other advantages, too. First, agile software development practices are very highly regarded in the programming world—so much so that top-tier programmers overwhelmingly prefer it. If you can describe yourself as an “agile shop,” you’ll more easily attract and retain a quality crop of software engineers.
Second, agile need not (and should not) stop at the borders of the engineering and IT departments. At Atlassian, agile has permeated into all aspects of the business: strategic planning, marketing, and even recruitment. Because all our work is guided by agile principles, we feel the same pain points as our customers. That, in turn, has helped us create de facto standard tools used by some 35,000 teams worldwide to support their own agile adoption and development practices.
No business wants to merely survive. We all aim to thrive in this exciting and increasingly competitive global economy. A change in approach is clearly necessary—and not just for grand, multi-year IT projects. Technologies and markets shift constantly, and companies need a development process that can keep up with them. Agile software development, as more of the world is discovering, is precisely that process.
By Eric Wittman, General Manager, Developer Tools on July 7, 2014 | Provided by Atlassian
MIT Technology Review
Does your company make medical devices? How about cars? Or appliances? Or mobile applications? Do you have an external website?
If you answered “yes” to any of these questions, then your company is a software company. As more and more businesses enter this category, the adoption of agile software development practices is becoming mainstream—and not just in the high-tech sector. Across industries, businesses are realizing that, even if their only foray into software is a corporate website, that software is the organization’s public face—and increasingly so, in this digital age of ours. Best to make a good first impression.
Agile software development is no longer a “bleeding-edge” approach. Nor does it mean that a bunch of rogue coders are riding roughshod over the roadmaps, timelines, and standards that are very real for businesses. In fact, the agile software approach requires a cultural embrace and commitment from the corner office all the way to the smallest cubicle.Agile’s value is well-documented. The approach has helped teams at both large enterprises and small startups deliver high-quality software—on time—for more than a decade. If your organization is not already employing agile software development practices, now is the time to adopt them to maintain a competitive edge and deliver the best possible products to customers.
Why Waterfall Falls Down
To understand agile’s advantages, it helps to first understand the traditional method for developing software, often called “waterfall.”Waterfall projects generally begin with a bevy of requirements documents, amassed over several weeks or even months: functional requirements, technical requirements, marketing requirements, product requirements—the list goes on. The actual coding doesn’t start until all these documents have been approved. Once development begins, it continues until all requirements have been coded to spec, then the quality assurance team takes over. Stakeholders and end users typically don’t get to see or try the results until the very end, often months or years after the project’s inception.
Meanwhile, changes in the market inevitably cause customer needs to change as well. But the specs were locked in months earlier and much of the development budget has been spent, so pivoting to meet the evolving competitive landscape is painful, if not impossible.
Worse, when a waterfall project falls behind schedule, that squeezes the final two phases, quality assurance and customer testing. Too often, the result is an application that functions poorly, no longer meeting the customer’s—or the business’s—needs.
The Agile Advantage
But lest we despair, agile software development provides a proven alternative. Its philosophy is summed up in the first principle of the “Agile Manifesto,” published in 2001 by a group of experienced and thoughtful programmers: “Our highest priority is to satisfy the customer through early and continuous delivery of working software.”The key words here are early and continuous.
Agile doesn’t mean a complete lack of documentation and scheduling. Indeed, agile software development projects also start off with a vision and a set of initial requirements. The difference is that, rather than spending months detailing exhaustive specifications, an agile project will begin development as soon as the requirements are fleshed out just enough for the coders to begin building the initial core pieces of working software.
Throughout the project, product managers, often called product owners, work one step ahead of developers, cultivating a prioritized backlog that includes granular tasks to tackle in the near term and coarsely defined items for later on. For their part, testers work in parallel with developers, focusing on automation so that changes can be fully tested within minutes of being checked in.
As a gardener, I like to compare agile to landscaping. Very few homeowners tear out the entire backyard and replant the whole thing at one shot, the way it’s commonly done on the makeover shows on TV. Instead, most people landscape in stages, putting a lawn in first, along with a tree or two, later adding some bushes and shrubs, and finally planting the small perennials that will provide seasonal accents. Software, like a garden, is a living, breathing entity that will grow over time.
An agile team’s goal is to deliver narrow, fully-functional slices of the project at the end of each iteration (usually one to two weeks in length). Perhaps a website’s basic login functionality—from the user interface all the way down to the database—is built during this iteration; next iteration, a “forgot password” feature might be added, and so on. Each slice is demonstrated to end users and stakeholders at the end of the iteration so they can provide feedback on what’s been built so far and guide priorities for future iterations. As you can imagine, this approach makes adapting to the changing marketplace a whole lot easier and makes your software more relevant for customers.
It’s All About the Culture
Make no mistake: More than anything else, agile is a shift in organizational culture. All the agile-flavored tools in the world won’t make your teams nimble. The role of tools is simply to reflect your teams’ processes and make following them less onerous.This cultural shift is what makes adopting agile so challenging for large companies with established rules and procedures. Managers have to get comfortable with letting development teams self-organize around their work during each iteration—not just who does what, but how much the team commits to delivering. Developers, testers, and operations engineers must learn to work side by side throughout the project, sharing responsibility for quality, stability, and performance instead of just “throwing it over the wall” to the team downstream. And everyone must embrace the idea that shipping fewer, high-quality features is better than shipping a bunch of features that don’t quite work right.
Fostering a climate of rapid feedback and continuous improvement brings other advantages, too. First, agile software development practices are very highly regarded in the programming world—so much so that top-tier programmers overwhelmingly prefer it. If you can describe yourself as an “agile shop,” you’ll more easily attract and retain a quality crop of software engineers.
Second, agile need not (and should not) stop at the borders of the engineering and IT departments. At Atlassian, agile has permeated into all aspects of the business: strategic planning, marketing, and even recruitment. Because all our work is guided by agile principles, we feel the same pain points as our customers. That, in turn, has helped us create de facto standard tools used by some 35,000 teams worldwide to support their own agile adoption and development practices.
No business wants to merely survive. We all aim to thrive in this exciting and increasingly competitive global economy. A change in approach is clearly necessary—and not just for grand, multi-year IT projects. Technologies and markets shift constantly, and companies need a development process that can keep up with them. Agile software development, as more of the world is discovering, is precisely that process.
Entradas
