Every software development organization today seems to practice the agile software development methodology, or a version of it. Or at least they believe they do. Whether you are new to application development or learned about software development decades ago using the waterfall software development methodology, today your work is at least influenced by the agile methodology.
But what exactly is agile methodology, and how should it be practiced in software development?
Agile was formally launched in 2001 when 17 technologists drafted the Agile Manifesto. They wrote four major principles for developing better software:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Before agile: The era of waterfall methodology
Old hands like me remember the days when the waterfall methodologywas the gold standard for software development. The software development process required a ton of documentation up front before any coding was done. Someone first wrote a business requirements document that captured everything the business needed in the application. These documents were long, detailing everything: strategy comprehensive functional specifications, and visual user interface designs.
This documentation effort was then followed with some form of technical specification that documented the application’s architecture, data structures, object oriented functional designs, user interfaces, and other nonfunctional requirements.
This waterfall software development process would finally kick off coding, then integration, and finally testing before an application was deemed production ready. The whole process could easily take a couple years.
We developers were expected to know “the spec,” as the complete documentation was called, just as well as the documents’ authors did, and we were often chastised if we forgot to properly implement a key detail outlined on page 77 of a 200-page document.
Software development itself back then also wasn’t easy. There were many development tools that required specialized training, and there wasn’t anywhere near the open source or commercial software components, APIs, and web services that exist today. We had to develop the low-level stuff such as opening database connections and multithreading our data processing.
For even basic applications, teams were large and communication tools were limited. Our technical specifications were what aligned us, and we leveraged them like the Bible. If a requirement changed, we’d put the business leaders through a long process of review and sign off because communicating changes across the team and fixing code was expensive.
Because software was developed based on the technical architecture, lower level artifacts were developed first and dependent artifacts afterward. Tasks was assigned by skill, and it was common for database engineers to construct the tables and other database artifacts first, followed by the application developers coding the functionality and business logic, and then finally the user interface was overlaid. It took months before anyone saw the application working and by then, the stakeholders were getting antsy and often smarter about what they really wanted. No wonder changes were so expensive!
Not everything that you put in front of users worked as expected. Sometimes, users wouldn’t use a feature at all, so that feature was a wasted investment. Other times, a capability was widely successful but required reengineering to support the scalability and performance required. In the waterfall world, you only learned these things after the software was deployed, after all that effort and expense.
The roles in the agile methodology
An agile software development process always starts by defining the users and documenting a vision statement on a scope of problems, opportunities, and values to be addressed. The product owner captures this vision and works with a multidisciplinary team (or teams) to deliver on this vision. Here are the roles in that process.
User
Agile processes always begin with the user or customer in mind. Today, we often define them with user personas to illustrate different roles in a workflow the software is supporting or different types of customer needs and behaviors.
Product owner
The agile development process itself begins with someone who is required to be the voice of the customer, including any internal stakeholders. That person distills all the insights, ideas, and feedback to create a product vision. These visions are often simple and short, but they nonetheless paint a picture of who the customer is, what values are being addressed, and a strategy on how to address them. I can imagine Google’s original vision looked something like “Let’s make it easy for anyone with internet access to find relevant websites and webpages with a simple, keyword-driven interface and an algorithm that ranks reputable sources higher in the search results.”
We call this this person the product owner. His or her responsibility is to define this vision and then work with a development team to make it real.
To work with the development team, the product owner breaks down the vision to a series of user stories that spell out more detail on who the target user is, what problem is being solved for them, why it’s important for them, and what constraints and acceptance criteria define the solution. These user stories are prioritized by the product owner, reviewed by the team to ensure they have a shared understanding on what is being asked of them.
Software development team
In agile, the development team and its members’ responsibilities differ from those in traditional software development.
Teams are multidisciplinary, composed of a diverse group of people with the skills to get the job done. Because the focus is on delivering working software, the team has to complete end-to-end functioning applications. So the database, business logic, and user interface of part of the application is developed and then demoed—not the whole application. To do this, the team members have to collaborate on what and how they are developing. To do that, they meet frequently to make sure everyone is aligned on who is doing what, and how the software is actually being developed.
In addition to developers, software development teams can include quality assurance (QA) engineers, other engineers (such as for databases and back-end systems), designers, and analysts, depending on the type of software project.
References: