The term Development can be related to just about any industry: construction, manufacturing, marketing, information technology, software development, hardware development, and research, just to name a few. When we talk about Agile, it is usually applied to software development, but it can be (and is easily) applied within all industries that produce a product.
Over time, traditional approaches to development have evolved and brought us to where we are today, with mixed uses of both traditional and Agile methods of product development. This blog post focuses on software development and how the Agile process has revolutionized the way software is created.
The Way it Was
Software development began a long time ago. Some would say the history of software development began in the late 1940s and really took off in the 1960s, as computers became more affordable and prominent in use within industries. Over time, software development processes evolved into what is known as the Waterfall approach of project management. This method of software development was most prevalent in the 1970s through the early 2000s, and it is still in use today. It is an “approach that emphasizes a linear progression from beginning to end of a project.” (1) According to Waterfall Methodology, this is a sequential development process that flows like a waterfall through all phases of a project, with each phase being completely finished before starting the next one. The phases are usually defined as requirements gathering, design, implementation, verification or testing, and deployment and maintenance.
The primary difficulty experienced with this approach is that if requirements change any where along the process, it is hard to change course without affecting the cost and time to market of the product being produced. It also assumes that the requirements can be defined up front and that they will be fully understood by the developers by the time design and implementation are started. Customer collaboration is minimal after the requirements gathering phase. By the time the product is finally produced and delivered, it is often times not what the customer had hoped for, either due to not fully knowing what they wanted upfront, or by discovering features that they should have asked for when they saw the finished product.
How did we become Agile?
In early 2001, 17 experienced software development professionals got together in Snowbird, Utah, to discuss ways to improve the software development process. As a result of this gathering, they defined the Manifesto for Agile Software Development. The Manifesto encompasses 4 main values, where the highlighted words on the left are valued more than those on the right:
- Individual and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
They also defined the Twelve Principles of Agile Software, which expand on each of the values in the Manifesto.
Out of these values and principles, the Agile development process was born.
The Agile Process of Development
Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an Agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.
The Agile process is designed to be much more flexible than the Waterfall approach. The focus of Agile is on customer collaboration and producing working products. The customer is involved from the beginning to the end of the development process, and can introduce requirement changes or feature requests along the way without substantially delaying the product. Agile is an iterative process that tackles the planning, design, implementation, and testing in shorter, repeating cycles. Agile works in short windows of times, called sprints, where prioritized tasks are completed, in usually about 2 or 3 weeks.
Cross-functional teams are centric to Agile development. The team includes people with diverse but complementary skills, who work closely together to get the work done. The team relies on each other and on the complete transparency of the product development. An Agile team always includes a Product Owner, who is focused on the product in development, and the Scrum Lead, who is focused on the team and the project timeline. The rest of the Scrum Team is usually a small team of 5-11 individuals and consists of software developers, engineers, analysts, system admins, and testers. The team is expected to be self-managed and encourages daily collaboration.
What’s going on - 20 years later? What’s the impact?
So, Agile has been around for 20 years…. How has it impacted the development world?
Although Agile development hasn’t completely replaced Waterfall development, it is definitely the front runner as the preferred project management approach. According to 20+ Astonishing Agile Adoption Statistics for 2022,
- 71% of companies are adopting Agile.
- 60% of companies experience growth in profits after adopting an Agile approach.
- 80% of federal IT projects adopt Agile.
- The Agile failure rate is 8%. The Waterfall failure rate is 21%.
The article states that there are many Fortune 500 companies that have adopted Agile, including IBM, Microsoft, and Cisco. It also says that the FBI is adopting Agile and that the manufacturing industry is invested, with over 25% using pure Agile. Lastly, it notes that more than half of companies in the construction industry use a combination of methodologies, including Agile.
According to “Agile vs Waterfall? Do Both?,” Jeanne Bradford puts forth that “The reality is that hybrid processes that mix the discipline and long-term planning of the Waterfall model with the adaptability and speed of Agile are not only possible – they are best-in-class”. This article focuses on hardware development and explains that 75% of the Agile Manifesto and the 12 Principles can apply to any type of development.
Agile has shifted the ‘power’ from management to the product teams to get their work done. In the long run, this may have increased software development professionals to enjoy their work more. In the Agile environment, success depends on high performance teamwork. In order to achieve this, upper management has empowered project teams to plan and prioritize their work and middle management changes their focus from micro-managing to removing obstacles that hinder the team’s productivity. Team members benefit from being ‘heard’ and can see their contributions more easily in the final product.
In addition to molding the approach to the development process, Agile has also spawned a huge industry that revolves around the tools and frameworks that Agile teams use. There are source control tools, such as Git, Mercurial, Subversion, and CVS. There are contiguous integration tools, such as Hudson, Jenkins, Travis CI, and Strider. There are team management tools: HP’s Agile Manager, Active Collab, JIRA Agile, Agile Bench, to name just a few.
Finally, from personal experience that spans from the 1980s through today, I can say that following the Agile process or methodology has helped software professionals develop a more personal relationship with other team members which helps them to be more empowered, productive, and satisfied in the long run.
How do we use Agile at IDEAMATICS?
Not only has IDEAMATICS adopted the Agile approach to Software Development, but we’ve enhanced it by going one step further. We developed the I-Agile™ development methodology, which is an iterative Agile development process that delivers frequent releases (e.g., every month), responds easily to customer requirements changes, allows for cybersecurity scans, and works with Government technical reviews (e.g., Preliminary Design Reviews [PDRs], Test Readiness Reviews [TRRs], Production Readiness Reviews [PRRs], etc.). I-Agile contains all the features of an Agile methodology while introducing flexibility to integrate vulnerability scanning and Government technical reviews into the Sprint cycle.
I-Agile uses Scrum, which is a framework that helps teams work together. Scrum describes a set of meetings, tools, and roles that work together to help teams structure and manage their work. We adhere to scrum principals by using Sprints, Sprint planning, Daily standups, Reviews and Retrospectives. We have (somewhat loosely) defined Roles within the Scrum Team: Product Owner, Scrum Leader, and the development team members. Our team is very small, so we don’t necessarily adhere to all of the predefined “scrum” roles. Our team members are required to wear multiple hats.
We use tools that help us work within the Scrum framework. We use a type of Kanban board which includes a Backlog. We break work into Features, User Stories, and Tasks. We select what work can go into each Sprint and adhere to, to the best of our ability, the content of the Sprint as defined during the Sprint planning ceremony. If need be, we re-negotiate the length of the Sprint to accommodate change requests that come in from the product owner during a Sprint. It’s an iterative, incremental process that works well for both maintenance of existing products and new features being developed.
We are less focused on adherence to the 12 Principals of Software Development or strict guidelines of the Agile process than we are to adhering to the spirit of the Manifesto, itself.
With the team we have in place, we are empowered to do our work effectively. We have the authority to collaborate and make strategic product decisions throughout the development process. We also have direct access to our ‘customer’ through planned, weekly backlog meetings or at any time we feel we need to show them something that requires discussion. Having the customer as part of the development team throughout the process is invaluable.
Overall, our I-Agile process has been extremely effective in allowing us to develop quality software that meets (and exceeds) the client’s requirements. If you would like to see firsthand how IDEAMATICS can utilize our I-Agile approach to develop your software and/or systems, please contact us so we can discuss!
