It is difficult to imagine an IT company that would not use an agile approach to software development. If the customers of IT companies are to respond dynamically to their own needs, we as an IT company must know how to deliver a piece of working code quickly. The more agile we are, the more satisfied customers will be. One aspect of agility is the ease with which we can react to the changing needs of our customers.
In 2001 the Agile Manifesto was announced. Among the authors of the Manifesto are the creators of Scrum (1996, Jeff Sutherland, Ken Schwaber) and Extreme Programming (XP 1999, Kent Beck, Ward Cunningham, Ron Jeffries).
The manifesto has become a breakthrough moment, so attractive and at the same time necessary approach to software production that cascade methodologies (the so-called waterfall, e.g. Prince) try to implement agility also for themselves.
Why is this happening?
A long and usually very expensive cascade process of software development does not predict a change during the work. Before the software reaches the market, it may take several months and become outdated because the needs of the market may have changed or the rivalry has been faster. The agile approach is to deliver software in the shortest possible time and only a small portion that brings real value. In the agile approach, the product (software) is built incrementally – function by function, starting from the so-called minimum product value (MVP) and then, after each iteration (in Scrum it is e.g. a 2 week sprint), it is expanded with another, tested and working piece of code, increasing the usable value of the software.
Imagine two situations:
– The first is a cascade approach, in which the investor requests software. A few months pass, the software goes to the market and it turns out that half of the functions are unnecessary. The time cannot be turned back and you have to pay for the work of programmers and testers.
– The second is the Agile approach. After just one month of work of a team of programmers and testers, a part of the working software goes to the market. Every next batch of working code appears e.g. every two weeks. If it turns out that the implemented function is unnecessary, the investor pays for only two weeks of work of the team. Every two weeks he can correct his plans based on actual market needs.
Waterfall (first) vs Agile (second). Agile assumes that parts of the tested and working software are delivered in the shortest possible time intervals, while Waterfall wants to deliver the full range of software immediately.
The Agile Manifesto fundamentally changes the investor-contractor and investor-product-contractor approach. The creators of the Manifesto claim that conversation is important, software quality is an essential value, and readiness to change is an essential part of work.
From several years of experience as a Scrum Master, I know that despite the effort that needs to be put into changing our own way of thinking and accepting the client’s perspective (12 principles of the Agile Manifesto), in the end we get his satisfaction. We learn how to approach challenges creatively and create harmonious teams.
Why do we need Agile?
– To ensure that our work is organized in a rapidly changing market of needs.
– To be wisely open to change.
– So that the customer can be sure that we are on his side.
Agile is not only about the ability to adapt to new conditions, but also about how we think and what kind of relations we want to build with the client.
Agile manifesto
We are discovering new methods of programming through practice in programming and supporting others in it. As a result of our work, we have begun to value more:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is to say, the items on the left are valued more than the items on the right.
12 Agile Software Development Principles
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
Agile approach:
Scrum, Extreme Programming, Feature Driven Development, Test Driven Development, Crystal Clear, Continuous Integration, Continuous Delivery, Kanban
