Loading...

Get your agile basics right

The rate of change in today's world is exponential in just about every field. To make optimal use of all the opportunities as they arise, we need to adapt really fast. Hence 'Agile' has become the de-facto methodology, or a way of life.

In this document, we will look at agile software development basics, agile manifesto, values, principles, and various agile methodologies using which agile can be practised. With increasing agile adoption, we will also look at different agile estimation techniques that teams can follow for backlog prioritization. Finally, the power of agile development lies at how these prioritized backlogs are planned using Agile release planning.

Why Agile?

Before delving into Agile to understand what it is, let's look at why it came into being. Agile evolved because of the very nature of software building processes.

Software building processes that cater to different market needs or business requirements are rather complex. The complexity of these processes can be defined along the following dimensions for better understanding:

  1. Certainty of requirements - indicates the extent of certainty of 'WHAT' is being built and 'HOW' likely it is to change
  2. Certainty of technology - indicates the extent of certainty of any approach or technology used to build the software and the way it is built

It is easy to build software applications, if the requirements do not change and there is a clear way to implement them. In such cases, all traditional methodologies work well, as we go with the assumption that requirements are analyzed, frozen, and implemented in sequence to meet a fixed target. But, it is usually a rare scenario!

In reality, requirements for software to be built are unknown, unclear, or keep changing. This makes the Software Building process complex or chaotic, thereby rendering traditional methods difficult to deal with.

Many software projects fail or get scrapped somewhere along the way, not because of the inefficiency of the software building team, or the lack of knowledge or budget alone, but because of the nature of work which includes constant change and uncertainty, leading to greater efforts and higher costs due to rework.

This brought in the need for a new approach to software development that must keep changing and evolving.

What are the challenges with traditional waterfall methodologies?

Traditional Waterfall methodology proceeds with a basic assumption that the solution exists and can be built "right" at the first attempt. The development cycle is carried out in phases, such that earlier phases have to be completed before going to the next phase

In this methodology, investment costs are incurred right from the start and it keeps adding on until the software is delivered and value realized. Industry experts estimate that the time spent between a validated business need and an actual application in production is about three years. This is a long timeframe, during which market dynamics tend to change. This is why many well intended projects end up being cancelled or shelved, and many of those that do get completed, do not meet current market needs, even if they have met the project's original objectives. The objective and the requirement would have undergone a transformation while the project was still being executed. Here are some of the challenges faced in the case of traditional methodologies:

  • High risk of failure
  • Rigid and resistant to change
  • Late realization of value from delivery

Waterfall Vs Agile-value delivery Figure 1: Traditional Vs Agile

What is Agile? | Agile Project Management

Agile is a time-boxed, iterative approach to project management and software development that helps teams deliver software incrementally. Unlike traditional waterfall methodology where teams generally work on a big launch or delivery, an agile team works in small iterations and delivers a potentially shippable increment of the software. Users provide early feedback on this increment and changes are taken up in the upcoming iterations. Thus, Agile Software Development is flexible to changing customer demands, ensuring that the software developed, is relevant to business. Agile also recognizes and acknowledges individuals and teams as key elements of software development and strongly emphasizes on open communication, collaboration, and adaptation among team members. Agile does not prescribe any iteration duration or team size, it simply lays out core values and principles to enable agility.

Agile Manifesto

The Agile Manifesto was written in 2001, describing four key values and 12 core principles that enables teams to become agile and develop faster to deliver high-quality (defect-free), working software of the highest business value in the shortest lead time. All methodologies abide by these values and principles.

Agile Values

The manifesto reads as follows: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • 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, while there is value in the items on the right, we value the items on the left more."

Any Agile methodology applies these four values in different ways, but each value relies on the other to guide the development and deliver high-quality working software.

Let us understand the values in detail:

  1. Individuals and interactions over processes and tools - Giving value to people more than the processes and tools is important, since it is the people who respond to business needs and drive development. If processes or tools drive development, the team is less likely to be responsive. Tools aid communication and collaboration and thus, support the delivery process. For example, a timesheet tracking tool has an objective of tracking an individual's work rather than aiding collaboration, whereas a visual story board brings more transparency and collaboration within the team.
  2. Working software over comprehensive documentation - A few years back, enormous amount of time was spent on product related documentation. Agile does not eliminate documentation, but provides only need-to-know information to the developer, without getting into minute details. Documentation helps in conversations and collaboration rather than simply tracking progress. Here, 'working software' is the only measure of progress.
  3. Customer collaboration over contract negotiation - The Agile Manifesto describes a customer as one who is engaged and collaborates not only at the beginning and end of a development process, but instead throughout the product lifecycle. While Agile methodologies may involve the customer during periodic demos, a project can have an end user as part of its team, attending daily meetings to ensure that development is progressing in the right direction.
  4. Responding to change over following a plan - Traditional software development regarded change as an expense, hence, it was to be avoided. With Agile, shorter iterations for delivery means priorities can be shifted from one iteration to another. As per Agile principles, change always improves a product and provides additional value.

