Agile Term	Definition
Agile Application Lifecycle Management	Also called Agile ALM, Agile Application Lifecycle Management is the integrated management platform of the entire software application lifecycle, from planning to the final release. Key components of the platform include the ability to handle change management, workflow, source code management, task management, testing and bug tracking, reporting and analytics.
Agile Practices	Agile practices are procedures that are defined as being highly efficient to productivity, and include the following practices: user stories, cross-functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burnup charts, burndown charts.
Agile Development	Agile development is a way of thinking about software development as expressed in the Agile Manifesto, and acts as an “umbrella” for a group of methodologies. The methodologies are based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile development is a conceptual framework that promotes evolutionary change throughout the entire life cycle of the project and represents a new, more flexible approach to development than the traditional methods that have previously been the norm for software development.
Agile Development Life Cycle	The complete software development process including Agile practices such as user stories, cross-functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burnup charts, burndown charts.
Agile Manifesto	Principles of Agile software development: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more."
Agile Processes	A software development methodology based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams and is collectively regarded as highly efficient to productivity. Specific processes include user stories, cross functional teams, unit testing, refactoring, continuous integration, multi-stage continuous integration, planning poker, burnup charts and burndown charts.
Agile Project Management	The process of planning, organizing, and managing the necessary resources in order to complete project goals while adhering to Agile practices.
Agile SCM Tool	Software Configuration Management tool that supports Agile Software Development Lifecycle requirements differently than requirements involved with traditional software development. These supported features and requirements of Agile SCM include feature-oriented development, sandboxing with private build before check-in, ability to revert to last good working version when integration testing fails, staging hierarchy, ability to revert and retarget changes, refactoring support and support for geographically distributed development.
Agile Software Development	Agile software development is a way of thinking about software development, as expressed in the Agile Manifesto, and acts as an “umbrella” for a group of methodologies. The methodologies are based on process-centric and iterative development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Agile software development is a conceptual framework that promotes evolutionary change throughout the entire life cycle of the project and represents a new, more flexible approach to development than the traditional methods that have been the norm for software development.
Application Development Process Tools	Tools necessary to complete the application development process, such as Application Lifecycle Management tools, Software Configuration Management tools, Build and Release tools, security and defect tracking tools, etc.
Application Lifecycle Management (ALM)	Also called ALM, Application Lifecycle Management is the management platform of the entire software application lifecycle, from planning to the final release. Key components of the platform include the ability to handle change management, workflow, source code management, task management, testing and bug tracking, reporting and analytics.
Backlog	Also knows as "product backlog," the backlog is a prioritized list of user stories and defects in order from most valuable to least valuable for a system. Backlogs include both functional and non-functional user stories as well as technical team-generated stories.
Branching	Branching is the duplication of objects under revision control (such as a source code file, or a directory tree) in such a way that the newly created objects initially have the same content as the original, but can evolve independently of the original. Branching can take two forms, static or dynamic. In static branches, copy and label operations are used to duplicate a given branch. The duplicate then can evolve independently. With dynamic branches, usually implemented in streams, only the label operation is used, to flag the point in time that a stream diverged from its parent stream. Both branching forms support some form of merging, so that code changes made on a branch can be re-integrated into another branch, as is typical in parallel development processes.
Burndown Chart	Representation of the number of hours remaining for completion of a project; usually represented in chart form with points plotted on an x and y axis that map a downward trend of work left to do until burning down to zero.
Burnup Chart	Representation of the number of stories completed; usually represented in chart form with points plotted on an x and y axis that map an upward trend of work completed until reaching 100%.
Change and Configuration Management	Change and Configuration Management (also known as Software Change and Configuration Management or SCCM) combines aspects of both change management and configuration management to control a software development project as it evolves through the software development process. SCCM typically includes all technical aspects of the development process, such as version control, branching and merging. Additionally, SCCM includes change related activities such as issue tracking, document tracking, and process workflows that enable development teams to control the overall process.
Change Control	Process in which changes to a product or system are introduced in a controlled manner with minimal disruptions to services and cost effective solutions involved in implementing the changes.
Change Management	Change Management enables development organizations to control, communicate and respond more effectively to rapidly changing business demands.
Change Packages	Change Packages enable developers and managers to group file changes together into a logical whole and enable release managers to work at the issue or task level, while still providing developers with full access to the underlying file contents of the Change Package. Once created, a Change Package allows users to move, copy, modify, merge or revert the change package.
Collocation	Collocation refers to development teams located and working in the same location. Collocation is usually applied at the cross-functional team level.
Configuration Management	Configuration Management refers to a set of practices around storing, tracking and releasing versions of a software product. Software products that enable development organizations to perform these practices efficiently are also referred to as Configuration Management systems or Configuration Management tools. Configuration Management systems will typically provide users with a variety of features, including but not limited to source code control, issue tracking, and change set management.
Configuration Management Tools	Configuration Management tools are the tools that make possible the practices around storing, tracking and releasing versions of software.
Continuous Integration	Continuous integration, one of the foundational aspects of Agile software development methodologies, is defined by Martin Fowler to be "a fully automated and reproducible build, including testing, that runs many times a day. This allows each developer to integrate daily, thus reducing integration problems." By getting changes into the main line as frequently as possible, preferably daily, and by extending the idea of a nightly build, continuous integration helps reduce integrations problems and identify and resolve problems more quickly.
Cross-Functional Team	Team comprised of members with all functional skills and specialties necessary to complete a project from start to finish.
Distributed Development	Development teams that work on the same project but are located across multiple locations or worksites.
Enterprise Agile	The adoption of specific Agile practices in an organization that works in conjunction with other non-Agile practices. Enterprise Agile is a highly efficient and customized practice for large organizations that have difficulty making a complete transition to Agile, as well as for organizations that already practice efficient development processes.
Epic	A user story which describes a large amount of customer value and needs to be broken down into many smaller user stories.
Feature Driven Development	Feature Driven Development (FDD) is an Agile method for developing software based on an iterative and incremental software development process. The main purpose of FDD is to deliver tangible, working software repeatedly in a timely manner.
Hybrid Processes	Development process that uses both Agile and non-Agile practices in conjunction with each other and is proven highly effective for development teams
Inspecting and Adapting	Agile process where teams evaluate a project by looking, listening to each other’s feedback and ultimately improving the process or changing course.
Iteration	Microcosm of a traditional Systems Development Life Cycle (SDLC,) each of which produces working software. Iterations can be as large as 3 months but are more typically between 1 to 4 weeks. See sprint.
Kanban	Methodology that comes from Lean software development and has three main components: visual system for managing work, limits work in progress, and work is pulled rather than pushed through the system.
Key Agile Principles	See Agile Manifesto.
Lean Software Development	A programming concept that focuses on optimizing efficiencies for development and minimizing waste. According to Mary Poppendieck, 10 rules of Lean programming include: eliminate waste, minimize artifacts, satisfy all stakeholders, deliver as fast as possible, decide as late as possible, decide as low as possible, deploy comprehensive testing, learn by experimentation, measure business impact and optimize across organizations.
Merging	The process of incorporating branches back into the mainline.
Multi-stage Continuous Integration	Agile method allowing for a high degree of integration to occur in parallel while vastly reducing the scope of integration problems. Multi-stage Continuous Integration (CI) is an expansion upon Continuous Integration, where each developer works on his or her own task. As changes are made, CI is done against that team's branch. If CI does not succeed, then that developer (possibly with help from her teammates) fixes the branch. This way when there is a problem, only that team, not the whole development effort is affected.
One Piece Flow	Process in which each developer or development process works on only one piece at a time before pulling code downstream, one piece at a time, to the next process.
Pair Programming	Process in which two developers work together at a single workstation, where one is responsible for typing code and the other for reviewing each line of code as it is typed in.
Parallel Development	Parallel development occurs whenever a software development project requires separate development efforts on related code bases. For example, when a software product is shipped to customers, a product development team may begin working on a new major feature release of the product, while a product maintenance team may work on defect corrections and customer patch releases of the shipped product. Both teams begin work from the same code base, but the code necessarily diverges. Frequently the code bases used in parallel development efforts must be merged at some future date, for example, to ensure that the defect corrections provided by the product maintenance team are integrated into the major release that the product development team is working on.
Planning Poker	A consensus-based technique for estimating; mostly used to estimate effort or relative size of tasks in software development.  Planning Poker is useful for building team cohesion and for fostering self-organizing teams.
Product Backlog	The backlog owned by the Product Owner.
Product Owner	A role originating from Scrum, but has now been widely adopted independently of Scrum. A product owner manages the product backlog, addresses questions that arise during development and signs off on work results. The product owner guides the team with what should be done and when the final product should be shipped. The Scrum team then balances out the product owner’s decisions by deciding how much work should be involved in an individual sprint and estimating the amount of time necessary to complete the task.
Real World Agile	The adoption of specific Agile practices in an organization that works in conjunction with other non-Agile practices. Real World Agile is a highly efficient and customized practice for large organizations that have difficulty make a complete transition to Agile as well as for organizations that already practice efficient development processes.
Refactoring	The practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. Refactoring makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code.
Release Management	Release management comprises a broad set of activities in software development organizations that center on ensuring that software is ready to be released to customers.
Release Plan	A document describing scheduling, activities, resources and responsibilities related to a particular release.
Release Process	The software release process is the final stage in a typical software development effort, where the software product is made available for use. To ready a software product for release, the release process must ensure that all product requirements have been met, usually by executing test suites designed to exercise product functionality and correcting any defects found.
SCM Software	Software Configuration Management software is a software tool that enable organizations to perform the SCM practices of storing, tracking and releasing a product, and typically provide users with a variety of features including source code control, issue tracking and change set management, advanced configuration management, change packages, process management and integrated issue tracking.
SCM Tools	Software Configuration Management tools are tools that enable organizations to perform SCM practices and typically provide users with a variety of features, including source code control, issue tracking and change set management, advanced configuration management, change packages, process management and integrated issue tracking.
Scrum	Agile development project management framework based around sprints and is generally comprised of a Scrum Team, Product Owner and Scrum Master. The framework of Scrum leaves most development decisions up to the self-organizing Scrum team, where decisions are reached as a whole team.
Scrum Master	Person trained to facilitate daily Scrum meetings, remove impediments, oversee the team’s progress through the process and track Scrum team updates.
Self Organizing	A team, usually found in Scrum, that manages itself through various means of communication and reoccurring structured meetings. Self organizing teams solve development issues together as a whole and decide the best solution depending on the various team members.
Software Change and Configuration Management (SCCM)	Software change and configuration management (SCCM – mainframe and distributed) tools implement a set of disciplines used to stabilize, track and control the versions and configurations of a set of software items and also may include development change management, defect tracking, change automation, development release management, integrated test management, integrated build management and other related processes. - Gartner Research
Software Configuration Management (SCM)	Software Configuration Management (SCM) refers to a set of practices around storing, tracking and releasing versions of a software product. Software products that enable development organizations to perform these practices efficiently are also referred to as Software Configuration Management systems or Software Configuration Management tools. Software Configuration Management systems will typically provide users with a variety of features, including but not limited to: source code control, issue tracking and change set management.
Software Development	Development of software in a planned and structured process. See software development process.
Software Development Process	The software development process is the set of coordinated activities performed by engineers, managers and technical writers resulting in the creation of a software product. Various named software development processes are in use today, including Agile, XP, Scrum, Waterfall and Lean.
Source Code Control	Source code control is a common requirement in all modern software development projects that provides mechanisms for checking source code in and out of a central repository. This allows different developers to work on the same project, with reduced fears of lost code or overwritten changes. Source code control also implies a version control system that can manage files through the development lifecycle, keeping track of which changes were made, who made them, when they were made, and why. Finally, source code control also frequently involves the ability to group versioned files as a single release, maintain multiple active releases concurrently (branching), and join different releases (merging).
Source Code Management	Source code management refers broadly to the set of operations required to store, retrieve and version the files used to construct software applications. Development teams rely on source code management to organize the source code files for different releases of software, so that releases can be uniquely identified for testing, packaging and delivery to customers. Failure to do this properly results in poor quality releases and inefficient use of development resources.
Spike	Timeboxed investigation of feasibility via a bare bones implementation, which touches on all aspects of the full implementation.
Sprint	Scrum specific word describing iterations.
Sprint Backlog	Plan for development team to map out implementation of features for an upcoming sprint.
Sprint Planning	A meeting for Scrum Teams, Scrum Masters and Product Owners where the Product Owner describes priority features to the team. The Scrum Team gets enough of an understanding about the tasks discussed that they are able to choose which ones to move from the product backlog to the sprint backlog.
Retrospective	Meeting held at the end of every sprint review to reflect on what went well during the sprint and what can be improved upon during the next sprint. Sprint retrospectives are valued as necessary parts of inspecting and adapting, and allow development teams to plan for future output.
Sprint Review	In the sprint review, teams go over what stories were completed during the iteration and demonstrate those stories for stakeholders and the product owner.
Stand-up	Daily Meetings that are meant to quickly and efficiently resolve obstacles that any team members may be experiencing.
Story Points	Relative scale of effort required by a team to implement a user story.
Task Board	A physical or electronic board representing the state of tasks in a current sprint, often divided into "to do," "in progress" and "done."
Timeboxing	The practice of constraining the amount of time for performing any activity. Examples include iterations, spikes and stand up meetings.
Unit Testing	Tests that exercise small amounts of isolated functionality.
User Stories	Used with Agile methodologies for specifying requirements and presented as an informal statement of the requirement (usually fitting on a 3x5 index card).
Velocity	The velocity of a team is the number of story points associated with stories that are finished over a given period of time, often 1 to 4 weeks. For instance, if the team completed 8 stories that were each 5 points during a four week period, then their velocity is 40 story points every four weeks.
Waterfall	Model of a software development process in which progress flows downwards through phases of conception, initiation, analysis, design, construction, testing and maintenance.
Whole Teams	Team comprised of members with different functional skills and specialties that work together during all phases of development in order to complete a project from start to finish. Also known as a cross-functional team.
XP	"Extreme Programming," one implementation of the Agile methodology that focuses on producing the simplest coding situation for application requirements and includes practices such as pair programming, incremental design and continuous integration.

 

