The Lean concept optimizes an organization's system to produce valuable results based on its resources, needs, and alternatives while reducing waste.
Waste could be from building the wrong thing, failure to learn, or practices that impede the process. Because these factors are dynamic in nature, a lean organization evaluates its entire system and continuously fine tunes its processes.
The foundation of Lean is that the reduction of the length of each cycle (i.e., an iteration) leads to an increase in productivity by reducing delays, aids in error detection at an early stage, and consequently reduces the total amount of effort required to finish a task. Lean software principles have been successfully applied to software development.
Kanban literally means a 'signboard' or 'billboard' and it espouses the use of visual aids to assist and track production.
The concept was introduced by Taiichi Ohno considered to be the father of the Toyota Production Systems (TPS). The use of visual aids is effective and has become a common practice.
Examples include task cards, Scrum boards, and Burndown Charts. These methods gained attention due to their practice at Toyota, a leader in process management. Lean Kanban integrates the use of the visualization methods as prescribed by Kanban along with the principles of Lean creating a visual incremental evolutionary process management system.
Extreme Programming (XP), which originated in Chrysler Corporation, gained traction in the 1990's.
XP makes it possible to keep the cost of changing software from rising radically with time. The key attributes of XP include incremental development, flexible scheduling, automated test codes, verbal communication, ever-evolving design, close collaboration, and tying in the long- and short-term drives of all those involved.
XP values communication, feedback, simplicity, and courage. The different roles in the XP approach include customer, developer, tracker, and coach. It prescribes various coding, developer, and business practices as well as events and artifacts to achieve effective and efficient development. XP has been extensively adopted due to its well defined engineering practices.
Crystal methodologies of software development were introduced by Alistair Cockburn in the early 1990s.
Crystal methods are intended to be people-centric, lightweight, and easy to adapt. Because people are primary, the developmental processes and tools are not fixed but are rather adjusted to the specific requirements and characteristics of the project.
The color spectrum is used to decide on the variant for a project. Factors such as comfort, discretionary money, essential money, and life play a vital role in determining the 'weight' of the methodology, which is represented in various colors of the spectrum. The Crystal family is divided into Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond, and Crystal Sapphire.
All Crystal methods have four roles: executive sponsor, lead designer, developers, and experienced users. Crystal Methods recommend various strategies and techniques to achieve agility. A Crystal project cycle consists of chartering, delivery cycle, and wrap-up.
The Dynamic Systems Development Methods (DSDM) framework was initially published in 1995 and is administered by the DSDM Consortium.
DSDM sets quality and effort in terms of cost and time at the outset and adjusts the project deliverables to meet set criteria by prioritizing the deliverables into "Must have", "Should have", "Could have", and "Won't have" categories (using the MoSCoW prioritization technique).
DSDM is a system-oriented method with six distinct phases: Pre-project; Feasibility; Foundations; Exploration and Engineering; Deployment; and Benefit Assessment.
A later version of DSDM known as DSDM Atern, was introduced in 2007, focuses on both prioritization of deliverables and consistent user or customer collaboration. The newest version is inspired by an Arctic Tern, making it a developer-centric software development framework for on-time and in-budget delivery of user valued and quality-controlled project features.
Feature Driven Development (FDD) was introduced by Jeff De Luca in 1997 and operates on the principle of completing a project by breaking it down into small, client-valued functions that can be delivered in less than two weeks time. FDD has two core principles: software development is a human activity and software development is a client-valued functionality.
FDD defines six major roles: Project Manager, Chief Architect, Development Manager, Chief Programmers, Class Owners, and Domain Experts with a number of supporting roles.
The FDD process is iterative and consists of developing an overall model, building a feature list, and then planning, designing, and building by feature.
Sometimes known as Test-First Development, Test Driven Development was introduced by Kent Beck, one of the creators of Extreme Programming (XP).
Test Driven Development is a software development method that involves writing automated test code first and developing the least amount of code necessary to pass that test later.
The entire project is broken down into small, client-valued features that need to be developed in the shortest possible development cycle. Based on clients' requirements and specifications, tests are written. The tests designed in the above stage are used to design and write the production code.
TDD can be categorized into two levels: Acceptance TDD (ATDD) requiring a distinct acceptance test and Developer TDD (DTDD) involving writing a single developer test. TDD has become popular because of the numerous advantages it offers like rapid and reliable results, constant feedback, and reduced debugging time.
Adaptive Software Development (ASD) grew out of the rapid application development work by Jim Highsmith and Sam Bayer.
The highlights of ASD are constant adaptation of processes to the work at hand, provision of solutions to problems surfacing in large projects, and iterative, incremental development with continuous prototyping.
Being a risk-driven and a change-tolerant development approach, ASD believes a plan cannot admit uncertainties and risks as this indicates a flawed and failed plan. ASD is feature-based and target-driven.
The first phase of development in ASD is Speculate (as opposed to Planning) followed by the Collaborate and Learn phases.
Agile Unified Process (AUP) evolved from IBM's Rational Unified Process.
Developed by Scott Ambler, AUP combines industry-tried-and-tested Agile techniques such as Test Driven Development (TDD), Agile Modeling, agile change management, and database refactoring, to deliver a working product of the best quality.
AUP models its processes and techniques on the values of Simplicity, Agility, Customizability, Self organization, Independence of tools, and focus on high-value activities. The AUP principles and values are put into action in the phases of Inception, Elaboration, Construction, and Transition.
Domain-driven design is an Agile development approach meant for handling complex designs with implementation linked to an evolving model.
It was conceptualized by Eric Evans in 2004 and revolves around the design of a core domain. "Domain" is defined as an area of activity to which the user applies a program or functionality. Many such areas are batched and a model is designed.
The model consists of a system of abstractions that can be used to design the overall project and solve the problems related to the batched domains.
The core values of DDD include domain-oriented, model-driven design, ubiquitous language, and a bounded context.
In DDD, ubiquitous language is established and the domain is modeled. Then design, development, and testing follow. Refining and refactoring of the domain model is done until it is satisfactory.
Scrum is an agile process most commonly used for product development, especially software development.
Scrum is a project management framework that is applicable to any project with aggressive deadlines, complex requirements and a degree of uniqueness.
In Scrum, projects move forward via a series of iterations called sprints. Each
sprint is typically two to four weeks long.
The idea behind "Agile" and Scrum in particular is that each sprint must produce value, typically in the form of working software.
I.e. as it is typically difficult to do long range planning as is envisaged in Traditional Project Management, Scrum's goal is to produce valuable products incrementally (in slices); sprint by sprint which pass muster in the "Demonstrate and Validate" process #16.
Click the image above for more information
Click here to see PP (Project
Planning) & PMC (Project Monitoring & Control) at Capability Maturity Level 2.
Find also the CM L2 REQM and CM processes?
Click here to see where PP and PMC are on the PMBOK 6 Dashboard?
What about the CM L3 processes Verification and Validation?
The image above explains the crucial role of
The image above explains the PLAN AND ESTIMATE processes in more
These PLAN AND ESTIMATE steps / processes (often glossed over by scrum teams), if correctly done, sets up the ability to complete the Demonstrate and Validate Sprint process (#16).
This "correct way to Mind the Gap" is how the Product Owner can agree that the sprint was a success and produced / released working software. Remember the "tar pit" analogy. I.e. the tar pit (La Brea tar pits in the USA is a good example) was used by "Frederick Brooks as the analogy to where software projects can, if not carefully managed, get stuck in and die! To proceed carefully across the tar pit and not get lost or stuck we must "Mind the Gap" sprint by sprint.
Minding the Gap thus protects the scrum team!
Remember that Scrum (Agile Project Management), unlike Traditional Project Management has made the many planning steps (in the Planning Process Group of the PMBOK) unnecessary. However, if the process to "Mind the Gap" (Project Planning PP and Project Monitoring and Control PMC) for Scrum presented here is not followed (and working software is not produced), this can be a serious risk to project success!
To ensure more accuracy a "demo deck" should be signed off by the Product Owner after demonstration to signal that the sprint has completed successfully and the GAP minded.
If this (CM L2 PP and PMC processes checkpoint signoff) is not possible then this is a risk. I.e. a note should be made by the Scrum Master in the Sprint Retrospective minutes / or a project log should be produced for audit purposes.
Click the image above to understand why Planning and Estimating is so important and how it fits into the PDCA cycle
in order to achieve stability at Capability Maturity Level 2+.
PMWay is of the opinion that PRINCE2 Agile is a "best and safest way" to run
Capability Maturity Level 3 and above is required to run this well!
The image below, PMWay believes, says what needs to be said about the use of PRINCE2 Agile.
Hover your mouse over the image below.
The project selection matrix from Dr. Robert. K. Wysocki (below) shows one how to
what project method best suites the type of project based on the criteria of clarity or lack of clarity of the
project goal or solution being considered.
Note: While all projects are risky business, agile projects are very risky business!
This 'type of project methodology' decision can also be based on how risk-averse is your organization.
PMWay's recommended approach is using PRINCE2 Agile as the recipe you follow; and PMBOK version 6 for the ingredients. The mandatory use of the PRINCE2 Agile Board (who have the relevant training, experience, ability, agility and power within the organization - to "remove the red beads") is the strategic driver for success for the PRINCE2 Agile method, PMWay (from considerable experience of the method's use in the Public and Private Sector) understands. Success in this regards is the dynamic "tension to produce results" from the empowered board who in turn remove the red beads and empower the project manager and team.
While PRINCE2 Agile is not shown in the diagram below, being a blend of the two, it would straddle across TPM and APM.