Agile Principles

The following 12 Agile principles form the basis of the Agile Manifesto:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
  4. Business people and developers must work together daily throughout the project
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
  7. Working software is the primary measure of progress
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
  9. Continuous attention to technical excellence and good design enhances agility
  10. Simplicity - the art of maximizing the amount of work not done - is essential
  11. The best architectures, requirements, and designs emerge from self-organizing teams
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Any Agile methodology will follow these values and principles and these can be applied using frameworks and practices that each methodology recommends.

Since the inception of agile, various flavors or methodologies of agile have evolved. The popular agile methodologies include Scrum, Kanban, Extreme Programming (XP), Feature- driven Development (FDD), and Dynamic Systems Development Method (DSDM). These agile methodologies are unique in their respective approach however; they revolve around core agile values and principles. They emphasize and enable incremental iterations and continuous feedback, to deliver customer value and business goals. They all share some core processes in common such as continuous planning, testing, integration and feedback to deliver software faster with better quality. They are all lightweight, easy to implement and adopt when compared to traditional waterfall method. Other important factor that all these agile methods focuses on is encouraging effective team collaboration and faster decision-making.

What is Agile Methodology?

There are various agile methodologies that share the same philosophy, practices, and characteristics. But these methodologies are implemented using their own individual procedures, terminologies, and practices. Here, we have summarized some of the popular Agile methodologies, including Scrum Basics.

Scrum: Agile Methodology

Scrum is a simple light weighted agile project management framework that enables product teams to build products incrementally in an iterative fashion through effective team collaboration. Ken Schwaber and Jeff Sutherland are co-creators of Scrum and continue to contribute significantly to the evolution of Scrum.

Scrum forms the base for many of the other frameworks and hence, it is important for an agile practitioner to understand this methodology. Scrum advocates self-organizing teams working towards a common goal through continuous inspection and adaptation. A potentially shippable increment or minimum viable product at the end of each iteration provides an option for the teams to quickly get feedback from end users and respond accordingly much faster.

The Scrum Methodology is defined by:

  • 5 Scrum Values
  • 3 Roles in the Scrum Team
  • 5 Scrum Activities or Events
  • 4 Scrum Artefacts

Scrum has gained popularity in the software development community. Scrum Methodology has proven to scale across multiple teams of large organization with 900+ people.

Kanban Software Development

Kanban is a popular framework in agile software development. Kanban method is used by software development teams, who need to deliver in a continuous flow and are not tied to a definite schedule. Kanban method was conceptualized from Lean and Just-in-Time manufacturing techniques from the Japanese Automakers who, used Kanban methodology to effectively manage their workloads. Kanban framework for software development helps to visually represent every piece of work or task on a Kanban board, allowing teams to visualize and plan work or task accordingly based on the team's capacity.

Kanban is mainly based on the following 3 core principles:

  • Visualize the workflow (Value Stream) : The visual representation of the development process helps determine the current status of one's tasks.
  • Limit Work in Progress (WIP) : The number of active tasks for every phase is restricted and thus, the team is able to pick work as per its capacity.
  • Continuous measure and improvement of the life cycle : The cycle time of the work items is measured. Teams focus continuously at removing the non-value adding activities and thus, continuously improving the cycle time and throughput.

Extreme Programming (XP)

Extreme Programming founded by Kent Beck, is one of several popular agile methodologies. XP is an agile software development framework that aims to deliver high-quality software quickly and continuously, through recommended engineering best practices. Extreme Programming stresses on customer satisfaction, rapid feedback loops, continuous planning, and continuous testing to deliver working software at regular intervals. XP improves software projects in five essential ways; simplicity, feedback, respect, courage, and communication and twelve practices:

  1. The Planning Game
  2. Small Releases
  3. System Metaphor
  4. Simple Design
  5. Testing
  6. Refactoring
  7. Pair Programming
  8. Collective Code Ownership
  9. Continuous Integration
  10. 40-hour work week
  11. On-site Customer
  12. Coding Standards

XP emphasizes on teamwork and collaboration with all the internal and external stakeholders. Extreme programming helps to plan, estimate, and deliver high priority tasks on an incremental iteration basis.

Feature Driven Development (FDD)

Feature Driven Development (FDD) is an agile software development methodology. FDD is client-centric, architecture-centric and employs short iteration software model. FDD was developed and described by Jeff De Luca, along with Peter Coad and it is designed to be used for large projects and teams. FDD consists of five main activities that are performed iteratively.

  1. Develop an overall model: Client and the development team detail out the domain models and then, progressively merge these models into the overall model.
  2. Build a features list: Information gathered in the first step is used to identify a set of required features. A feature is a small piece of client-valued output. The project is thus divided into features. A feature development should typically not take more than two weeks.
  3. Plan by feature: The features are prioritized and planned for the development; then, teams are selected and assigned the feature sets.
  4. Design by feature: The chief programmer leads the programmers through the feature sets. The chief programmer also chooses features and domain classes for designing. Sequence diagrams and general designs of the features are worked out, followed by a design inspection.
  5. Build by feature: Subsequent to design inspection, the class owners start developing the software to support the design. Once the code is developed, tested, inspected, and approved by the chief programmer, the feature is added to the main build.

Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method (DSDM) is an agile delivery framework, which focuses on full project delivery. DSDM was created in 1994, and it sought to provide more governance and discipline to the Rapid Application Development (RAD) method. Over the years, DSDM agile framework evolved into more generic method for project management and rapid software delivery. DSDM is a simple, extensible framework that covers the entire lifecycle of a project and is based on the best practices for planning, managing, executing, and on-time project, delivering with scalability to address projects of all sizes, belonging to any business sector.

DSDM is based on the following eight principles:

  • Focus on business needs
  • Collaborative and co-operative approach
  • Deliver on time
  • Never compromise on quality
  • Build incrementally from firm foundations
  • Develop iteratively
  • Communicate continuously and clearly
  • Demonstrate control

