Saturday, October 9, 2021

SKP's Agile Cheatsheet : Important Terminologies #01

Well, I have been on Agile and Its ‘Customized’ Variants ever since 2006. That was when I was actually trained by the Pioneers of the Agile Movement – ‘Thoughtworks’. It was great fun to know Agile, Scrum, TDD, XP, PP, Lean, Kanban, Sprints, Demos and Milestones. Also, It was great to Pair Program with Thoughtworkers.  I was a Senior Software Engineer at Huawei, Bangalore when this had happened.

 


Fig. 0 : A Collaborative Software Development Process, Adaptable to Change

 

Every now and then, in these 15 years – I come across a New Agile or Related Term – Since it is a very Deep and Vast Topic with Variants and Allied Terminologies – I tried to come up with a cheat-sheet to help everyone from a Student/Intern to the CTO to quickly recollect or find out an Agile Term. You will not need to know every term in this list, But I am sure as life goes on and you move across Roles/Jobs/Organizations you are going to come up with these (and more) Agile Terminologies. Some Terms may only be aligned to Agile, as they started to become more mainstream or ingrained into the Development Process, post adoption of Agile.

 

One Set is the Agile Terminologies in terms of the Process – The other is the set of names of Popular Tools, Utilities that are associated with Agile. Now in 2021, I am at about 17 years of Experience – I am sure I will come across even more Agile Terms and I will keep updating this List on my Blog! If you find a startling omission, please do leave a comment and I will make sure that I will add it. If you have any exciting Agile Terms or stories in your work/career related to Agile do leave it in the comments.

 

Acceptance Testing

An acceptance test is a formal description of the behaviour of a software product, generally expressed as an example or a usage scenario. Several different notations and approaches have been proposed for such examples or scenarios. In many cases the aim is that it should be possible to automate the execution of such tests by a software tool, either ad-hoc to the development team or off the shelf. [Type – Software Testing / Product Management]

 

Affinity Diagram

An affinity diagram is a method used to organize many ideas into groups with common themes or relationships. Affinity diagrams are tools for analysing large amounts of data and discovering relationships that allow a design direction to be established based on the associations. [Type – Brainstorming, Agile Process, Sprint Retrospective]


Fig.1 : Real-World Affinity Diagram (Affinity Mapping) from a Sprint Retrospective
(Copyright is with www.kbp.media)

Agile C4Model

C4 Model documents the architecture of a software system, by showing multiple points of view that explain the decomposition of a system into containers and components, the relationship between these elements, and, where appropriate, the relation with its users. The viewpoints are organized according to their hierarchical level:  Context Diagrams, Container Diagrams, Component Diagrams, Code Diagrams. [Type – Agile Modelling, Agile Architecture, System Design]

 

 

Fig.2 : Hierarchical C4 Model for Various Viewpoints of a Software System

( Copyright is with www.c4model.com )

 

 

Agile Unified Process

Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP) developed by Scott Ambler.  It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including Test-Driven Development (TDD), Agile Modeling (AM), Agile Change Management, and Database Refactoring to Improve Productivity. [Type – Agile Variant / Development Process]

 

Anti-Pattern

Antipatterns are common solutions to common problems where the solution is ineffective and may result in undesired consequences.  An antipattern is different from bad practice under certain circumstances. [Type – Patterns in Problem Solving]

 

Architectural Spike

An Architectural Spike is a technical risk-reduction technique popularized by Extreme Programming (XP) where you write just enough code to explore the use of a technology or technique that you're unfamiliar with. [Type – Agile Stories / Prototyping]

 

Burn Down Charts

The team displays, somewhere on a wall of the project room, a large graph relating the quantity of work remaining (on the vertical axis) and the time elapsed since the start of the project (on the horizontal, showing future as well as past). This constitutes an “Information Radiator“, provided it is updated regularly. Two variants exist, depending on whether the amount graphed is for the work remaining in the iteration (“Sprint Burndown”) or more commonly the entire project (“Product Burndown”). [Type – Agile Project Management]

 


Fig.3 : Burn Down vs. Burn Up Charts

