Lean Agile Foundations — An A to Z Guide
What you need to know to be willing for a Lean Digital Transformation at your company
A3 — A structured way for knowledge sharing that enables teams to practice scientific thinking, discovering and learning together on a single sheet of large (A3) paper, often with the use of graphics. A powerful tool for problem-solving, communication and improved decision-making. On the left side, we used to find four sections (and a title) — Background, Current Condition, Goal/Target, and Analysis. This is where the problem and context in which it exists are studied to reach the root cause(s). On the right side, we have three sections — Proposed Countermeasures, Plan and Follow-up (yes, a built in PDCA cycle), where possible solutions are identified, and a plan of action is prepared.
Acceptance Criteria — A set of statements (Test Scenarios), each with a clear pass / fail result, that specify both functional and non-functional requirements, and are applicable at the Epic, Feature, and Story Level that needs to be reached to confirm that the software is working as expected (and agreed) with the Team according to PO (Product Owner) specifications. It should not be confused with DoD (Definition of Done). DoD is common for all the User Stories whereas the Acceptance Criteria is applicable to specific User Story.
Agile is the ability to create and respond to change. It is a way of dealing and ultimately succeeding in a VUCA (Volatility, Uncertainty, Complexity and Ambiguity) world. It’s really about thinking through how you can understand what’s going on in the environment that you’re in today, identify what uncertainty you’re facing, and figure out how you can adapt to that as you go along.
Agile Software Development — An umbrella term for a set of frameworks (Scrum, RAD, XP, FDD, Kanban, DA, etc) and practices (pair programming, code review, TDD, and so on) based on the Agile Manifesto and the 12 Principles behind it.
A burndown chart is a graphic representation of how quickly the team is working through a Release or Sprint based on Epics or User Stories. It shows the total effort against the amount of work for each iteration and is also used to predict your team’s likelihood of completing their work in the time available.
Business Agility is the ability of an organisation to adapt quickly to market changes, respond rapidly and flexibly to customer demands, adapt and lead change in a productive and cost-effective way without compromising quality and at last continuously be at a competitive advantage.
Business Value is the net benefit that will be realized by the customer of a project, and can be measured in either monetary or non-monetary terms.
The Cumulative Flow Diagram (CFD) is an analytics tool for Lean management. It provides a concise visualization of important agile metrics like: cycle time, throughput, lead time, work in progress and so on. It provides both quantitative and qualitative insights into both past and existing problems, and helps the understanding of where focus is needed in order to make your process more predictable.
Continuous Improvement is a method to make sure that your processes, methods, and practices are as efficient, accurate, and effective as possible. Basically aimed to reduce waste and improve whatever you need. No matter what you are doing, there’s always room to improve. Continuous Improvement is based on Lean, Kaizen, PDCA, Six Sigma, or DMAIC principles and forms a key part of both of those practices.
Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time. It is sometimes confused with Continuous Deployment, that means every change goes through the pipeline and automatically gets put into production, resulting in many production deployments every day. Continuous Delivery just means that you are able to do frequent deployments but may choose not to do it, usually due to businesses preferring a slower rate of deployment. In order to do Continuous Deployment you must be doing Continuous Delivery. Further, Continuous Integration usually refers to integrating, building, and testing code within the development environment.
Daily Meeting — As Inspection and Adaptation are at the heart of Agile, each day at the same time, the team meets in a 15-minute time-boxed event for the Team to synchronize activities and create a plan for the next 24 hours. Normally held in front of the task board (or Kanban board) and usually guided by three questions to structure discussion (what I have done yesterday, what I’m going to do today and whether I have any impediment preventing me from going ahead with it.
Definition of Done (DoD) — A set of conditions, including acceptance criteria, that a software product must satisfy and meet to be accepted by a user, customer, team, or consuming system to ensure it is really Done. It’s used to be like a checklist created by, understood and agreed with everyone in the Team, that includes: unit tests passed, code reviewed, acceptance criteria met, functional tests and non-functional requirements met, and so on. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. DoD is common for all the User Stories whereas the Acceptance Criteria is applicable to specific User Story.
Definition of Ready — Almost like DoD, DOR is a checklist the team makes explicit and visible with criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration. To sum up, a DoR will ensure a story meets all requirements before the Sprint Planning. As a concept, a user story should not be accepted in the Sprint if DoR was not met. DoD is the checklist to ensure Sprint objectives are met at the end of the iteration.
Design Thinking is a human-centered approach to innovation that draws from the designer’s toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success. It’s about embracing simple mindset shifts and tackling problems from a new direction, with a customer centric view, reducing the risk associated with launching new ideas, products, and services, whereas learning and iterating faster.
The term DevOps was formed by combining the words “development” and “operations” and signifies a cultural shift that bridges the gap between development and operation teams. It’s a set of practices that works to automate and integrate the processes between those areas, so they can work together in the entire product lifecycle, from design through the development process to production support. As a result, building, testing, and releasing software faster and more reliably.
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment. Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Digital Transformation is not (only) about technology. It’s a process beginning and ending with the customer to create new — or modify existing — business processes, culture, and customer experiences.
Disciplined Agile is a people-first, learning-oriented hybrid agile approach to IT solution delivery. Its risk-value delivery lifecycle, goal-driven, and enterprise awareness approach aims to describe how to effectively combine strategies from Scrum, XP, Kanban, SAFe, and others practices in a tailorable and scalable manner.
An Epic is a large user story that cannot be delivered as defined within a single iteration or is large enough that it can be split into smaller user stories.
Gemba literally means “real place” or, as can be found in some literature, “real place”. This term is similar to the expression Genchi Genbutsu (“Go See”), which in turn represents an attitude. So, “going to the gemba” means going to where things really happen and actually seeing what is going on to think of a solution to the problem.
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. A good user story should be: Independent, Negotiable, Valuable, Estimable, Small, Testable.
Literally Kaizen stands for KAI (Change) and ZEN (For the Better). It means continuous improvement. It emcompasses 5 key principles for a successful Continuous Improvement culture: Know your Customer, Let it Flow, Go to Gemba, Empower People and Be Transparent.
Kanban — A visual system for managing work as it moves through a process. It allows visualizing both the workflow (as simple as “To Do,” “In Progress,” “Complete,” or much more complex.) and the actual work passing through that process. The goal of Kanban is to identify potential bottlenecks in your process and fix them so work can flow through it cost-effectively at an optimal speed or throughput (that can be limited by WIP — work in progress). It came from Lean and was adapted for software development.
The Lead Time is the time from the moment when the request was made by a client and placed on a board to when all work on this item is completed and the request was delivered to the client. So it’s the total time the client is waiting for an item to be delivered.
Lean — The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.
Lean Inception is the effective combination of Design Thinking and Lean StartUp to decide the Minimum Viable Product (MVP). It is a collaborative workshop that helps teams to understand, align and plan the building of the lean product.
Lean Software Development is an adaptation to the software development world from lean principles t in order to deliver better, cheaper and faster software. It’s basically the applying seven fundamental “lean” principles to achieve breakthrough quality, savings, speed, and business alignment: Eliminate Waste; Build Quality In; Create Knowledge; Defer Commitment; Deliver Fast; Respect People; and Optimize the Whole.
Large-Scale Scrum (LeSS) is Scrum — applied to many teams working together on one product. it’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible.
Agile Metrics are standards of measurement that help monitor how productive a software team is across the different phases of the SDLC, in an agile context. Burndown Charts (Sprints, Epics, Releases), Velocity, Lead Time, Cycle Time, CFD, Value Delivered, Throughput and Blocked Time are good examples of Agile Metrics.
MVP the Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
Nexus is a framework that drives to the heart of scaling, extending Scrum to guide multiple Scrum Teams on how they work together to deliver working software in every Sprint. It shows the journey these teams take as they come together, how they share work between teams, and how they manage and minimize dependencies.
OKR — Objectives and Key Results is a goal system used by many successful companies to create alignment and engagement around measurable goals. Objectives are memorable, inspirational and engaging qualitative descriptions of what you want to achieve. An Objective should motivate and challenge the team. Key Results are a set of metrics that measure your progress towards the Objective. For each Objective, you should have a set of 2 to 5 quantitative and measurable Key Results. If it does not have a number, it is not a Key Result.
PDCA is an improvement cycle based on the scientific method of PLAN: determining goals and proposing needed changes for a process; DO: implementing the change; CHECK: evaluate and measure the results in terms of performance; and ACT: taking appropriate action aiming standardize and stabilize the change or begin the cycle again, depending on the results.
The PDSA Cycle (Plan-Do-Study-Act) is a systematic process for gaining valuable learning and knowledge for the continual improvement of a product, process, or service. Also known as the Deming Wheel, or Deming Cycle. He emphasized the PDSA Cycle, not the PDCA Cycle, with a third step emphasis on Study, not Check . Dr. Deming found that the focus on Check is more about the implementation of a change, with success or failure, followed by needed corrections to the Plan in the event of failure. Deming’s focus was on predicting the results of an improvement effort, studying the actual results, and comparing them to possibly revise the theory. He stressed that the need to develop new knowledge, from learning, is always guided by a theory.
Product Backlog — A single and ordered list of all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases, including the attributes of a description, order, estimate, and value, that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.
In short the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals. The PO is the sole person responsible for managing the Product Backlog.
Product Backlog Refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the PO’s discretion.
A Product Roadmap is a high-level visual summary that maps out the vision and direction of your product offering over time. It communicates the why and what behind what you’re building and is a guiding strategic document as well as a plan for executing the product strategy.
Scaled Agile Framework (SAFe) is a framework that empowers complex organizations to achieve the benefits of Lean-Agile software and systems development at scale. It sustains and drives faster time-to-market; increases productivity and quality; and improves employee’s engagement. It is designed to help businesses continuously and more efficiently deliver value on a regular and predictable schedule.
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is lightweight, simple to understand and difficult to master. Its definition guide consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum.
Scrum of Scrums — A technique to scale Scrum up to large groups (over a dozen people), consisting of dividing the groups into Agile teams of 5–10. Each daily scrum within a sub-team ends by designating one member as “ambassador” to participate in a daily meeting with ambassadors from other teams, called the Scrum of Scrums. The SoS proceeds otherwise as a normal daily meeting, with ambassadors reporting completions, next steps and impediments on behalf of the teams they represent.
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. SMs do this by helping everyone understand Scrum theory, practices, rules, and values. As a servant-leader for the Scrum Team, this person helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. At last, the SM helps everyone change these interactions to maximize the value created by the Scrum Team.
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, usable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. It contains and consists of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.
Sprint Backlog — The set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
Sprint Goal — An objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting.
Sprint Planning — An event in the Scrum framework where the team determines the product backlog items they will work on during that sprint and discusses their initial plan for completing those product backlog items. Once items are defined those product backlog items are called Sprint Backlog.
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
Sprint Retrospective — A timeboxed opportunity for the Scrum Team to inspect how the last Sprint went with regards to people, relationships, process, and tools; identify and order the major items that went well and potential improvements; and, create a plan for implementing improvements to the way the Scrum Team does its work. Occurs after the Sprint Review and prior to the next Sprint Planning.
Test-driven development (TDD) is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring. Its primary goal is specification and not validation. In other words, it’s one way to think through your requirements or design before you write your functional code (implying that TDD is both an important agile requirement and agile design technique). In essence you follow three simple steps repeatedly: Write a test for the next bit of functionality you want to add; Write the functional code until the test passes; Refactor both new and old code to make it well structured. You continue cycling through these three steps, one test at a time, building up the functionality of the system.
In software development and product management, a User Story is an informal, natural language description of one or more features of a software system. A user story is a tool used in Agile software development to capture a description of a software feature from an end-user perspective. A user story describes the type of user, what they want and why. A user story helps to create a simplified description of a requirement.
User Experience (UX) deals with people interacting with your product and the experience they receive from that interaction. UX is measured with metrics like: success rate, error rate, abandonment rate, time to complete tasks, and (since we deal in digital) clicks to completion. Customer Experience (CX), in contrast, encompasses all the interactions a person has with your brand. It might be measured in: overall experience, likelihood to continue use, and likelihood to recommend to others. In essence, UX is part of a broader CX, but CX contains some aspects outside of a product that UX does not.
Value Stream — All of the actions, both value-creating and nonvalue-creating, required to bring a product from concept to launch (also known as the development value stream) and from order to delivery (also known as the operational value stream). These include actions to process information from the customer and actions to transform the product on its way to the customer.
Source: https://www.collab.net/sites/default/files/media/sol-vsm/enterprise-value-stream-mgmt.png
Velocity measures the average work a team does during a Sprint. The report, in this case, contains several iterations. The accuracy of the forecast depends on the number of iterations. The more iterations, the more precise the forecast. The unit of measurement is hours or story points. Velocity also determines the ability of a team to work through backlogs. As time passes, velocity tends to evolve. To ensure consistent performance, it’s important to track velocity.
Visual Management is a way to visually communicate expectations, OKRs, standards, roadmaps, production activities, and indicators of production system performance, in a way that requires little or no prior training to interpret, so the status of the system, initiative or value stream can be understood at a glance by everyone involved.
Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (eg., Features, Capabilities, and Epics) to produce maximum economic benefit. It’s calculated by dividing the Cost of Delay by the duration. Jobs that can deliver the most value (or CoD) in the shortest duration are selected first for implementation.
WIP stands for Work In Progress. It’s the number of task items a team is currently working on and frames the capacity of your team’s workflow at any moment. Limiting work in progress is a cornerstone and fundamental concept in Kanban. It allows you to manage your process in a way that creates a smooth workflow and prevents bottlenecks.
References
Access from July 28, 2020 till August 24, 2020
Agile, Scaled Agile and Scrum
https://www.leadingagile.com/2014/09/acceptance-criteria/
https://www.leadingagile.com/2017/02/definition-of-done/
https://www.scrumguides.org/scrum-guide.html
https://www.visual-paradigm.com/scrum/definition-of-done-vs-acceptance-criteria/
https://www.leanagilecouncil.org/definition-of-ready-dor-and-definition-done-dod-in-scrum/
https://www.agilealliance.org/agile101/agile-glossary/
https://less.works/less/framework/introduction#LeSS
http://agilemanifesto.org/
https://www.projectmanager.com/blog/burndown-chart-what-is-it
https://www.atlassian.com/agile/tutorials/burndown-charts
https://kanbanize.com/kanban-resources/kanban-analytics/cumulative-flow-diagram
https://www.pmi.org/disciplined-agile/process/introduction-to-dad
https://disciplinedagileconsortium.org/disciplined-agile-faq
https://medium.com/@plutora/15-agile-metrics-that-actually-matter-32e4b26cfcaa
https://www.scrum.org/resources/scaling-scrum
https://felipecastro.com/en/okr/what-is-okr/
http://agiledata.org/essays/tdd.html
https://martinfowler.com/bliki/TestDrivenDevelopment.html
https://www.visual-paradigm.com/guide/agile-software-development/what-is-user-story/
https://www.scaledagileframework.com/wsjf/
Business
https://www.pmi.org/learning/library/delivering-business-value-9378
https://www.agilebusiness.org/page/WhatisBusinessAgility
https://designthinking.ideo.com/
https://www.ideou.com/blogs/inspiration/what-is-design-thinking
https://www.salesforce.com/products/platform/what-is-digital-transformation/
https://digital.gov/2014/07/07/user-experience-ux-vs-customer-experience-cx-whats-the-dif/
DevOps
https://www.process.st/continuous-improvement/
https://martinfowler.com/bliki/ContinuousDelivery.html
https://www.scaledagileframework.com/continuous-deployment/
https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
https://theagileadmin.com/what-is-devops/
https://www.atlassian.com/devops
Kanban
https://www.lean.org/lexicon/kanban
https://www.atlassian.com/agile/kanban/boards
https://www.agilealliance.org/glossary/kanban/
https://www.digite.com/kanban/what-is-kanban/
https://www.scrum.org/resources/blog/limiting-work-progress-wip-scrum-kanban-what-when-who-how
https://www.kanban.university/#resources
https://kanbanize.com/kanban-resources/getting-started/what-is-wip
https://kanbantool.com/kanban-library/analytics-and-metrics/kanban-definition-of-lead-time-and-cycle-time
Lean
https://planet-lean.com/what-is-a3-thinking/
https://www.lean.org/leanpost/Posting.cfm?LeanPostId=602
https://www.lean.org/lexicon/a3-report
https://www.leanti.com.br/conceitos/12/O-que-e-Gemba-(Genchi-Genbutsu).aspx
https://lean.blog.br/gemba/
https://www.kaizen.com/what-is-kaizen.html
https://www.caroli.org/en/book/lean-inception-how-to-align-people-and-build-the-right-product/
https://agilevelocity.com/7-principles-of-lean-software-development/
https://books.google.com.br/books/about/Lean_Software_Development.html?id=8o1eom6ifIMC&redir_esc=y
https://leanstartup.co/what-is-an-mvp/
https://www.lean.org/lexicon/plan-do-check-act
https://www.lean.org/lexicon/value-stream
https://www.lean.org/lexicon/visual-management
https://www.100pceffective.com/blog/what-is-visual-management/#:~:text=Visual%20management%20is%20a%20way,all%20sorts%20of%20everyday%20scenarios
https://deming.org/explore/pdsa/
