Online Mind Mapping and Brainstorming

Create your own awesome maps

Online Mind Mapping and Brainstorming

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account? Log In

Agile by Mind Map: Agile
5.0 stars - 12 reviews range from 0 to 5

Agile

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight interactions throughout the development cycle. The Agile Manifesto introduced the term in 2001. Since then, the Agile Movement, with all its values, principles, methods, practices, tools, champions and practitioners, philosophies and cultures, has significantly changed the landscape of the modern software engineering and commercial software development in the Internet times.

Scrum

Scrum is an iterative and incremental Agile software development framework for managing software projects and product or application development. Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach". Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication among all team members and disciplines in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need, and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

Kanban

Kanban is a scheduling system for lean and just-in-time production. Kanban is a system to control the logistical chain from a production point of view, and is not an inventory control system. Kanban was developed by Taiichi Ohno, at Toyota, to find a system to improve and maintain a high level of production. Kanban is one method through which JIT is achieved. Kanban became an effective tool in support of running a production system as a whole, and it proved to be an excellent way for promoting improvement. Problem areas were highlighted by reducing the number of kanban in circulation.

Lean software development

Lean manufacturing, lean enterprise, or lean production, often simply, "lean", is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. Working from the perspective of the customer who consumes a product or service, "value" is defined as any action or process that a customer would be willing to pay for. Essentially, lean is centered on preserving value with less work. Lean manufacturing is a management philosophy derived mostly from the Toyota Production System and identified as "lean" only in the 1990s. TPS is renowned for its focus on reduction of the original Toyota seven wastes to improve overall customer value, but there are varying perspectives on how this is best achieved. The steady growth of Toyota, from a small company to the world's largest automaker, has focused attention on how it has achieved this success.

Crystal Methods (Crystal Clear)

Crystal Clear is a member of the Crystal family of methodologies as described by Alistair Cockburn and is considered an example of an agile or lightweight methodology. Crystal Clear can be applied to teams of up to 6 or 8 co-located developers working on systems that are not life-critical. The Crystal family of methodologies focus on efficiency and habitability as components of project safety. Crystal Clear focuses on people, not processes or artifacts. Crystal Clear requires the following properties: ⁕Frequent delivery of usable code to users ⁕Reflective improvement ⁕Osmotic communication preferably by being co-located Crystal Clear additionally includes these optional properties: ⁕Personal safety ⁕Focus ⁕Easy access to expert users ⁕Automated tests, configuration management, and frequent integration

Extreme Programming (XP)

Extreme Programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. Other elements of Extreme Programming include: programming in pairs or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, simplicity and clarity in code, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers. The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. Critics have noted several potential drawbacks, including problems with unstable requirements, no documented compromises of user conflicts, and a lack of an overall design specification or document.

Adaptive Software Development (ASD)

Adaptive Software Development is a software development process that grew out of rapid application development work by Jim Highsmith and Sam Bayer. It embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. Adaptive Software Development replaces the traditional waterfall cycle with a repeating series of speculate, collaborate, and learn cycles. This dynamic cycle provides for continuous learning and adaptation to the emergent state of the project. The characteristics of an ASD life cycle are that it is mission focused, feature based, iterative, timeboxed, risk driven, and change tolerant. The word speculate refers to the paradox of planning – it is more likely to assume that all stakeholders are comparably wrong for certain aspects of the project’s mission, while trying to define it. Collaboration refers to the efforts for balancing the work based on predictable parts of the environment and adapting to the uncertain surrounding mix of changes caused by various factors – technology, requirements, stakeholders, software vendors, etc. The learning cycles, challenging all stakeholders, are based on the short iterations with design, build and testing. During these iterations the knowledge is gathered by making small mistakes based on false assumptions and correcting those mistakes, thus leading to greater experience and eventually mastery in the problem domain.

Agile Unified Process (AUP)

Dynamic Systems Development Method (DSDM)