The Case for Project Management

Last Updated on Saturday, 15 October 2011 01:21 Written by Mike Cottmeyer Saturday, 15 October 2011 01:21

 

How far ahead should we plan? I depends on what you are building, when you need to have it done… and if you aren’t going to get done… how soon do you need to know about it. If your goal is to build the highest value features possible, deliver continuously to market, get real time feedback… you might be able to get away with planning a sprint or two out… maybe less. If your goal is to deliver a specific set of predefined features, all of which need to be done by the end of the quarter, you may want to have all three months laid out. It’s not that we wouldn’t inspect and adapt and deal with reality, it’s just that we need to know if our velocity isn’t trending such that everything is going to get done. If we don’t know how we are doing against done, we don’t know what tradeoffs we need to make along the way.

I’ve worked with several clients recently that were trying to operate as if the software they were building was emergent. It wasn’t. They were being asked to deliver a specific outcome, with a pre-defined set of time and cost constraints. For these guys, it was absolutely silly to only plan their backlog two weeks at a pop. They had no idea how they were doing against the expectations of the business. They had no idea if they were on track or not or how they should approach the business to negotiate scope trade-offs. They had no means to determine if their approach was trending toward and acceptable outcome. The reality was that they were going to work really hard, probably deliver a great working product, and still have their stakeholders upset with them.

