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.
A Kanban board (a pull system) looks a lot like a task board, but they’re not the same thing. You’ve seen task boards in discussions of Scrum and XP, so it’s easy to look at a
Kanban board and assume it’s basically the same thing.
The purpose of a task board is to make the state of current tasks clear to everybody on a team. Task boards help a team stay on top of the current status of their project. Kanban boards are a little different. They are created to help a team understand how work flows through their process. Because work items are kept at a feature level on a Kanban board, they aren’t the best way to know exactly which task each team member is working on—but they’re great for helping you see how much work is in progress in each state of your process.
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.
While somewhat dated extremeprogramming.org is still an excellent resource on this method. NB: Look at bottom right of each page for the XP [Next Page] Buttons.
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.
Scrum Dashboards (Note: you must be logged on to open this link!)
PMWay is of the opinion that PRINCE2 Agile is a "best and safest way" to run
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 awesome book 'Effective Project Management - Traditional, Agile, Hybrid, Extreme page 66' (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.
Project types slotted into the matrix
Note: I am skeptical of hybrid solutions. Far better to tailor the popular methods (PMBOK, PRINCE2 [or P2 Agile], or SCRUMBOK) as these processes are very well known by millions of qualified experts. If you need to run these lean then tailor the processes but in a way that maintains quality. I.e. why re-invent the wheel? And, by way of an example, from a Scrum perspective snowflake scrum is one of the 7 dysfunctions. 'This situation happens when a team or organization thinks it is "unique," so it has to adapt Scrum to fit its needs. You either do Scrum or you don’t do Scrum. Modifying Scrum does not fix the problems. Modifying Scrum will likely hide your problems … for a little while. When the problems are hidden, it may feel better, but those problems are still there. Ultimately, they will manifest as a lack of business agility and dysfunction.'