( Copyright is with https://publications.axelos.com/ )

 

 

Burn Up Charts

By 2002, the Burndown Chart gained enough popularity among the Scrum community, as well as alternatives such as the “Burnup” which merely inverts the vertical direction, or the more sophisticated “Cumulative Flow Diagram“, which most closely resembles a Burnup but appears to be an Independent Invention. [Type – Agile Project Management]

 

Capacity

Capacity is how much availability the team has for the sprint. This may vary based on team members being on vacation, ill, etc. The team should consider capacity in determining how many product backlog items to plan for a sprint. [Type – Agile Project Management / Agile Estimation]

 

 

Fig.4 : Typical Capacity Calculation ( Copyright is with https://www.targetprocess.com )

 

Constraints

A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements, such as limited development resources or a decision by senior management that restricts the way you develop a system. Constraints can be economic, political, technical, or environmental and pertain to your project resources, schedule, target environment, or to the system itself. . Constraints are documented in a similar manner to business rules and technical requirements.  [Type – Agile Development / Limitations in Development]

 

Continuous Delivery

Continuous Delivery is the ability to get changes of all types—including new features, configuration changes, bug fixes and experiments—into production, or into the hands of users, safely and quickly in a sustainable way. Our goal is to make deployments—whether of a large-scale distributed system, a complex production environment, an embedded system, or an app—predictable, routine affairs that can be performed on demand. We achieve all this by ensuring our code is always in a deployable state, even in the face of teams of thousands of developers making changes daily. We thus eliminate the integration, testing and hardening phases that traditionally followed “dev complete”, as well as code freezes. [Type – Agile Development / Agile Releases]

 

Continuous Deployment

Continuous deployment aims to reduce the time elapsed between writing a line of code and making that code available to users in production. To achieve continuous deployment, the team relies on infrastructure that automates and instruments the various steps leading up to deployment, so that after each integration successfully meeting these release criteria, the live application is updated with new code. [Type – Agile Development / Agile DevOps]

 

Continuous Development

Continuous development, “like agile, began as a software development methodology. Rather than improving software in one large batch, updates are made continuously, piece-by-piece, enabling software code to be delivered to customers as soon as it is completed and tested.Companies that can successfully implement Continuous Development throughout their organization often find dramatic strategic benefits,” as described in the Harvard Business Review. [Type – Agile Development / Agile Releases]

 

Continuous Integration

Continuous Integration is the practice of merging code changes into a shared repository several times a day to release a product version at any moment. This requires an integration procedure which is reproducible and automated. [Type – Agile Development / Agile Change Management]

 

Cumulative Flow Diagram

The Cumulative Flow Diagram (also known as CFD) is one of the most advanced Kanban and Agile analytics charts. It provides a concise visualization of the three most important metrics of your flow: Cycle Time, Throughput, Work in Progress. Its main purpose is to show you how stable your flow is and help you understand where you need to focus on making your process more predictable. It gives you quantitative and qualitative insight into past and existing problems and can visualize massive amounts of data. [Type – Agile Project Management]




Fig.5
: Typical Cumulative Flow Diagram in Agile ( Copyright is with https://www.kanbanize.com )

 

Definition of Done (DoD)

The definition of done is an agreed upon list of the activities deemed necessary to get a product increment, usually represented by a user story, to a done state by the end of a sprint. [Type – Agile Management]

 

Demo

Demo or Sprint Demo or Sprint Review or Agile Demo (Terms with only few Subtle Differences) : [1] An activity of a sprint review where the completed (done) product backlog items are demonstrated with the goal of promoting an information-rich discussion between the Scrum team and other sprint review participants. [2.] A term that is frequently used synonymously to refer to the entire sprint review.  [Type – Agile Development]

 

Disciplined Agile Delivery (DAD)

Disciplined agile delivery (DAD) is the software development portion of the Disciplined Agile Toolkit. DAD enables teams to make simplified process decisions around incremental and iterative solution delivery. DAD builds on the many practices espoused by advocates of Agile Software Development, including ScrumAgile ModelingLean Software Development, and Others. The primary reference for disciplined agile delivery is the book Choose Your WoW! written by Scott Ambler and Mark Lines. [Type – Agile Variant]

 

Dreyfus Model

The Dreyfus Model is based on the idea that different people, no matter their profession, can be divided into 5 categories - from novice to expert. In addition, each category has a specific set of skills and, most importantly, different approaches to solving problems. Newbie (Novice) or Beginner, Advanced Beginner, Competent, Proficient, Expert. It can be used in Agile for Scaling People. [Type – Agile Project Management]

 

Earned Value Management

Earned Value Management (EVM) is a project management technique that measures the technical performance, cost and schedule of a project against planned objectives. The result is a simple set of metrics that provides early warnings of performance issues, allowing for timely and appropriate adjustments. EVM also improves the definition of project scope and provides valuable metrics for communicating progress to stakeholders. To implement EVM, you need to measure some basic metrics like a valuation of planned work, called planned value (PV). Agile EVM is a lightweight and easy to use adaptation of the traditional Earned Value Management technique which provides the benefits of traditional Earned Value Management for Scrum. [Type – Agile Project Management / Agile Analysis]

Fig.6 : Typical S-Cure showing EV, AC, PV, SV, CV in Agile ( Copyright - https://www.mpug.com )

 

Well, Wishing Happy Times with Agile and Wait for Part #2. Parting for Now with a Quote Related to Agile!

 

“Intelligence is the Ability to Adapt to Change.” ~Stephen Hawking

________________________

Sumith Puri is the Chief Java Scientist at Java Hero*, Bangalore, India. Java Hero provides Specialist Java/Java EE Services such as Training, Test Setting, Test Evaluation, Job Interviews, Blogging* & Expert Consultancy.

No comments: