Methods and Frameworks
Scrum a team-based collaborative approach to iterative and incremental development of projects to create a product during small (2-week)cycles called iterations and to increase functionality of the product during each iteration by adding new potentially shippable content. The Scrum team that includes 3 roles: Product Owner, Scrum Master and Scrum Team. Each of the roles has different Scrum tasks and operations to perform.
Kanban is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system.
Lean software development
Lean software development is a set of practices that focus on delivering higher quality software quickly. The seven principles of Lean are eliminating waste, building quality in, defer commitment, delivering fast, focusing on learning, respecting people and seeing the whole.
Scaled Agile Framework (SAFe)
A Framework how to scale agility in large organization. See www.scaledagileframework.com for more information. The creator of SAFe is Dean Leffingwell, a former IBM / Rational employee who was engaged in the development of RUP.
For information on how IBM supports SAFe, see IBM’s Support for the Scaled Agile Framework © (SAFe™).
Disciplined Agile Delivery (DAD)
Large Enterprise Scaled Scrum (LESS)
The inventors of LESS are Craig Larman and Bass Vode. The focus of LESS is on the flow of information through large organizations from the requirements view. LESS recommends structure principles for the organization to optimize a continuous information flow.
Agility Path by scrum.org
The Agility Path program is a continuous improvement approach for organizations that decided to transform toward agility and lean. This approach is supported by an agile assessment to monitor the success of the transformation.
Continuous Integration is a set of software development practices, behaviors and principles for automating and improving the integration and validation of software continuously, so that engineers can detect and fix problems early and deliver quality software.
Continuous stakeholder feedback
Continuous stakeholder feedback is a defining principle of Disciplined Agile Development within IBM. That means that at regular intervals, a team approaches some subset of its stakeholders and demonstrates some aspect of planned or new capabilities of software. An important distinction between continuous stakeholder feedback and more traditional practices of beta test, for example, is the timeframe feedback is sought - and used!
Agile estimation is a practice used by agile software development teams to determine the size of a work item that has been identified by stakeholders. Agile teams do just enough estimating without wasting unnecessary effort on too fine-grained estimates too far in advance when the project is likely to change. Agile teams estimate in terms of size, rather than duration. Size indicates how big the work is, while duration identifies how long you expect for it to take to complete the work. The whole team works together to determine the size of the work. Then, based on a historical view of how much work they can get done within a sprint, they derive the duration. Agile Estimation uses a technique called Planning Poker to allow the team to estimate the size of work needed to complete each user story.
Automated graphical user interface (GUI) testing mimics the way an end-user uses an application. Automated GUI tests increase a test team's efficiency by allowing them to create a suite of tests that is both reusable and robust.
Briefly, pairing is two people working together on one task. One person is the "driver" (with keyboard and mouse) and the other is the "navigator".
Retrospectives are an integral part of the Scrum process and are the mechanism to drive ongoing improvements to their process that will improve the efficiency of the team or the quality of our product. Retrospectives are gathered at the end of every sprint after the sprint review meeting. The team and Scrum Master meet to discuss what went well and what to improve in the next sprint. Retrospective actions are captured in the product backlog.
The phrase technical debt was first introduced by Ward Cunningham in 1992 as a metaphor identifying the affects on a software organization when it chooses a quick and dirty approach that's expedient in the short term but that increases complexity and is more costly in the long term.
Test-driven development (TDD) is a technique where a test case covering a code change or new functionality is written first, then just enough code to make the test pass is implemented. The software is refactored to make it readable and to accommodate changes. The availability of tests before actual development ensures rapid feedback after any change. Practitioners emphasize that test-driven development is a method to design software, and not just a testing method.
A leading cause of project failure is misunderstood requirements. Requirements are often understood from the developer's point of view, but rarely from the customer's or user's viewpoint. Use cases document functional requirements in a way that is understandable by the broad spectrum of people involved with the project.
User stories are brief descriptions of functionality written from the perspective of a stakeholder that are valuable to an end user or customer of the software.