1/8 - Agile software development
“If everyone is moving forward together, then success takes care of itself.” Henry Ford
History of agile
The modern history of Agile methodology starts in 2001 with the Agile Manifesto postulated by the leading software developers who needed to create a clear-cut approach to the contemporary challenges offered by the ever-changing environment. With their novel principles offering continuous delivery, short development cycles, high level of communication, and adaptability to the environment, Agile methods have become a breakthrough for software developers.
Unlike traditional methods, they are more flexible and help manage complex software projects using fewer resources. However, Agile methodology history does not start in 2001, it starts earlier. And it is important to understand what practices lay down a foundation for Agile to understand this ideology better.
Software development started with the invention of complex computing machines in the 1950s. Back then it took dozens of years to develop working software for a computer. During this time, new technologies were invented and software did not comply with the new challenges. In the 1990s when computers started to enter the market en masse and were used by the enterprises, this issue remained pressing. According to the IT experts of the time, it took 3 years before an actual application was completed to satisfy the business requirement. Naturally, such a time lag was unacceptable.
Frustration over long time-lags in software development led to a situation when the leading developers had to come up with new practices that could significantly speed up the process. Certain attempts to promote iterative software development were made back in the 1980s, even though this decade was dominated by the traditional Waterfall methods. For instance, James Martin offered the IT community to minimize preparation for the project and start with development as soon as possible. This method was named rapid application development or RAD. Even though RAD was somewhat distant from modern Agile approaches, it guided developers on the right path to creating the history of Agile methodology.
The ideas of iterative development were sporadically voiced throughout the 90s and software developers realized that Waterfall methods are too rigid for many kinds of projects. In the early 1990’s Ken Schwaber and Jeff Sutherland created the scrum method and codified it in 1995 to present it at a conference. The results were published as a paper “SCRUM Software Development Process.”
Then Agile Manifesto appeared, and Agile ideology gained huge popularity among developers. The modern history of Agile development methodology starts at this point. Numerous methods were developed and sharpened by the IT community after thousands of Agile projects since then.
Agile is a Mindset
Ultimately, Agile is a mindset informed by the Agile Manifesto’s values and principles. Those values and principles provide guidance on how to create and respond to change and how to deal with uncertainty.
You could say that the first sentence of the Agile Manifesto encapsulates the whole idea: “We are uncovering better ways of developing software by doing it and helping others do it.”
When you face uncertainty, try something you think might work, get feedback, and adjust accordingly.
Keep the values and principles in mind when you do this. Let your context guide which frameworks, practices, and techniques you use to collaborate with your team and deliver value to your customers.
Agile Principles and Values
The Four Values of The Agile Manifesto
The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile approach to software development. Each Agile methodology applies the four values in different ways, but all of them rely on them to guide the development and delivery of high-quality, working software.
1. Individuals and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.”
Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs.
Communication is an example of the difference between valuing individuals versus processes. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.
2. Working Software Over Comprehensive Documentation
Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each.
The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function.
The Agile Manifesto values documentation, but it values working software more.
3. Customer Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work out the details of delivery, with points along the way where the details may be renegotiated.
Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starting. This meant the customer was involved in the process of development before development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process, making. This makes it far easier for development to meet their needs of the customer.
Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.
4. Responding to Change Over Following a Plan
Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.
With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration. Agile’s view is that changes always improve a project; changes provide additional value.
Perhaps nothing illustrates Agile’s positive approach to change better than the concept of Method Tailoring, defined in An Agile Information Systems Development Method in use as: “A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.” Agile methodologies allow the Agile team to modify the process and make it fit the team rather than the other way around.
Principles
The Twelve Agile Manifesto Principles
The Twelve Principles are the guiding principles for the methodologies that are included under the title “The Agile Movement.” They describe a culture in which change is welcome, and the customer is the focus of the work. They also demonstrate the movement’s intent as described by Alistair Cockburn, one of the signatories to the Agile Manifesto, which is to bring development into alignment with business needs.
The twelve principles of agile development include:
Customer satisfaction through early and continuous software delivery – Customers are happier when they receive working software at regular intervals, rather than waiting extended periods of time between releases.
Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes.
Frequent delivery of working software – Scrum accommodates this principle since the team operates in software sprints or iterations that ensure regular delivery of working software.
Collaboration between the business stakeholders and developers throughout the project – Better decisions are made when the business and technical team are aligned.
Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams.
Enable face-to-face interactions – Communication is more successful when development teams are co-located.
Working software is the primary measure of progress – Delivering functional software to the customer is the ultimate factor that measures progress.
Agile processes to support a consistent development pace –Teams establish a repeatable and maintainable speed at which they can deliver working software, and they repeat it with each release.
Attention to technical detail and design enhances agility – The right skills and good design ensure the team can maintain the pace, constantly improve the product, and sustain change.
Simplicity – Develop just enough to get the job done for right now.
Self-organizing teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power, take ownership, communicate regularly with other team members, and share ideas that deliver quality products.
Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.
The intention of Agile is to align development with business needs, and the success of Agile is apparent. Agile projects are customer-focused and encourage customer guidance and participation. As a result, Agile has grown to be an overarching view of software development throughout the software industry and an industry all by itself.
Agile software development methods
Agile software development methods support a broad range of the software development life cycle. Some methods focus on the practices (e.g., XP, pragmatic programming, agile modeling), while some focus on managing the flow of work (e.g., Scrum, Kanban). Some support activities for requirements specification and development (e.g., FDD), while some seek to cover the full development life cycle
Frameworks :
Adaptive software development
Agile modeling
Agile unified process
Disciplined agile delivery
Extreme programming
Feature-driven development
Lean software development
Lean startup
Kanban
Rapid application development
Scrum
Scrumban
Scaled Agile Framework - SAFe
Philosophy
Compared to traditional software engineering, agile software development mainly targets complex systems and product development with dynamic, non-deterministic and non-linear characteristics. Accurate estimates, stable plans, and predictions are often hard to get in early stages, and confidence in them is likely to be low. Agile practitioners will seek to reduce the leap-of-faith that is needed before any evidence of value can be obtained. Requirements and design are held to be emergent. Big up-front specifications would probably cause a lot of waste in such cases, i.e., are not economically sound. These basic arguments and previous industry experiences, learned from years of successes and failures, have helped shape agile development's favor of adaptive, iterative, and evolutionary development.
Adaptive vs. predictive
Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team has difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method is about what will happen on that date. An adaptive team cannot report exactly what tasks they will do next week, but only which features they plan for next month. When asked about a release six months from now, an adaptive team might be able to report only the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on analysing and planning the future in detail and cater for known risks. In the extremes, a predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive methods rely on effective early phase analysis and if this goes very wrong, the project may have difficulty changing direction. Predictive teams often institute a change control board to ensure they consider only the most valuable changes.
Iterative, incremental, and evolutionary
Most agile development methods break product development work into small increments that minimize the amount of up-front planning and design. Iterations, or sprints, are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a cross-functional team working in all functions: planning, analysis, design, coding, unit testing, and acceptance testing.
At the end of the iteration a working product is demonstrated to stakeholders. This minimizes overall risk and allows the product to adapt to changes quickly. An iteration might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.
Through incremental development products have room to "fail often and early" throughout each iterative phase instead of drastically on a final release date. Multiple iterations might be required to release a product or new features. Working software is the primary measure of progress.
Very short feedback loop and adaptation cycle
A common characteristic in agile software development is the daily stand-up (a daily scrum in Scrum framework).
In a brief session, team members report to each other what they did the previous day toward their team's iteration goal, what they intend to do today toward the goal, and any roadblocks or impediments they can see to the goal.
Quality focus
Specific tools and techniques, such as continuous integration, automated unit testing, pair programming, test-driven development, design patterns, behavior-driven development, domain-driven design, code refactoring and other techniques are often used to improve quality and enhance product development agility. This is predicated on designing and building quality in from the beginning and being able to demonstrate software for customers at any point, or at least at the end of every iteration.
Agile runs on trust
An agile program cannot function without a high level of trust amongst team members. It requires candor to have difficult conversations regarding what's right for the program and the product. Because conversations happen at regular intervals, ideas and concerns are regularly expressed. That means team members also have to be confident in each other's ability (and willingness) to execute on the decisions made during those conversations.
In summary, agile development is a structured and iterative approach to making software. It gives you the ability to respond to change without going off the rails. And that's good news for any program
You might also like :
User Stories Playbook (Pre-Order @50% off)
User Stories and backlog management guide
User Stories and Backlog Management Playbook
Module 1 – Agile Manifesto and Principles
Module 2 – Agile Methodology
Module 3 – User Stories
Module 4 – Epic, Theme and Story evolution
Module 5 – Agile User Stores
Module 6 – The 3-C’s of User Stories
Module 7 – INVEST Criteria for User Stories
Module 8 – User Story Estimation Methods
Module 9 – Exercises and Case Study
This is for you if:
You are a new product manager
You don't know how or where to start
You've started working on the product role but still feel lost about writing stories
You're none of the above but you know someone who is. Gift them!
Thank you for your support, Product Mindset Team.