Dynamic systems development method is an agile project delivery framework, primarily used as a software development method. First released in 1994, DSDM originally sought to provide some discipline to the rapid application development method. In 2007 DSDM became a generic approach to project management and solution delivery. DSDM is an iterative and incremental approach that embraces principles of Agile development, including continuous user/customer involvement. DSDM fixes cost, quality and time at the outset and uses the MoSCoW prioritisation of scope into musts, shoulds, coulds and won't haves to adjust the project deliverable to meet the stated time constraint. DSDM is one of a number of Agile methods for developing software and non-IT solutions, and it forms a part of the Agile Alliance. The most recent version of DSDM, launched in 2007, is called DSDM Atern. The name Atern is a shortening of Arctic Tern - a collaborative bird that can travel vast distances and epitomises many facets of the method which are natural ways of working e.g. prioritisation and collaboration. The previous version of DSDM which is still widely used and is still valid is DSDM 4.2 which is a slightly extended version of DSDM version 4. The extended version contains guidance on how to use DSDM with Extreme Programming.

Feature Driven Development (FDD)

Scrum-ban

Scrum-ban is a software production model based on Scrum and Kanban. Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished user stories and defects are familiar from the Kanban model. Using these methods, the team’s workflow is directed in a way that allows for minimum completion time for each user story or programming error, and on the other hand ensures each team member is constantly employed.[19] To illustrate each stage of work, teams working in the same space often use post-it notes or a large whiteboard.[20] In the case of decentralized teams, stage-illustration software, such as Assembla, ScrumWorks, or JIRA in combination with GreenHopper can be used to visualize each team’s user stories, defects and tasks divided into separate phases. In their simplest, the tasks or usage stories are categorized into the work stages Unstarted Ongoing Completed If desired, though, the teams can add more stages of work (such as “defined”, “designed”, “tested” or “delivered”). These additional phases can be of assistance if a certain part of the work becomes a bottleneck and the limiting values of the unfinished work cannot be raised. A more specific task division also makes it possible for employees to specialize in a certain phase of work.[21] There are no set limiting values for unfinished work. Instead, each team has to define them individually by trial and error; a value too small results in workers standing idle for lack of work, whereas values too high tend to accumulate large amounts of unfinished work, which in turn hinders completion times.[22] A rule of thumb worth bearing in mind is that no team member should have more than two simultaneous selected tasks, and that on the other hand not all team members should have two tasks simultaneously.[21] The major differences between Scrum and Kanban are derived from the fact that, in Scrum work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous. This is visible in work stage tables, which in Scrum are emptied after each sprint. In Kanban all tasks are marked on the same table. Scrum focuses on teams with multifaceted know-how, whereas Kanban makes specialized, functional teams possible.[23] Since Scrum-ban is such a new development model, there is not much reference material. Kanban, on the other hand, has been applied in software development at least by Microsoft and Corbis. Read more

Agile practices

Test-driven development (TDD)

Test-driven development is a software development process that relies on the repetition of a very short development cycle: first the developer writes an automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence. Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right. Programmers also apply the concept to improving and debugging legacy code developed with older techniques.

Acceptance Test Driven Development (ATDD)

Behavior-driven development (BDD)

Backlogs

Sprint backlog

Product backlog, Increment

Cross-functional team

A cross-functional team is a group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments. Typically, it includes employees from all levels of an organization. Members may also come from outside an organization. Cross-functional teams often function as self-directed teams assigned to a specific task which calls for the input and expertise of numerous departments. Assigning a task to a team composed of multi-disciplinary individuals increases the level of creativity and out of the box thinking. Each member offers an alternative perspective to the problem and potential solution to the task. In business today, innovation is a leading competitive advantage and cross-functional teams promote innovation through a creative collaboration process. Members of a cross-functional team must be well versed in multi-tasking as they are simultaneously responsible for their cross-functional team duties as well as their normal day-to-day work tasks. Decision making within a team may depend on consensus, but often is led by a manager/coach/team leader. Leadership can be a significant challenge with cross-functional teams. Leaders are charged with the task of directing team members of various disciplines. They must transform different variations of input into one cohesive final output. Cross-functional teams can be likened to the board of directors of a company. A group of qualified individuals of various backgrounds and disciplines are assembled to collaborate in an efficient manner in order to better the organization or solve a problem.

Continuous integration (CI)