Core Techniques used in DSDM:

  • Time-boxing
  • MoSCoW Rules (Must have, Should have, Could have, Won't have this time)
  • Prototyping

What are the advantages of agile software development?

  • Reduced risk of failure: Agile methods involve customers and stakeholders at frequent intervals throughout the development process. This allows development teams to obtain continuous feedback and adapt to changing needs of the business. This increases the probability of the software meeting market needs.
  • Reduced time-to-market with predictable delivery: Agile helps in delivering business value by focusing on what is needed immediately. Prioritizing what needs to be delivered helps realize early ROI with every iteration
  • Improved satisfaction of development teams: Agile fosters creation of empowered, self motivated and committed teams with a sense of purpose by providing a working environment based on transparency and trust. This drastically improves the morale of development teams and motivates them to deliver highest business value. They can clearly see the role their contribution plays to achieve the ultimate result.
  • High quality: The objective is always to deliver quality products by testing early and often, making the product more robust and defect free.
  • Collaborative environment for faster delivery: Agile improves team collaboration to clear hurdles and get work done effectively and efficiently.

What is Agile Estimation?

Estimation in Agile is completely different from the traditional waterfall method of estimating. The traditional method uses a bottom-up approach for estimation, where requirements are first detailed out, then tasks to complete those requirements are estimated in hours/days, after which the data is used for project scheduling. Agile on the other hand, uses a top-down approach for estimation, where the feature sets are planned and prioritized based on the current needs. This prioritized set is drilled down to the task level on a Just-in-Time basis, iteratively and collaboratively by involving all the team members at each level.

Top-down Vs Bottom-up

The traditional method for estimation generally takes weeks or months to plan and to schedule the detailed project requirements. Once all the requirements are detailed out and documented, a Gantt chart is produced, depicting all the tasks and requirements to be completed along with each time estimate. Resources are assigned to complete the task at each level, which helps determine the final time and cost for the project. This type of approach is known as bottom-up approach, as all details pertaining to the product development must be defined before project schedule and budget can be estimated.

However, in the current software industry, the use of this bottom-up approach has severe impact and repercussions as market needs are constantly changing at a fast pace. This is further impacted by changes in technologies, development tools, and easier access to knowledge, thus resulting in heavy scope creep or schedule slippage and teams even end up delivering an obsolete product.

The Agile Estimation uses a top-down approach to address this issue, by using the information that is currently available to provide estimates of features that need to be delivered in the next few iterations. As software is delivered iteratively and collaboratively, any change in requirement can be planned and estimated for further iterations. This approach helps teams react faster to the changing market needs.

Agile Estimation Techniques

Agile estimation techniques are collaborative. The entire team participates in the estimation process, to ensure that all perspectives are considered and everyone agrees on the estimate hence, avoiding a blame game for incorrect estimation in the future. Agile estimation techniques are designed to be fast and deliberate to reduce the estimation time. Most Agile estimation techniques use relative units (usually, story points) for estimation, instead of estimating in dollars or days. Here are 7 popular Agile Estimation Techniques.

  • Planning Poker: is a popular Agile estimation technique. The Product Owner details out a set of features to estimate. All participants use numbered planning poker cards with values like 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233 and so on (which is a Fibonacci sequence) to estimate the items. Voting is repeated with discussions in between until all the votes are unanimous. Planning Poker is a consensus-based Agile estimation and planning technique. Planning Poker generally works well to estimate for a relatively lower number of items (2 to 10).
  • T-Shirt Sizes: is a perfect and informal technique for estimating a large backlog of relatively large number of items. Items are categorized into T-shirt sizes: XS, S, M, L, and XL. Usually, the decisions about the size is based on open and mutual collaborative discussions. This technique helps teams to quickly calculate the approximate size of backlogs.
  • Dot Voting: is a super simple and effective technique for estimating a relatively small set of items. This method is usually used as a decision making tool as well as for estimating. Each person gets a small set of dot stickers that are used for selecting and voting for preferred items from a list. The more the dots, the greater the votes. Dot Voting works well for both small and large group.
  • The Bucket System: is used to estimate for a large number of items within small to medium sized teams quickly and effectively, using the same sequence as the Planning Poker technique, where the group or team estimates items by placing them in buckets. In the Bucket System of estimation, the "Divide and Conquer" phase is critical and protects the anonymity of individuals. Thus, the Bucket System is faster, more collaborative, and provides relatively more effective results than Planning Poker estimation technique.
  • Large/ Uncertain/ Small: It is a very fast method of agile estimation technique. The group starts estimating by simply placing the items into three categories: large/ uncertain/ small. After the initial discussion of estimation, a process similar to the "Divide and Conquer" phase in the Bucket System is used to go through the remaining items. The group then assigns the items to these three categories. It works well for smaller groups.
  • Affinity Mapping: is the method used to estimate items that are similar. The team starts grouping the items that are like-sized from small to large. This method is usually a physical activity, executed in a visual way that works best for a small group with a relatively small number of items. Once Affinity Mapping is done, associated numerical point estimation can be assigned.
  • Ordering Method: is the method used to place items in random order on a scale labeled - low to high. Each person participating takes a turn to move one item on the scale. Each move involves changing the position of an item one spot lower or higher, discussing about the item, or passing the turn. Once everyone passes their turn, then the items are ordered. This method helps to get detailed size estimation and works best with small groups having relatively large number of items.

What is Agile Release Planning?

Post estimation of features, the Agile team needs to plan the schedule in which the prioritized features are delivered. Agile Release Planning is the process of planning the set of features or backlogs to be delivered incrementally, based on the business needs, backlog priority, and the team capacity. Planning and Estimation of the backlogs in Agile are based on the Agile team's velocity, which is the number of story points or works that the team can do for a single iteration. Initially, for a new team, velocity is based on assumption, but over iterations, the team's velocity is identified, which is then used to plan how much work the team can deliver in an iteration.

Agile Release Planning is a collaborative effort and involves the Scrum Master, Product Owner, Agile team and stakeholders. Generally, releases are made of short iterations typically ranging between 1 and 4 weeks. For example, in a project where the release is in 2 months and iterations are planned on a weekly basis, the release will consist of 8 iterations.

Iteration Planning

After Release Plan, during the iteration or sprint planning, the team members do a detailed level planning of the committed stories. Iteration Planning takes place on Day 1 of the sprint and generally lasts for 2-4 hours. The team breaks down release backlog or features into detailed tasks and test cases that need to be developed and executed as part of the iteration. It is recommended that tasks are optimally detailed such that each task should not take more than a day. If the tasks are larger, then it is broken down into smaller tasks. This ensures that the progress of the story can be tracked effectively. During the iteration, if the committed work is completed before the timeline, the remaining time is utilized for the next set of high priority features. At the end of each iteration, a potentially shippable software product is delivered.

Iteration Tracking

Managing iteration to ensure it is on track as planned is crucial for success of the iteration. Tracking iteration gives the team a complete view of the iteration, its progress, and summary, status of stories, tasks, tests, and issues. It also tracks the impediments that the team needs to address along with the issues, and the dependencies with other teams that need to be addressed for the successful completion of the iteration. This is visible across the team and inculcates an environment of transparency. Thus, when any individual in the team is facing an impediment, anyone available can pitch in and help clear the impediment, thus clearing up the work in progress as the progress of the iteration is the objective of the team and not just the individual tasks assigned or claimed by each of them.

index