Agile’s history roots back to the publication of “ The Manifesto for Agile Software Developmen t ” consisting of 12 fundamentals in 2001. Undoubtedly, certain setups of the Agile approach had appeared before that, but only this document systemized and set them out to such extent which was sufficient for use. Year by year, new companies, IT specialists and project managers adhere to the Manifesto. New methods and versions of the agile development system emerge.
What is Agile (flexible) methodology?
Agile is an interactive development model in which software is created incrementally from the outset of a project, in contrast to the cascade models where the code is delivered at the end of the work cycle.
The flexible methodology is based upon breakdown of projects into small operational pieces called user stories. According to priorities, tasks are solved within short two-week cycles (iterations).
The 12 principles which constitute the Agile Methodology may be streamlined into 4 main ideas:
- Priority of people and communication over tools and processes;
- Priority of a functional product over abundant documentation;
- Priority of collaboration with customers over contract confirmation;
- Priority of readiness to changes over following the initial plan.
Methods inherent in Agile:
Scrum
The term of Scrum was borrowed from rugby where this word means the method of team game in the form of three lines built by each rival attempting to grasp the ball. For successful regrasping, not only good physical fitness is essential – each scrumming player should act concertedly with others, with clear understanding of the goal.
This method is successfully used by such companies as Microsoft, Yahoo, Siemens Healthcare. A project manager from Amazon even described a case of Scrum introduction based on the experience acquired.
Since Scrum is a frame for development, each example that follows may differ from the previous one.
Jeff Sutherland, the author or the book “Scrum. The Art Doing Tweice the Work in Half the Time”, distinguished 8 steps to use the methodology:
- Select the product owner who is aware of the project goal and expected outcome.
- Organize a team — up to 10 persons with skills necessary to create an operational product.
- Appoint the Scrum master who will supervise the project workflow and assist the project team in addressing challenges.
- Make up product backlog — for each product requirement, set up priorities on the Agile board. In this process, the product owner’s role is essential, since he collects requests for the product for the backlog team to evaluate them.
- Schedule sprints (iterations) — time fragments to complete definite chains of tasks.
- Arrange daily fifteen-minute meetups — ask each team member 3 questions: what he did yesterday, what he will do today, what impedes task fulfillment.
- Make reviews of operational parts of the product — by involving stakeholders into such reviews.
- Hold retrospectives — problem discussion with search for solutions after each sprint. Implement the resulting modification plan in the following sprint.
Retrospective in Agile
Scrum has 4 key elements:
- Product Backlog — list of requirements for the project
- Sprint Backlog — list of requirements to be fulfilled within the upcoming sprint
- Sprint Goal — sprint purpose
- Sprint Burndown Chart — the diagram which is updated as tasks advance being completed. It facilitates the understanding of dynamics and the team’s advancement level in the project.
eXtreme Programming (XP)
Kent Beck, the developer of this methodology, has created an extreme programming method targeted at addressing volatile software product requirements and improving the quality of development.
It is applicable only in the field of software development, and it is based upon 4 processes:
- coding — according to the team’s common layout standards;
- testing — tests are basically created by programmers before writing a code which will be tested;
- planning — both for the final build and for separate iterations. The latter take place every two weeks on an average.
- audition — of both developers and a customer, to eliminate unclear points and to define requirements and values.
Crystal Methodologies
This family of methodologies developed by Alistair Cockburn, one of the authors of “The Manifesto for Agile Software Development” is little known in some local domains of project management. Cockburn offers to make classification by colors, based on such criterion as the number of persons in a team: 2 (Crystal Clear) to 100 (Crystal Red). The Maroon, Blue and Violet colors are assigned to more large-scale projects.
Crystal projects should conform to 3 basic characteristics:
- swift delivery of the operational code — evolving idea for the iterative model in Agile development.
- improvement through reflexion — a new software version is improved based on the information about the previous one.
- “osmotic” interaction — Alistair’s innovation, a metaphor for communication and information exchange between software developers within one room.
This family of methodologies is described in detail in the book “Crystal Clear: A Human-Powered Methodology for Small Teams” by Alistair.
Dynamic Software Development Method (DSDM)
Not just a single person, yet not even a team, but a consortium of 17 British companies worked on DSDM development. As extreme programming, DSDS is used predominantly to create software.
The end consumer (user) gets a special role in the development process. This core principle is supplemented with the following basic ones:
- frequent releases of the product’s operational versions
- autonomy of developers in decision making
- testing throughout the work cycle.
DSDM is subdivided into versions which are updated as technologies develop and as new software development requirements appear. Currently the last one is DSDM Atern released in 2007, although the previous one (of 2003) is still in service.
At the outset, the team considers feasibility of developing an application and its scope of use. Then the work is divided into three interconnected cycles:
- functional model cycle — creating analytical documents and prototypes.
- design&engineering cycle — bringing a system into operation.
- implementation cycle — system deployment.
Feature Driven Development (FDD)
This methodology emerged even earlier than “The Manifesto for Agile Software Development”.
Although FDD also employs the iteration model of development, it differs from Agile in the following features:
- more attention to up-front modeling
- increased (as compared with Agile) significance of plotting reports and charts
- the methodology is designed for corporate development.
Feature Driven Development consists of the following cyclic phases:
- Creating a general model — vision of the project based on preliminary data.
- Developing a list of properties — similar to product backlog in the Scrum methodology.
- Planning by properties — the complexity of properties is evaluated by each team member.
- For each property — technical design and implementation – the final phase upon completion of which the property merges into the product, and the cycle repeats.
Lean Software Development
Lean Software Development is a set of lean management principles (rather than a methodology) which are targeted at increasing efficiency of the development process and at minimizing costs.
This set includes the following 7 fundamentals:
- eliminating losses — everything that adds no value to the product for the end consumer.
- continuous training — ongoing development of a team enhances possibilities for efficient fulfillment of tasks.
- making decisions as late as possible — priority is given to deliberate solutions which are well-developed and based on acquired knowledge, rather than to spontaneous ones.
- swift delivery — this is basically the core principle of the iterative model.
- team reinforcement — one of the “Manifesto…” fundamentals holds that people and their interactions are more important than processes and tools. A project team is the best guarantee for successful completion of tasks.
- integrity and quality — it is necessary to make an originally high-quality product not to waste time and resources on further testing and elimination of bugs.
- vision of an aggregate picture — a project cannot be broken down into separate parts without understanding the current status of development, as well as the purposes, concept and strategies of the software developed.
Versions of Agile development methodologies
Agile Modeling (AM)
Agile Modeling is a set of values, fundamentals and practices for software modeling.
AM is used as an element in fully-fledged software development methodologies — for instance, in extreme programming or Rapid Application Development.
Agile Modeling has the following fundamental features:
- effective interaction between project stakeholders;
- striving for developing an ultimately simple solution of all possible ones, which will meet all requirements;
- continuous receipt of feedback;
- courage to make decisions and to be responsible for them;
- realizing that you know absolutely everything.
Agile Unified Process (AUP)
AUP is a simplified version of another software development methodology — Rational Unified Process (RUP). Since 2012, it was substituted by Disciplined Agile Delivery (DAD), but AUP is still the case here and there.
Scott Ambler, the author of the methodology, highlighted the following key points in Agile Unified Process:
- Your team knows what is does;
- Simplicity comes first.
- Conformity to the fundamentals of the flexible development methodology.
- Focus on activities valuable for the project.
- Independence in selection of tools.
- Customized AUP configuring for requirements of a specific project.
Agile Data Method (ADM)
ADM is a set of iterative software development methodologies which emphasize forming requirements and solutions in a project through collaboration of different teams. As AUP, this methodology is not self-contained either.
The principle of Agile Data Method is defined by six fundamentals:
- Data — the basis for creation of any application.
- Problems in a project — they may be detected only if the project goal and concept are clearly understood.
- Work groups — apart from the basic team of developers, there are enterprise groups which support other work groups.
- Uniqueness — there is no perfect methodology, so each project requires tools from different methodologies to be combined.
- Team work — joint work is much more efficient than individual activity.
- “Sweet spot” — search for an optimal solution of a problem (“sweet spot”) by avoiding extremities.
Essential Unified Process (EssUP)
It was developed by Ivar Jacobson, a Swedish scientist, to improve Rational Unified Process.
EssUP uses the concept of practice which includes:
- usage scenario — description of a system’s behaviour.
- iteration development — creation of operational pieces of the code in short cycles within a few weeks.
- team practices — targeted at rallying the team and increasing its efficiency.
- procedural practices — for instance, “Think globally, start small” or “Involve stakeholders into business processes”.
In one form or another, all practices are present in the RUP and CMMI methodologies, as well as in the flexible development methodology.
Getting Real (GR)
This is a methodology effective for startups and starting teams, which suggests the maximum use of specific features inherent in small projects and companies, such as mobility, flexibility, search for new solutions, absence of a strict and confused hierarchy etc.
Jason Fried and David Hansson, founders of the 37signals Company (currently Basecamp), determined Getting Real as a system for solving feasible tasks, which is ultimately simple, comprehensive and functional.
GR is a mix of a dozen of agile development tools which are used to minimize the following:
- alternatives
- options and settings
- company structure
- meetings
- promises.
Such extraordinary concept has not gone mainstream, although some of its elements have merged into other methodologies.
OpenUP (OUP)
This is a software development methodology independent of tools and free of strict structure, which provides such practices:
- measuring the team’s speed of operation;
- holding daily meetings and retrospectives upon completion of iterations;
- concept of microsteps and early testing by using checklists;
- methodology of Agile Model Driven Development (AMDD).
These practices are realized based on four principles:
- reconciliation of interests and achieving the common vision in joint work;
- continuous improvement through ongoing feedback;
- focusing on the application’s architecture at early stages to minimize risks;
- maximizing value for the end consumer.
Agile Indicators
Given the diversity of Agile tools, practices, methods and methodologies, we need to choose an instrument which will help us to determine how each of them is effective.
Metrics are used as such instrument.
For most projects, these 4 metric categories will be enough:
- Productivity — it adjoins the Velocity and WIP metrics. The first one will suit not all projects, since the number of tasks performed per iteration is measured, but iterations are not equal. The Work-in-Progress metric defines the limit of tasks in different phases: and the higher it is, the worse it goes;
- Forecasting — the Capacity metric, which consists in determining the number of perfect hours available in the following sprint. Accordingly, it is possible to understand the amount of time available for work, the degree of efficiency in task fulfillment, as well as to plan the number of tasks for a sprint;
- Quality — for instance, the requirements stability index which is calculated by the formula = (Total number of original business requirements + Number of requirements altered by the time given + Number of added requirements + Number of subtracted requirements) / (total number of original requirements). This metric is used to determine the amount of time spent on re-working tasks;
- Values — this metric is computed individually in every case, depending on the project format. For example, in the AirBnb startup, the number of high-quality photos downloaded was chosen as a metric determining the end value of the product for users. As this number was increasing, the number of users was growing in proportion.
The rules applicable to the metrics are the same as those for other Agile tools.
There is no single metric which would be uniquely correct and relevant for your project.
Metrics should be revised in an ongoing manner, outdated ones must be subtracted, and new ones must be added as necessary. It should be comprehensive and available for the whole team without being transformed into a goal in itself. Metrics for the sake of metrics are a bad solution.
Myth Busters: Agile
The popularity of the flexible development methodology played a low-down trick with it, and myths about certain aspects of Agile can be seen even on specialized portals. Let’s sort them out!
Myth No.1: Agile will suit all projects.
This is the most assertive misconception. Just a single Agile method in itself will add no value to the product, nor will it motivate the team.
Myth No.2: Agile disfavors documentation.
The agile development methodology does not disfavor documentation, it denies documentation as a goal in itself. When it comes to selecting documentation as a means of communication, Agile really favors personal communication.
Myth No.3: Agile and planning are incompatible.
This myth is contested by daily planning events with 10-minute standups, as well as by iteration planning taking place every two weeks, sprint meetings etc.
Myth No.4: Agile requires a lot of re-work.
The agile software development methodology provides for re-work in two forms: requirements re-work (users figure out what they really need) and software re-work (teams of developers find improved ways to write and design applications). But this is the case to be also encountered in other methodologies! Moreover, such Agile novelty as the iteration model serves to reduce the negative influence of re-work.
Advantages and disadvantages of Agile in use
Advantages:
- involving stakeholders — the team becomes more capable to understand the customer’s requirements. What is more, early and frequent delivery of software enhances the trust of stakeholders to the project team and makes engagement in the project more profound.
- early and predictable delivery — the iteration-based development model (in short periods lasting for 1 to 6 weeks) provides flexibility and prompts product release.
- focus on business value — collaboration with the customer ensures that the team understands how to make the product ultimately valuable for the consumer.
- continuous quality improvement — testing during each iteration with division of the final build into separate parts of the operational code facilitate improvement and elimination of software errors before the final product is released.
Disadvantages:
- strict requirements for the team and customers — without close interaction between the project team and users, it is impossible to ensure release of a high-quality product with high value. What is more, abundant Agile tools and methods predetermine that the team should be experienced for their proper introduction.
- not suitable for outsource and for projects where participants interact with each other only in an online mode.
- the risk that the final software version will never be released — surprisingly, this disadvantage arises from such Agile advantages as iterative development and ongoing improvement of the product.
- it fails without clear vision of business purposes of the project — since an Agile team is guided by stakeholders, it is impossible to develop a product without a goal and concept clearly figured out.
Applications
Not all project management services or programs will suit for Agile-based project management, because each of them has its specific features.
If your business is a marketing&advertising, design, seo or digital agency, you may use the saas service from Worksection for the whole team to operate on it. So far we are recommended by COXO Digital, Royal ® Advertising and Prozorro.
Here are a couple of life hacks to configure Agile in Worksection:
- configure tags and statuses which are necessary for work in your company.Statuses may be: in progress, checkup, done, re-work needed, critical, features, payment due.Tags often read like this: layout, testing, production, concept, code.
- create project backlog and project spring.
- create tasks and preliminary checklists, sketches etc. in the backlog.
- during meetups, determine sprint tasks and transfer them from the backlog to the sprint.
- use guest access of customers to tasks so that you always have coordinated and relevant feedback on the project.
- tag responsible persons in tasks for each colleague to know his area of responsibility and feel involved in the sprint outcome.
Verdict
Due to the agile software development methodology, small project teams gain maximum efficiency. Agile realizes itself through such other flexible methods as Scrum, XP, Lean etc.
It cannot be deployed hurriedly, by an inexperienced team, within a short period of time,
but when introduced, Agile will improve the interaction between IT and businesses, it will prompt product release into the market, and it will add product value for the end consumer.