Having a plan doesn’t mean that we have to have a death march. Having a plan means that we have a baseline to measure against. Some way to determine if we are making the progress necessary to achieve our goals. Remember that line in the Agile Manifesto? We value responding to change over following a plan?  While we value the items on the right, we value the items on the left more? The plan isn’t the problem… it’s failure to respond to change… to deal with reality that is the problem. If I have a fixed time, fixed cost, fixed scope project… I damn well better be delivering incrementally using an agile approach… it’s the only way of knowing if I’ve got a shot in hell of being successful. It’s the only way we can confidently let our stakeholders know if we are on track or not.

Not every team needs a project manager… but I think many could benefit from some really good project management. I’ve been an agile project management guy from the beginning, but I am becoming increasingly convinced that we need to be teaching teams, not just how to self-organize, but how to effectively manage delivery… product or project delivery, I don’t care which. Self organized teams need to have everything necessary to deliver an increment of value… it’s my opinion that everything necessary to deliver an increment of working product includes someone that knows how to manage risk, validate assumptions, communicate with stakeholders, assess progress against the goal, and know when things are off track. That can be the PO, the ScrumMaster, or someone else on the team… again, it doesn’t matter.

What matters is that project management is happening… no matter who does it.

Click here to cancel reply.

Organizational culture powerfully influences a company's performance — or at least we say so. I often hear executives reassure me that projects will get done because "we have an execution culture," or that customers will be well taken care of because "we have a culture where the customer comes first." At the same time, culture is also one of the great rationalizations for managerial shortcomings. Many times I've heard that a project was delayed because "we don't make quick decisions around here," which is the managerial equivalent of "the dog ate my homework."