Continuous integration is the practice, in software engineering, of merging all developer working copies with a shared mainline several times a day. It was first named and proposed as part of extreme programming. Its main aim is to prevent integration problems, referred to as "integration hell" in early descriptions of XP. CI can be seen as an intensification of practices of periodic integration advocated by earlier published methods of incremental and iterative software development, such as the Booch method. CI isn't universally accepted as an improvement over frequent integration, so it is important to distinguish between the two as there is disagreement about the virtues of each. CI was originally intended to be used in combination with automated unit tests written through the practices of test-driven development. Initially this was conceived of as running all unit tests and verifying they all passed before committing to the mainline. This helps avoid one developer's work in progress breaking another developer's copy. If necessary, partially complete features can be disabled before committing using feature toggles. Later elaborations of the concept introduced build servers, which automatically run the unit tests periodically or even after every commit and report the results to the developers. The use of build servers had already been practised by some teams outside the XP community. Nowadays, many organisations have adopted CI without adopting all of XP.

Information radiators

Task (or Scrum) board

Kanban board

Burndown chart

Iterative and incremental development (IID)

Iterative and Incremental development is any combination of both iterative design or iterative method and incremental build model for development. The combination is of long standing and has been widely suggested for large development efforts. For example, the 1985 DOD-STD-2167 mentions: "During software development, more than one iteration of the software development cycle may be in progress at the same time." and "This process may be described as an 'evolutionary acquisition' or 'incremental build' approach." The relationship between iterations and increments is determined by the overall software development methodology and software development process. The exact number and nature of the particular incremental builds and what is iterated will be specific to each individual development effort. Iterative and incremental development are essential parts of the Modified waterfall models, Rational Unified Process, Extreme Programming and generally the various agile software development frameworks. It follows a similar process to the plan-do-check-act cycle of business process improvement.

Pair programming

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently. While reviewing, the observer also considers the "strategic" direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the "tactical" aspects of completing the current task, using the observer as a safety net and guide.

Planning poker

Planning poker, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates. Planning poker is a variation of the Wideband Delphi method. It is most commonly used in agile software development, in particular the Scrum and Extreme Programming methodologies. The method was first defined and named by James Grenning in 2002 and later popularized by Mike Cohn in the book Agile Estimating and Planning, whose company trade marked the term.

Refactoring

Code refactoring is a "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior", undertaken in order to improve some of the nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve the maintainability of the source code, as well as a more expressive internal architecture or object model to improve extensibility. By continuously improving the design of code, we make it easier and easier to work with. This is in sharp contrast to what typically happens: little refactoring and a great deal of attention paid to expediently adding new features. If you get into the hygienic habit of refactoring continuously, you'll find that it is easier to extend and maintain code. Typically, refactoring is done by applying a series of standardised basic "micro-refactorings", each of which is a tiny change in a computer program's source code that either preserves the behaviour of the software or at least does not modify its conformance to functional requirements. Many development environments provide automated support for performing the mechanical aspects of these basic refactorings.

Timeboxing

In time management, a timeboxing allocates a fixed time period, called a time box, to each planned activity. Several project management approaches use timeboxing.

Scrum meetings

Sprint planning

Daily scrum

End meetings, Sprint review, Retrospective

Use case

In software and systems engineering, a use case is a list of steps, typically defining interactions between a role and a system, to achieve a goal. The actor can be a human or an external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in Systems Modeling Language or as contractual statements. As an important requirement technique, use cases have been widely used in modern software engineering over the last two decades. Use case driven development is a key characteristic of process models and frameworks like Unified Process, Rational Unified Process, Oracle Unified Method, etc. With its iterative and evolutionary nature, use case is also a good fit for agile development.

User story

In software development and product management, a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function. User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements, though primarily it is the task of a product manager to ensure user stories are captured. User stories are a quick way of handling customer requirements without having to create formalized requirement documents and without performing administrative tasks related to maintaining them. The intention of the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.

Agile Modeling

Agile Modeling is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods. Agile Modeling is a supplement to other agile methodologies, in which Agile Modeling is used to describe how to approach modeling and documentation. Examples of other agile methodologies include Extreme Programming, Disciplined Agile Delivery, and Scrum.

Domain-driven design (DDD)

Domain-driven design is an approach to develop software for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following: ⁕Placing the project's primary focus on the core domain and domain logic. ⁕Basing complex designs on a model of the domain. ⁕Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems. The term was coined by Eric Evans in his book of the same title.

Velocity tracking

Velocity is a capacity planning tool sometimes used in Agile software development. Velocity tracking is the act of measuring said velocity. The velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project.