Four Facets of Agile – Part 2 (Agile Practices)

In this series of post, I am writing my introspection to the facets that are required to achieve agility in Software Development. Because it requires much more to do than just following the textbook prescribed approach. I grouped these facets into four components –

  1. Agile Values and Principles
  2. Agile Mindset
  3. Agile Practices and
  4. Tools and Technologies

In the part-1 of the post, I discussed about the first two of these facets. In this post let’s deep dive in the Agile Practices.

Agile Practices

Agile manifesto provides guiding values and principles around which various Agile Software Development Frameworks are defined. These frameworks consists a set of practices and processes. Because people are involved at different capacity and competencies, so some Agile methods have also defined roles and responsibilities. These method specific practices vary as per framework specification, but there are many practices that are common. Few of these practices have become quite popular due to their benefits and wider acceptance among Agile communities. These practices are either related to organizational practices with the focus to project management, customer engagement, estimation, planning, requirement management, software engineering and quality assurances.

“Initially project team may start any practice on ad hoc basis but has to gradually evolve and mature over time to become repeated and socially recognized, tacitly or explicitly as norms.”

Though there are many sources on the internet from where details on Agile Practices can be found. You can refer the method-wise comprehensive list of practices at along with the description. Here I am listing only standard practices that have been widely accepted within Agile communities. These practices can be categorized in followings –

  1. Requirement Engineering Practices
  2. Estimation and Planning Practices
  3. Programming Practices
  4. Agile Management Practices

 Agile Practices

Requirement Engineering Practices

  • Product Vision – Product development should not start without defining the product vision appropriately – which should be precise, communicating the intent for which product is being created, aligned to organization strategy. 
  • Evolutionary Requirements – Agile does not mandates availability of entire set of software features before starting with development. However, having Initial Features List which represents the potential requirements of the target products is recommended. This list should be ordered on business values, risk factors and timeliness of availability, which forms the basis of release and iteration planning. Ideally features with high business values and high risk are targeted to be developed in initial iterations.
  • Backlog Grooming – Need to be undertaken regularly by the team to refine the product backlog items in a formal meeting. The team performs the assessment, re-validation, removes irrelevant, elaborate, split to sub-stories, prioritize, and estimate in order to produce relevant, detailed, fine-grained, estimated and prioritized backlog items which can be consumed in a forthcoming iteration. While splitting user stories generally, it’s kept small enough so that they can be completed within an iteration.
  • Story Mapping – Story mapping technique used to maintain and deliver user stories incrementally on completion of an iteration. These user stories are prioritized on business values ensuring release of functionally depended stories in appropriate order within a specific iteration.
  • Definition of Ready – Project should establish user stories readiness criteria under INVEST (Independent, Negotiable, Valuable, Estimable, Small, and Testable) guideline. The team should not start working on user stories until they meet ‘READY-ready’ status which defines the explicit working agreement between Product Owner and rest of the team members in order to avoid rework and task-switching.

Estimation and Planning Practices

  • Relative Estimation – Agile team make use of relative estimation techniques using reference feature and rough time of completion. Features are broken into smaller piece of stories using the Feature Breakdown Structure (FBS) such that it can be easily completed within an iteration. Team can estimate features using either the Units (Story points, Gummi Bears, Foot-Pounds, and Nebulous Units of Time) or Ideal Times. It should be the entire team who should be doing the estimation based on single reference and average velocity.
  • Collaborative Planning – Customers, team and management should get involved in planning together the software releases. Developers should be willing, management should trust and support; renouncing the command and controls. There should be transparency with customer in terms of plans and works.
  • Multi-level Adaptive Planning – Management and team should commit to continuous planning at multiple levels, revise taking feedbacks from customer and stakeholders. The next iterations are planned adapting the customer feedbacks obtained from previous iterations.
  • Iteration Planning – Team should held iteration planning meeting prior to every iterations in order to select sprint backlog and decompose each work-items into tasks planned within the iteration.
  • Release Planning – Release plans have business importance for planning the features that they would like to verify or develop in product. This also help to facilitate planning the inspection / verification of the product released, announce product’s availability in market to end-users and be prepared for market response and requests. Team should be ready for deployment of “Release on demands”.
  • Small Release Cycles – The product releases planned should be frequent and often integrating one or more iteration’s working software to release them for end-users review and feedbacks.
  • Planning Poker/Game – Using the planning poker game is the general approach taken by Agile team to estimate the user stories. Product owner and scrum master participates in meeting for query resolution and facilitation respectively.