But the problem with all of these statements — both positive and negative — is that they don't really mean anything. Worse yet, they can't be translated into any kind of action. At best these declarations are vague generalizations; and at worst they are misleading stereotypes.

The truth is that most leaders don't know how to develop a useful picture of their organization's culture, which is why they resort to platitudes. However when managers can better articulate the behavioral patterns that constitute the culture, they can determine which behaviors facilitate results — and which behaviors should be avoided.

For example, a large automotive parts company had just completed a merger, and the senior team — made up of leaders from both firms — struggled with making decisions. They either took too long to decide, or the decisions just didn't stick. To fix this problem, the team asked themselves some simple questions about the decision-making culture: To what extent are decisions currently made by consensus or by the CEO (on a scale of 1-10)? On that same scale, how were decisions made at your heritage company? And on the same scale, where should the decision-making process be in the new company?

Each person on the team answered these questions separately, and a facilitator consolidated them as the basis for a group discussion. When looking at the answers, the team quickly realized that the previous companies had very different decision-making cultures (one was a slow process of building consensus, and the other used open, time-bound debate with final decisions made by the CEO). The team members also had very different expectations for how the process should work. By making these differences concrete and conscious, they were able to have a constructive dialogue that led to ground rules for decision-making.

Any management team can assess its culture by asking these kinds of simple questions across a range of organizational behaviors. For example: To what extent do we reward individual vs. team results? To what extent do we share information broadly or parcel it out narrowly? To what extent do we encourage or discourage risk?

Asking these kinds of questions can smoke out the differences in expectations that people have about the organization. Not everyone experiences culture the same way, so a structured way to discuss those differences can increase alignment and the ability to take collective action. In practical terms, culture is not an intangible cloud that hangs over a company, but an outcome of the way people behave on multiple dimensions. Better understanding of these behavioral patterns — and how each person experiences them — makes it possible to decide whether to continue them or not.

To what extent do you question your organization's culture?