What is Agile?
What is Agile?
Agile designed to add energy, focus, clarity, and transparency to project teams developing complex systems. It enforce a simple set of rules that allows rapid self-organization of software teams to produce systems with evolving architectures.
Agile is an approach of building product or service by empowering and trusting people, acknowledging change as norm, and promoting constant feedback.
–Shuh, Peter (2005). Integrating Agile Development in the Real World.
Agile is a mindset, established through 4 values, grounded by 12 principles and manifested through many different practices.
–Ahmed Sidky
Mechanically applying Agile methods and practices is called “doing Agile”. It also refers to organizations that fail to move beyond the simpler trappings of agility: daily stand up, iterations, maintaining task boards and so on.
The art of learning how to live Agile values and principles is called “being Agile”. Adopting agile requires a change in thinking -it’s not just adopting a set of practices.
A properly implemented Agile method will increase speed of development, align individual and organization objectives, create a culture driven by performance, support shareholder value creation, achieve stable and consistent communication of performance at all levels, and enhance individual development and quality of life.1
- Disciplined project management approach;
- No precise definition, rather a set of Principle & Practices base on Agile Manifesto;
- Business & delivery focus, welcome change;
- Agile is general concept, Scrum and XP are specific implementation of Agile;
- Incremental framework, frequent delivery & continuous feedback loops;
- Empirical process, frequent inspect and adapt cycles that minimize waste;
- Accommodate rapid product changes;
- Frequent releases in short development cycles (iteration, time-boxing etc.);
- Minimum requirement/specification upfront, and test documentation (if at all);
- Self organizing, self managing, cross-functional teams that make and meet commitments; and,
- Engineering practices that rapidly delivery high quality software.
What Agile isn’t?
Although agile has a lot of support, it also has its fair share of critics who believe that it is a fad and does not work. There are websites and blogs from people who insist that a plan-driven, prescriptive approach is more appropriate for delivering projects.
Generally it is a much agreed opinion that when teams are supported by management, and can interact with the customer, they are much more successful than teams who create software using a sequential, prescriptive approach.
Agile isn’t unplanned, the reality is that on adaptive Agile projects we do much more planning than on predictive projects. Agile is planned approach but it is not big design upfront, instead it is spread out much more evenly over the entire project. In fact, planning is an integral part of any agile project. Agile teams are very disciplined and dedicated to planning and to revisiting those plans; because they are involved in the creation of the plans, they are deeply committed. Agile plans follow more of a rolling wave approach using top-down planning, into which we’ll take a deeper look later in this course.
- Agile isn’t traditional methods;
- No big upfront design -BUFD;
- Not an ad-hoc approach;
- Isn’t unplanned;
- Isn’t chaos;
- Isn’t unpredictable.
Why Agile?
Top 3 reasons cited for agile adaptation were to accelerate time to market, more easily manage changing priorities, and to better align IT and business objectives.3
- Accelerate time to market;
- Managing change priorities;
- Better align IT/Business;
- Increase productivity;
- Enhance software quality;
- Project visibility;
- Reduce risk;
- Simplify development process;
- Reduce cost;
- Enhance software maintainability;
- Improve team morale;
- Improve/increase engineering discipline;
- Manage distributed teams.
Agile is documented to help large project cut time to market by 37% and increase productivity by 16%. A research firm, QSM Associated concluded that, as compared to industry averages, the development teams utilizing Agile practices were on average: 4
- 37 percent faster delivering their software to market;
- 16 percent more productive;
- Able to maintain normal defect counts despite significant schedule compression.
Whats Different?
| Traditional Approach | Agile Approach |
| Defined Process: Control and Coordinated | Empirical Process: Inspect and Adapt |
| Plan all in Advance | Refine Plan As You Go |
| Work is assigned or push to the team | Work is stored in queue and team pull the task |
| Work Breakdown Structure | Feature Breakdown Structure |
| Functional Specifications | User Stories |
| Gantt Chart | Release Plan |
| Status Report | Information Radiators/Deliver as you go |
| Learn at the end | Learn Every Iteration |
| Follow the plan | Adapt Everything |
| Manage Task | Manage Teams |
| Conventional project team | Self-organized project teams |
| Avoid change | Embrace change |
| Prescriptive | Adaptive |
The Influencers
In 2001, a group of 17 “lightweight” methodologists met in Snowbird ski resort in the wasatch mountains of Utah, to discuss their approaches to delivering software. This group of people consisted of representatives from eXtreme Programming (XP), Scrum, DSDM, Adaptive Software Development, and others. What emerged was the Agile Software Development Manifesto.
Agile Manifesto -Values5
Principles behind the Agile Manifesto5
- 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.
Traditional Project Phases6
Traditional waterfall approach of handing software projects are divided in to phases, it is:
- Simple, linear and structured approach;
- Great amount of time spend in the Requirement and design phases to reduce later coding and testing cost; and,
- More disciplined in its procedure.
The other site the coin is, in traditional approach, the default response to change is either to avoid or negotiate due to nature of big upfront planning.
- Requirements are not fully understood before the project begins;
- Users know what they want only after they see an initial version of the software;
- Requirements change often during the software construction process; and,
- And new tools and technologies make implementation strategies unpredictable.
Agile Approach
Using simultaneous phases, an Agile team produces deployable software every week. In each iteration, the team analyzes, designs, codes, tests, and deploys a subset of features.
The team gets feedback much more frequently. As a result, the team can easily connect successes and failures to their underlying causes. The amount of unproven work is very small, which allows the team to correct some mistakes on the fly, as when coding reveals a design flaw, or when a customer review reveals that a user interface layout is confusing or ugly
The tight feedback loop also allows Agile teams to refine their plans quickly. It’s much easier for a business to refine a feature idea if they can request it and start to explore a working prototype within a few days. The same principle applies for tests, design, and team policy. Any information you learn in one phase can change the way you think about the rest of the software. If you find a design defect during coding or testing, you can use that knowledge as you continue to analyze requirements and design the system in subsequent iterations.
If you find this article useful, you can check out our PMI-ACP Agile bootcamp.
1. Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams by Jeff Sutherland, Anton Viktorov & Jack Blount http://www.necsi.edu/events/iccs6/papers/ ee6637fd0a1f958002d8f242162b.pdf
2. Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin
3. 7th Annual state of Agile versionone® Agile made easier development survey
4. “The Agile Impact Report” http://media.rallydev.com/events/pdf/Agile-Impact-Report.pdf, accessed on July 11, 2013
5. Manifesto for Agile Software Development, http://www.agilemanifesto.org/
6.Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams by Jeff Sutherland, Anton Viktorov & Jack Blount