Programming Practices

Project team need to follow certain prescribed practices for requirement elicitation, design, coding, testing, and releases. These engineering practices helps to enhance the overall software development process to produce frequent quality deliverables iteratively. Some of the important are listed as below –

  • Code Refactoring – developer should adapt to continuous code refactoring. Test-driven development (TDD) mandates refactoring to continuously develop functionality as well as enhance code quality.
  • Coding Standard – developers should follow the mutually agreed coding standard for both front-end and back-end. Similarly, automation testers should follow a standard for writing test cases and scripts. Usually, the coding standard should define the coding style, guidelines, object-oriented designs, use of design patterns, along with do’s and don’ts etc.
  • Pair Programming – Though this has been controversial but pair programming should be seen from outcome i.e. the quality perspectives. Pairing need not be with developers-to-developers but any two or more skills – developers, testers, analysts etc. The increased code quality, knowledge sharing, parallel peer review, skills enhancement, skills transfer and on the job training are implicit benefits of paired programming.
  • Emergent Design – simplicity should be the main focus of design which should evolve incrementally as the product developed. It’s harder to keep the design simple and scalable such that product increments can be delivered at the end of every fixed duration iteration by introducing newly developed functionalities. Developers can easily be carried away by technologies consideration in respect to scalability, performance, security, concurrency etc.  Simple but incrementally augmented designs are the best approach. Follow ‘the art of what suffices”.

We should follow the Extreme Programming sayings: “You Aren’t Gonna Need It” and adhering to the practice of “No Big Design up Front (BDUF).”

  • Architectural Spikes / Spike Solutions – Team should involve innovation, R&D, Proof-of-concepts (POCs) whenever required in order to ascertain the viability of architectural / solution approach. Appropriate technical backlog items should be included.
  • Domain Driven Design – Ensuring that the application design focus on core business domain logic, complexity using object-oriented (OOAD) and model driven development (MDD) concepts.
  • Continuous Reviews – Architecture, design elements and code base must be reviewed continuously by skilled and experienced developers. Standard practices like self-reviews, peer-reviews, review check-lists are the result of continuous reviews practices. Code reviews can also be automated to large extents using plenty of available tools.
  • Continuous Integration – It’s very critical to continuously integrate and build the source code in order to ensure that code written by different developers does not break. Use of effective continuous integration minimizes the efforts and time required to integrate the code which helps to produce quicker deliverables. The common practice of CIs are used in conjunction with configuration management, build automation, automated test execution and build exception management etc. It’s not necessary that every team follow all of these listed, rather it depends on team and organization’s Agile maturity. There are many different fragmented tools and approach to achieve CI.
  • Configuration Management – This practice is used in conjunction with continuous integration, which  uses suitable configuration management, to establish control and rules to handles files checkin/out, versioning, branching rules etc.
  • Build Automation – Automating the compilation of source code and automated reviews in order to produced software package consisting of installers, database scripts, dependent files/components etc. and handling build errors with exception management frameworks. Some of the concepts and practice around the build automation are – Ten-Minute Builds, Daily Builds.
  • Continuous Agile Testing – Testing should start early writing unit tests while coding and should be performed often repetitively  with maximum test coverage to ensure product quality. Test Driven Development (TDD) is the widely used Agile Testing practice. Whenever and wherever possible testing should be automated in order to achieve higher test coverage, speed and repetitiveness. Automation also helps to avoid any manual testing errors, overall cost reduction, higher quality of deliverables and reduce human dependencies.

