The most enthusiastic Agile advocates believe it can save the world. Skeptics think it’s an industry built on turning basic ideas into complex and costly processes. The truth is somewhere in the middle. While some agile practitioners might be overpromising, there’s no denying Agile’s impact on how the world designs and builds software.
As you might expect, Agile methodologies aim to help organizations build software in ways that boost speed to market and increase responsiveness to customers. They were created to help development teams move faster, use resources efficiently, and more quickly respond to change. Agile principles put a premium on collaboration, with the aim of faster delivery of better software that more fully meets real world end user needs.
Where Did It Come From?
Agile is a formalization of the rapid application development principles first presented in the early 90s. Rapid application development, first championed in Jim Martin’s book of the same name, sought to bring much-needed speed and flexibility to traditional software development sometimes called waterfall. These processes relied on a linear approach with phases that had to be completed in sequence
Martin and other RAD advocates believed that the traditional software methodologies could not handle the realities of software development:
User requirements often evolved as an application was built
Waiting until the end of the process to deliver drove up the cost of addressing eventual feedback
The same linear approach also increased the possibility of significant technical risk. What happens if user requirements evolve while an application or service is moving from concept to completion? Waiting until the end of the process to deliver a final product, as prescribed by a classic waterfall software development lifecycle (SDLC), exponentially drove up the cost of addressing feedback and managing risk when it occurred.
During the 1990s, software professionals worked to bring shared, scalable best practices to rapid application development, grounding its ideas in much-needed detail and discipline. Two notable efforts were:
· Rational Unified Process (RUP), first advocated for a simplified, iterative approach to software design
· Extreme Programming (XP), designed around more collaborative, team-driven programming and more aggressive design and feedback loops.
Together, these methodologies formed the foundation of Agile, championing iteration over linear development and collapsing the complicated waterfall phases into a simplified approach focused on usability over project artifacts.
The Agile Manifesto
With RAD, RUP, and XP as a foundation, the Agile Manifesto clarified the latest thinking and best practices of rapid application advocates. Written in 2001, between the dot.com boom and the coming digital century, the manifesto was short and to the point. In fact, the manifesto is so concise that we can include the entire thing here:
“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
It also instructs readers that while “... while there is value in the items on the right, we value the items on the left more.”
It is these four shifts that defined Agile, and they came just in time. As the dot.com economy boomed, companies found themselves under extreme pressure to both bring products to market quickly and enable fast, frequent updates of those applications. The timing of the Agile Manifesto could not have been more perfect.
RELATED: Understanding Agile Project Management
Agile Development Principles
The manifesto itself outlines 12 fundamental principles that illustrate what makes Agile different. Taken together, these principles illustrate four foundational themes.
Working Software
Quickly moving to a working software prototype is perhaps the most radical departure from traditional SDLCs. Rather than spending all their time completing and updating requirement documents, Agile practitioners work quickly to build a working prototype of the proposed software.
Not only does this allow stakeholders to better engage with requirements in the real world, but it also gives developers more time to find errors and make the changes required to maintain fidelity to the initial vision. Finally, it lends itself to the critical Agile tenet of continuous delivery.
Continuous Delivery
In Agile there is little distinction between the first release and the next “point release” update. The goal is to achieve a consistent pace of updates and upgrades, driven by continuous feedback from customers and users.
This pace is also critical to how work is managed across teams. It’s also essential to Agile’s insistence on embracing (and even encouraging) ever-changing requirements. Continuous delivery offers more opportunities to listen, learn, and refine software as it is built and updated going forward.
Changing Requirements
A static requirements document can’t keep up with a customer’s evolving requirements. Agile is optimized for a world where requirements will change throughout the development process, so design and build teams must be ready to update the prototype to reflect the new realities quickly.
Regular Intervals
To be able to embrace changing requirements as inputs, it requires developers to build in shorter, iterative cycles.
These cycles come at shorter, more consistent intervals. Dividing a large project into shorter phases also enables developers to find opportunities to re-use code and be more proactive about managing delays.
We’ll learn a little bit later about what these intervals look like on paper. but in general, this iterative approach to software, combined with a focus on continuous delivery, is well-suited for a digital world where users expect a steady stream of meaningful updates and upgrades.
Self-Organization
This last concept isn’t so much about the software, but rather the team building it. Agile does its best when designers and developers are empowered to self-organize both their teams and their workflows. This means breaking free of traditional management hierarchies to achieve a higher degree of agency and autonomy.
This self-organization is an ideal complement to the way the software itself is built. Continuous delivery, in short, regular intervals, of evolving prototypes, naturally helps teams evaluate priorities and make action plans. Regular scrums (more on these later) also provide a check-in to ensure team and project goals are intrinsically aligned.
The Agile Methodology
While the manifesto laid out the blueprint of what motivated Agile practitioners, it was hardly an instruction manual for those looking to integrate and implement in the real world. Luckily, the manifesto was only the first step. With these principles in place, Agile advocates can move Agile from idea to implementation.
ALSO READ: What Is Rapid Application Development? A Faster Path to Superior Value
Why it Matters
Like its predecessor, rapid application development, Agile is designed to focus the hard work designers, coders, testers, and project managers on the big picture end goal: high-quality software. This also unlocks big benefits for the organization and the customer.
Speed to Market
As you might expect from the name, the core appeal of Agile methodology is speed. Developers focus on getting to a prototype quickly, then moving from that model to a final product. Every step taken in that process is optimized for speed. This means learning is faster and testing and subsequent refinements happen more rapidly, reducing the cycles required to move the application from idea to market-ready product.
Predictability and Transparency
Breaking a project into smaller pieces, combined with efforts for continuous delivery, should lead to more project predictability. Why? Because Agile is better suited to deal with constant change, and shorter intervals give projects more time to get back on track rather than waiting until final delivery to realize it’s “all gone wrong”.
The nature of Agile project management helps stakeholders know precisely where the work stands at all times as a result of the modular nature of rapid application development. Breaking the project into smaller pieces also boosts visibility into the project at any time.
Greater Value
While Agile may not immediately reduce upfront development costs, over time it produces a better product. It also drives nimbler project management, fewer hours spent on administration, and less time lost to unclear priorities.
Agile is also predicated largely on simplicity, where developers look for the most direct way to solve a particular need or feature gap. The same focus also prioritizes re-use of code where possible, meaning that, in best-case scenarios, developers can build an object once and use it many times.
A Focus on the User
This final benefit might seem obvious—isn’t all software built for users? However, as we learn more about the specifics, with Agile this prioritization becomes more pronounced. The entirety of the design, development, and testing processes begin and end with the user and their needs.
The knock-on effect of creating better software leads to more satisfied customers. Moreover, it helps give development teams a stronger sense of shared purpose since they’re not just coding software. They’re making tools and services for real people.
The Agile Methodology
Ideas are important, but how do they get put into action? The critical distinction between rapid application development as a principle and Agile as a methodology is found in specific roles and processes. Without these, software professionals can adhere to Agile principles, but won’t benefit from the best practices. That’s why it’s so important to understand the building blocks of the Agile process, especially those that differentiate it from previous SDLC models, waterfall in particular.
Unique Roles
Agile methodology is marked by a few distinct roles in addition to whatever technical specialists are required to get a project over the finish line. These Agile roles also very specialized, with multiple certification programs offering officially sanctioned/badged training for two of the three.
Product Owner
The Product Owner is the voice of the customer, although, given the need for continuous feedback, they serve as a representative, not a replacement. They are the master of all business requirements, with a deep understanding of priorities, and tasked with making tradeoffs as development progresses and scheduling features into future releases.
Scrum Master
Let’s start with what the scrum master isn’t. They are not a project manager, although they do take over some of the traditional PM tasks. This is an important distinction when moving from other SDLCs to Agile. The Scrum Master’s primary task is to ensure that development teams are adhering to Agile principles, which is why the job is so much larger than a project manager. They’re a unique cross between manager, coach, counselor, and mentor.
Team Members
This role includes everyone else working on the project, based on scope. For software, this typically includes designers, developers, database specialists, and testers. It also includes project personnel, and whatever domain expertise is relevant to the project.
Unique Agile Artifacts and Processes
In addition to the roles, the Agile development process has unique processes and deliverables that set it apart from waterfall SDLC.
User Stories
A user story is a minimally detailed, user-focused view of a specific feature or function. Given Agile’s approach to big picture requirements, these stories are a natural starting point. Each user story should lay out a single task or end-state the user is expected to accomplish. For instance, for a finance tool, the user story might read “User downloads the most recent payroll report.”
User stories can capture business and technical requirements, as long as the story remains focused on the user’s needs. The story above could be expanded to say, “User downloads the most recent payroll report on a smartphone.” Large, complex stories are called epics. Also, stories can be split into more manageable stories if appropriate. These user stories are created by the product owner.
User Story Points
Once a story is built, it’s assigned points based on time, risk, and complexity. These points allow the development team to prioritize among stories for the same application. Absolute values are less important than relative – the point is to set a path to estimation and prioritization.
The team assigns user story points with help from the Scrum Master. Once points are assigned, values are reviewed by the Product Owner, who then sets priorities for a specific sprint.
Sprints
A sprint is the smallest unit of project measurement on an Agile workplan. At the end of a sprint, work is presented for review by the Product Owner and other stakeholders. Sprint lengths depend on the project, but two weeks is the average. Sprint progress is tracked via daily scrums.
Scrums
Scrums are typically daily, often face-to-face meetings to update the teams on progress to-date, obstacles encountered, and resources needed. It’s also an opportunity to measure project risk, adapt as required, and update the product backlog.
Product Backlog
A product backlog lists the additional features, changes to existing features, fixes, infrastructure changes, or other outstanding requirements that stand between this sprint and completion. They are maintained by the product owner, who prioritizes the backlog according to story needs.
There are also sprint-level backlogs that capture the above information relative to a specific sprint.
RECOMMENDED: How to Get Your Team To Execute (and Love) Agile Digital Transformation Practices
What is Agile Development Beyond Software?
The powerful ideas behind Agile and its wholehearted adoption by the software industry has inspired other disciplines and industries to consider its application in their own fields. How can project and product teams outside of software quickly move an idea from abstraction to existence? Whether they love the focus of iteration over sequence or the power of prototypes, people are hungry for new ways of working. Agile has a lot to offer.
Not for Everybody: Where Agile Doesn’t Work
As transformational as Agile can be, it’s not an ideal fit for every software project. There may be technical or organizational constraints that make other SDLC approaches, even waterfall, are more appropriate.
Your Heart Isn’t in It
Everybody loves Agile, right? However, it’s a big step, and there are lots of successful projects completed every year without it. If you’re unwilling or unable to commit to Agile from start to finish, save yourself the frustration
Your Culture Isn’t Ready
Agile depends on lots of collaboration, and face-to-face is best. If your teams are heavily siloed, the transition to Agile might be lengthy and expensive. There are certainly resources/training to help drive education, but that presents another obstacle to success.
Your Customer Isn’t Ready
Agile is heavily focused on customer/user feedback. If your customer can’t provide input on a regular basis, an Agile approach is probably inappropriate.
You Don’t Have Access to the Talent
Agile does make some pretty specific demands on your team members. While certification isn’t 100 percent required, the roles of Product Owner and Scrum Master are specialized skill sets. If you can’t find this kind of specialized expertise, your best Agile efforts probably won’t pay off.
There Are Constraints Outside of Your Control
The fast-paced, iterative nature of Agile demands everything moves at a quick pace. If your project has lots of infrastructure dependencies you don’t manage, you may be setting yourself up to be permanently behind schedule.
Getting Started with Agile Development
Your first Agile project is a big step. It’s a serious investment in new ways of thinking about how you build and deliver software. It requires new skills and mindsets. It also means choosing an ideal pilot:
· Modular, user-focused software
· A project that falls within your functional and domain expertise
· A relatively reasonable timeline that allows time for learning
· Invested, engaged customers
· A team that’s ready to take on new skills and responsibilities
Kintone Can Help
At Kintone, we’re specialists at helping businesses plot their path to (and through) digital transformation. Let our experience and expertise help you choose the best practices that best fit your vision of tomorrow. We bring together technology experts, deep business smarts, and a robust solutions suite to help you solve the big challenges standing in your way. Not sure you’re ready for Agile? Let us help you learn more.
About the Author