“Test early, test often and automate tests.”

  • Automated Agile Testing – Inspired by the concepts of Test-First Development and Continuous Testing, advanced testing practices like – Acceptance Test Driven Development (ATDD) also known as Story Test Driven Development (SDD) and Behavior Driven Development (BDD) are inspired by Continuous Testing, which are achieved via test automation using various tools available. Many forms of Agile Testing are undertaken – such as Unit Testing, Smoke or Build Verification Testing, Integration Testing, System or Functional Testing, Exploratory Testing.
  • Definition of Done – Each user stories are marked completed only if it meets the criteria defined for ‘DONE-Done’ status.
  • Continuous Deployment – Project should follow iterative and incremental delivery and deployment approach. The application deployment process should be automated to minimize lead time and efforts required as well as reduce human errors and dependencies. The continuous integration can be trigger to deployment into testing or staging environment.

Agile Management Practices

  • Iterative Incremental Development – Iterative and incremental development produces working software adding functionalities usable to users.
  • Fixed & Short Length Iteration – Keeping the iteration duration fixed helps to set cadence synchronizing various events, scheduled development, testing and releases. Also iteration length should be kept shorter (ideal average is two weeks) duration maximizes the feedback loops and further course correction at the same time provides ample time within a given iteration.
  • Daily Scrum Meetings – Daily team events sharing progress and impediments, usually time-boxed and entire team participation. Also known as Daily Stand-up or Daily Scrum.
  • Information Radiators – Task Board and Kanban Board are recommended for use, Big Visible Charts (Sprint Burn down/up and Release Burn Down) should be promptly displayed on information radiators.
  • Velocity & Software Metrics – Velocity and other software metrics should be calculated and analyzed for each iterations. These metrics become the base for further iterative planning, taking appropriate control and improvement measures.
  • Retrospectives – Meeting should be held regularly to improve process and product taking feedbacks and contributions from all stakeholders, team members etc.
  • Reflection Workshop / Iteration Review – Post iteration product review meetings should be organized without fail order to demo/review the integrated working software so to obtain the constructive feedbacks, changes, clarifications etc. from end-users.
  • Collective Ownership – Management, project team, product owner, customer and other stakeholders collectively owns the product development.
  • Active Stakeholders & Customer – Project team should work along with customer and other project stakeholders in order to succeed with expected quality and valuable product delivery.
  • Cross-functional Team – Project team formation should be cross-functional i.e. representation from development, testing, architecture, functional domain etc.
  • Self-organizing Team – Management should support team for self-organize itself, team member should be willing to work and contribute themselves.
  • Dedicated Product Owner(s) – Dedicated product owner should be assigned to project to work along with team. If full time dedicated product owners cannot be made available then the practice of having proxy product owner with team can deployed.
  • Open Work Area – The open work area facilitates the interactions and communication among team.
  • Collocated Team – As far possible project team and customer representative should be collocated in order to collaborate and communicate easily and effectively.
  • Knowledge Sharing – organization should provide environment and facility to share the knowledge (via Portals, Wikis, Blogs etc.) to communicate project related technical and non-technical information among stakeholders.
  • Continuous Customer Satisfaction Feedback – Organization should provision to obtain continuous feedbacks from the customer during the development process. Customers should be encouraged to continually rethink and realign their requirements with business expectation.


There are numerous other Agile practices that are not listed here. The adaption and implementation of these practices depends on the current maturity level of the organization and project team.

In the beginning, I called these practices as ‘standard’ instead of best practices. Whereas some of these practices need to be practiced without fail, without which attaining true agility becomes very difficult as the underlying intents cannot be achieved optimally.  Even the standards need continuous improvements over the period; because today’s standard and best would obsolete tomorrow.

“If any practice is declared as the best practice, which means that the practice does not need any improvement; that goes against the concept of continuous improvements.”

Team should be selective, slow and steady at the same time incrementally enhance the practice being followed.

In the subsequent post of this series, I will cover on “Tools and Technologies” Agile facets. Stay tuned. Would love if you can share your feedbacks.