Agile is a way of working. It is a business-focussed mindset (based on the Agile principles) coupled with a suite of practical tools (the Agile practices). An Agile way of working enables individuals, teams and organisations to consistently deliver fast, customer-centred outcomes with reduced risk at a lower cost, whilst remaining responsive to changing environments.
The next generation of agile practices are still based on the established Agile principles. The evolution is concerned with improving the regularity, low-risk, high-velocity, and sustainable pace of delivering business value.
Advanced Agile teams that have developed a high level of Agile maturity are often disbanded as their projects are handed over BaU. Agile 2.0 seeks to break this cycle by creating perpetual delivery teams and abandoning the concept of Project versus BaU. A major benefit of this mode of work is that "the team that builds it, supports it", eliminating some of the poor practices where projects are "lobbed over the fence" with minimal or ineffective handovers.
Such a perpetual team can be smaller in size than traditional project teams, but can help minimise change impacts by delivering smaller changes with a more regular frequency at a lower unit cost. Many other advanced Agile techniques can be incorporated into a next-generation Agile team, however such a team must be highly competent at all of the Agile practices before contemplating such a transition.
Human Resource professionals will be required to assist with organisational and job design elements as people’s roles will evolve from temporary project assignments to a more permanent project and support responsibilities within a cross-functional team. Often members of these teams require multiple leaders within a matrix structure to satisfy their functional skills (e.g. as a Procurement expert) as well as the priorities and expectations of a business sponsor or project management office.
In February of 2001, 17 respected, independent thinkers from various software development schools of thought, got together to re-invent software development. Taking it from a heavy, documentation-driven process, they used a principle-based approach to conceive the Agile Software Development Manifesto (http://agilemanifesto.org).
Agiledirect has used this manifesto to uncover better ways of delivering business outcomes by running Agile projects and helping others to do so. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
The original Agile principles (written for software development) are outlined in the Agile Manifesto. Agiledirect has considered the benefits of the original manifesto’s principles and re-imagined them for application in today’s business environment. This is useful for a wide range of business projects and BaU activity.
Agile Principles (Agiledirect adjusted):
Is a visual approach to displaying work and is a significant artefact in an Agile way of working. An Agile Wall is typically applied to an actual piece of vertical real estate (but could also be a portable board or online tool) and represents the work "to do", "in progress", and "done". An individual or team uses the wall as an interactive aid to visualise work. Often, library cards or post-it notes are affixed to the wall and manipulated as required to manage the work.
An Agile Wall typically includes elements such as scope, deliverables, milestones, release plan, story cards, task cards and a RIO (risks, issues and opportunities). To maximise the value of an Agile Wall, a team will conduct stand-up meetings in front of the wall and manage the cards according to the work being carried out.
An Agile Wall can also be referred to as a story wall, storyboard, task wall, Kanban board, task board, or project wall.
Business stakeholders from the extended team are encouraged to "walk the wall" to obtain near real-time status updates on the teams progress, supplementing the need to rely solely on status reports.
A business object that represents something of tangible value. Important Agile artefacts are:
Often, these key artefacts are managed on an Agile Wall.
A collection of
A regular process (part of a team’s cadence) that involves adding new tasks / stories to the backlog, re-prioritising existing work or removing redundant scope. Stakeholders from the extended team (e.g. Sponsor, Product Owner) are encouraged to attend and participate in these sessions to ensure the scope (i.e. the backlog), remains aligned to their desired business objectives
See Business As Usual.
A visual representation of how activity is linked to the generation of desirable outcomes. These desirable outcomes are ideally well quantified or qualified as either tangible or intangible benefits. The team’s project charter should contain this benefits illustration showing how the goals and objectives of the project will link to the benefits. Further mapping can then occur to map specific features or groups of features to particular benefits. This exercise usually creates the fist release plan as each incremental release should deliver or significantly contribute to the stated benefits.
Encompasses a range of different types of visualisations that are …big and visual. The intent of BVCs are to 'radiate' information in such a way that an audience can clearly, quickly and succinctly receive it. The most common example of a BVC is the Agile wall itself. The Agile wall serves as a medium during a stand-up meeting to track the work to do, in progress and done. The Agile wall is also a powerful BVC to actively manage risks, issues and opportunities (RIO).
Any resource or process whose capacity is less than or equal to the demand placed on it, thus constraining the flow of work or information through a process and therefore (usually undesirably) impacting upstream and downstream processes. The core team often calls upon members of the extended team to remove or resolve these bottlenecks. Most take the form of people or roles outside of the project that insist on involvement or approval requests funnelling through them. The agile approach of transparency should be used to bring such people closer to the project and involve them in relevant agile practices to meet their needs, as opposed to completing additional artefacts to suit that purpose. In this sense, the Agile way of working is often seen as a source of disruptive innovation and should be embraced as a catalyst for efficient change.
For those external processes that add value and ensure good governance practices are maintained (e.g. Risk, Fraud, Audit), then every effort should be made to include these processes in the release plan and the team’s cadence.
A visual representation of the amount of work remaining in a Timebox (or Iteration) that decreases cumulatively across time boxes. The burn down chart typically plots a line that reduces in scale based on the work remaining to reach a given goal (on the vertical axis) across time (on the horizontal axis). A more detailed explanation can be found here.
A visual representation of the amount of activity completed in a Time box (iteration) that is cumulatively increases across time boxes, usually the entire project’s duration. This resulting line maps an upward trend from left to right across the chart. Also plotted on the chart is a line representing the amount of work planned (referred to as ‘the scope line’). The distance between the two lines is thus the amount of work remaining. When the two lines meet the project is typically considered complete. The benefit of a burn up chart over a burn down chart is the inclusion of the scope line as it clearly indicates when work has been added or removed from the project. A burn up chart is similar to an earned value chart. A more detailed explanation can be found here.
The typical course of activity that an individual or organisation undertakes to deliver its core products and / or services. This is true even during circumstances that are ‘out of the ordinary’ business operations (e.g. doing disaster management in accordance with a business continuity plan).
BaU also relates to the normal execution of standard operations within an organisation. This is in contrast to the execution of a project that will likely introduce change, although that change may eventually become BaU. BaU processes are managed via already established organisational structures whereas projects are managed by bespoke governance structures such as steering committees extended teams and core teams.
Although BaU activity is typically predictable and cyclical in nature, it may be managed using the principles and practices associated with project management. Some examples of BaU activity that may adopt a project management approach are organisational real estate changes, system upgrades, disaster management and audit management.
Another term sometimes used to describe BaU is 'lights-on' (generally for Information Technology functions). Lights-on usually refers to the work required to keep business systems up and running.
Benefits are the tangible and / or intangible positive changes that an organisation can expect to receive through the achievement of objectives. These objectives can be completed as part of Business as Usual (BAU) or as part of a project. Often, the likelihood of achieving a benefit is used to justify the initiation and resourcing of a project.
The linkage between benefits and the work to be done to achieve the benefit should be shown in a benefits map. The benefits map should trace the relationship between the project’s goals, to its features, through to its minimal marketable features (MMFs). These MMFs, once released, will deliver specific benefits that should be quantified where possible.
An assessment of business benefit should be a key element in any business case and also a key feature to guide the execution of the project plan. In their simplest form, benefits can be defined by evaluating the trade-off between cost and return. This may be measured and quantified financially (e.g. ‘cost-benefit analysis’). For intangible benefits such as improved staff morale, there are often organisational measures that can be used such as ‘% employee engagement’. Consider a range of metrics before defaulting to a completely subjective measure of benefit. In most contemporary business environments, the
Business benefits can be catalogued and defined in 6 key areas:
A document capturing the reason for initiating a project or idea with particular emphasis on the business benefits. This document is generally used to show the value of the project to others and capture compelling arguments as to why a project should go ahead. This business case can be supplemented with a future-dated media release to help portray the vision in stakeholder-centric terms.
The individual (usually referred to by virtue of their role or position) that is the primary custodian to assure achievement of the business benefits to be achieved through the design / enhancement of a product, artefact, team, system or process.
The individual (usually referred to by virtue of their role or position) that is the primary beneficiary of the business benefits that are achieved through the design / enhancement of a product, artefact, team, system or process. This person is the link between the project and the business strategy/goals and is usually a channel to represent the Voice of the customer.
Typically, the Business Representative is a key member of the core team.
The highest priority Agile principle is to, "satisfy the customer through early and continuous delivery." This principle affects a range of Agile activities to ensure delivery of business value is the core reason for completing any task during an Agile project. Business value is often determined by understanding the business benefit that will be achieved through completing the project.
Business value arises in a range of interactions and agile artefacts including:
Refers to the pace a core team can continue to sustain for the duration of a project. Finding a sustainable pace is generally determined after a few iterations are completed and the velocity is tracked and performance via a retrospective process.
A key project role usually structured into the core team. The CM is primarily responsible for managing the ‘people-related’ aspect of a project, particularly if the project is delivering changes that will impact people. NOTE: In Agile, the practice of Change Management is distinctly different from the IT definition of a change management, which refers to the process of tracking variation.
The CM works with the Project Manager, Iteration Manager and Communications Manager to identify business impact, calibrate the appetite for change, manage stakeholder engagement and address resistance. Unfortunately, the value of a CM is typically under-appreciated in business projects.
See Project Charter.
Is a strategy that involves organising information into logical groupings so that it is easier to manage and communicate. Chunking is also a strategy to improve memory retention. Chunking can be used in presentations to make it easy for an audience to understand and remember your messages. Chunking is based on the understanding that an individual's memory is easily overloaded by excessive detail or lack of structured information.
A key role in the core team. Responsible for facilitating the design and delivery of communications. The Communications Manager works closely with the Change Manager to engage stakeholders, understand their needs and manage their expectations using a variety of media.
The people responsible for carrying out the day-to-day work – either as a project team or work group. The core team are typically the 'doers'. Through applying the Agile principles and practices, the core team is responsible for elaborating the scope of the project and making decisions about how the work will get done.
The team is usually made up of a cross-functional group of people with the skills necessary to deliver the planned outcomes. The core team typically consists of the following roles:
The core team can also include:
Using the feedback gained from showcases, retrospectives, steering committee meetings and other communication channels to re-orient activity towards achieving business requirements. The aim is to ensure the day-to-day work remains relevant and cost-effective in achieving the desired outcomes that will deliver the business benefits.
A team comprised of members drawn from different functional areas across the organisation. A cross-functional team can also refer to a group of people with the range of skills relevant to completing the work. A cross-functional team is better equipped to generate wisdom of the crowd than a team of overly similar roles.
The primary beneficiary of the core team's output. Customers may be internal (e.g. CEO) or external (e.g. product consumer). Ideally, the customer is directly involved in informing the work of a core team. If the customer is external, then getting them involved in the core team is not always practical, so the customer’s interests can be represented by the Product Owner, Business Owner and / or Sponsor, or by incorporating the Voice of the Customer using tools such as personas to represent their interests within the project.
The criteria or series of steps that are used to determine when an artefact or work packet is complete. Defining the criteria to determine the DoD should involve the
Team's should adapt the DoD to their specific requirements, however having cards as partially done, and then completing a big deployment each release is not an efficient or Agile approach. When a task is done, it should be ready to deliver to customers (even though the product owner may choose to bundle tasks and features into a release). This delivery should include all required change management, business readiness and approval artefacts.
The criteria or series of steps that are completed to prepare a
"Does a person who will be completing this task have the necessary and sufficient information required to commence work, achieve all of the objectives of the task, and perform all steps as agreed in the team's definition of done?"
Typically a definition of ready includes elaborating a
A tangible artefact that is produced by the core team to satisfy the requirements of a customer and ultimately contribute to achieving business benefits. A deliverable could be a report, a document, a product, a service, server upgrade, a website, etc.
This phase is designed to create a compelling case for change and unite stakeholders behind the project's goals and objectives. A dedicated core team consisting of representatives from all teams that would be involved in the Implementation should be formed to complete the following more detailed work:
Discovery phase activities occur after the Idea work has completed. They seek to understand the problem or opportunity in more detail. Often lean or other assessment methods are used during this phase to quantify the issues and the planned response.
Discovery activities ensure the business understand the benefits and risks of proceeding and moving away from the status quo. This phase also serves as a checkpoint to confirm if the Project Sponsor’s peers and stakeholders are willing to invest.
A dedicated team should be formed for a period of time sufficient to:
At this preliminary level, decide if the costs stack up for a return on investment? If so, proceed to the Design Phase.
A distributed team that has individuals working on the same project but not physically located together. The preferred mode of working with an Agile approach is face-to-face. Projects are encouraged to co-locate their cross-functional teams to minimise the negative affects of distance. Thomas Allen discovered this affect in the 70s (known as the Allen curve) where communications significantly reduced once people were separated by more than 50 metres.
To counter this challenge, teams that cannot be co-located for cost or operational reasons should employ every technique or technology at their disposal to simulate proximity. Always-on Skype ™ TVs are a good low-cost option to create the sense of sharing office space. Live chat or webcam systems are also useful to encourage rich conversations among team members.
Distributed teams operating in different time zones should maximise the overlapping periods of their working days. This usually involves teams starting earlier or finishing later – even an extra hour per day is incredibly useful to maintain the shared contribution to the project's goals.
The process of defining / refining a story or further exploring a matter to foster a better understanding of it. Elaboration requires engaging with the
The process of determining the size, and subsequently, the effort and time required to complete tasks. There are three main contexts where estimation is applied:
People in the extended team play an important role but are not dedicated to the doing the work on a day-to-day basis. Extended team members have a vested interest to support the core team and ensure that the core team members are enabled to get on with the job.
The project manager is responsible for relationship management of the extended team. The extended team typically consists of the following roles:
A succinct description of the key attributes of a desired outcome, deliverable, artefact, product or service. Features are usually determined when the
Features are chunked through the process of elaboration with stakeholders to become a series of tasks that are tracked on the Agile wall. Features should also be solution/system independent as the represent a business or customer oriented features should also be solution/system independent as the represent a business or oriented requirement.
See Agile Wall.
As the name implies, building your way of working upon poor foundations will lead to a very 'fragile' implementation of 'agile'. Small hurdles will become insurmountable and trivial issues will become major impediments. Shane Hastie summarised these well in his Vancouver presentation (2012). If you start to see these issues, there is a very strong chance that your foundations and poor, and Tragile is imminent:
This kind of media release is written during the Discovery and Design phases of a project, but written as if were published on the release or go-live date. The release is never published, however it serves to confirm the scope, benefits, timings and impacts of the project on its stakeholder community.
The Sponsor and Owner should take primary accountability to author this release and keep the content under 500 words. This ensures only the key benefits are highlighted and quantified in terms that stakeholders understand.
The format of a media release answers the question for stakeholders of, "what is in it for me". This is different from the typical format of Project Charters or Business Case documents that are written from a more project-centric perspective, and often require assumed knowledge of the strategic drivers, none of which are relevant to the end users or beneficiaries of the project.
Major organisations like Amazon and the Suncorp Group use this tool to keep the team focussed and ensure scope does not diverge excessively from the planned course without good strategic reasons. If it does, the media release should be re-written to reflect the course correction.
A decision, checkpoint or gateway where an individual or group of stakeholders are required to make determination to proceed ('go') or not ('no-go'). Go / no-go decisions usually occur through a formal, preferably pre-defined, process based on a combination of criteria such as:
No-go decisions may result in a deferral of progression to the next phase (assuming the outstanding criteria can be met in a suitable timeframe) or a cancellation of the next phase.
No-go decisions should not be seen as unsuccessful outcomes, rather using agile principles, the business owner may have received sufficient business value for this particular endeavour and choose to focus their efforts on alternative activities. This kind of business agility and subsequent cost avoidance speaks to some of the core benefits of an Agile approach.
A test designed to determine the user-friendliness of communications. The test question is: "Is this written in such a way that my grandmother would understand it?"
A document, generally no more than 1-2 pages providing information derived from the Idea phase of a project. It will usually contain the following:
The first phase in an Agile approach starts with identifying the opportunity or problem. The Project Owner and Sponsor must establish a shared sense of purpose with agreement that actions are taken to capitalise on the opportunity or resolve the problem.
A small focused
This last point is a key element of the Agile approach, as permission is not sought to commence the project, merely to progress to the next Discovery phase. This concept is taken from Lean "just-in-time" processes to ensure effort is sufficient and waste minimised.
See Implementation Phase.
The Implementation phase comes after the Design work has been completed. This phase is designed to deliver on the vision and solution defined during the Design phase. It involves ongoing collaboration with key stakeholders for the duration of the project and is designed primarily to maintain alignment between daily activity and delivery of the planned
Something that has happened (or is happening right now) that requires attention and management. An issue is different from a risk as it does NOT have a probability (because an issue is 'here and now') and is having an impact (usually adverse) on the project.
The response to an issue should be pre-defined as one of the controls proposed for the corresponding risk.
For more info see: Risks, Issues and Opportunities (RIO)
A fixed period of time during which activity is done to achieve a specific outcome. Iterations are usually 2 weeks in duration but can vary as required.
NOTE: I find that 1 week is not long enough to allow people to get on with the doing and 4 weeks too long as a team can start to drift off course.
A key role in the core team. In order for the core team to stay focused on maximising the amount of business value generated during the implementation phase, team members must assume the role of IM from time to time. Initially teams may have a dedicated person performing this role, however they should rapidly be assigning IM-related tasks to any member of the team within the first few iterations. Often an expert agile coach or facilitator can perform the IM role to help get the team moving in the right agile directions.
People performing IM tasks help to facilitate or coach colleagues through: iteration planning meetings (IPMs), backlog grooming, status reports, and tracking progress using burn down / burn up charts. Everyone in the team should be capable of performing these tasks to reduce the dependence on any one individual. This approach has the added benefit of adopting standardised approaches that the team can buy in to, as no one individual can dictate their personal style to the team.
A planning session undertaken collectively by the core team to determine what will be worked on in during the next iteration. Iteration planning occurs prior to commencement of the next planned iteration and requires a Backlog Grooming session to ensure all of the cards are already prioritised based on the higher-level release plan.
Commencing with the next highest priority, the Product Owner explains the card in more detail. The team probe and question, to determine relevant details necessary to elaborate the card. Elaborations may include mock up designs, process maps, acceptance criteria, testing approaches and necessary skills required to complete the card.
Given an elaborated card, the team may chose to merge or split the card to ensure the size of the card is suitable to complete within the planned iteration.
The team will then estimate how many cards can be drawn from the backlog into the upcoming iteration and commit to that delivery. Various artefacts are updated at this point to project the likely velocity of he team (burn up/down charts, release plans, project charters, status reports, and story walls).
This is the first iteration performed in the implementation phase and represents the setup for the team. No cards or tasks of business value or related to scope should commence in this first iteration. The goal is to ensure that when iteration 1 commences, the team can commence work unimpeded by any tools, facilities, resources or capabilities they need.
Most iteration zero efforts focus on the following activities:
Any other tasks as needed for the team to commence immediately.
Is a Japanese word that translates as "signboard" or "billboard". Kanban refers to the process of using visual triggers to help manage the work in progress on an Agile wall. Kanban is useful alternative to
An event of significance that occurs at a pre-determined point in time. Milestones usually mark the end of a stage to signify the completion of a work package or phase. Milestones can be scheduled before the end of a phase so that if problems arise corrective action can be taken to ensure the outcome is achieved on time.
A diagram used to visually organise information. It is usually created around a single concept and drawn with an image in the centre of a blank landscape page, to which associated representations of ideas such as images, words and parts of words are added.
The smallest set of functionality inherent in a product or service that must be realised in order for the customer to perceive value. An MMF is the Agile approach used to chunk features that the Product Manager can use for their release planning.
A prioritisation technique used to reach a common understanding on the importance of particular tasks, outcomes or features. The categories are as follows:
The upside of risk. In particular, opportunity recognition is an entrepreneurial skill that identifies the potential to achieving something greater then what was originally conceived.
In most organisations a significant amount of energy is spent on risk (hazard) and issue management and little on opportunity exploitation. Managing risks and issues bring comfort to Sponsors and executive teams because it increases the predictability of a project delivering what it was originally intended to do (even it comes at more cost). However, exploiting opportunities can provide a far greater return on investment.
Large organisations struggle with opportunity recognition as risk and issue management are far more 'real'. Whereas small business (that is, the 'small business mindset') is inherently more flexible and better suited to exploit opportunities out of competitive necessity. The Agile Principles are biased towards opportunity management.
A useful tool to help visualise opportunities is the Dynamic SWOT also known as a TOWS Matrix, where the original SWOT is expanded into an action-oriented approach: http://bit.ly/Y6tG1j.
For more info see: Risks, Issues and Opportunities (RIO)
Personas are used as proxy to represent an individual / group who is not present to participate in a process. For example, if a Voice of the Customer process is being used to elaborate the requirements for a project and the actual customer is not available, then an individual can assume the 'persona' of that customer for the purposes of the project.
Asking people to assume a persona is also a powerful way to build empathy for that particular person / role being 'channelled'.
Planning poker is a consensus-based technique for estimating the relative size of tasks. It works by each estimator being given a deck of cards. Depending on the scoring system chosen, the deck of cards may read: '0', '1', '2', '3', '5', '8', '13', '20', '40', and '100' in large print. Participants are asked to rate each task with the cards but do not show the others their rating until everyone reveals their cards at once. Where there is disparity between the estimates, discussion can take place to finalise an effort/resource score for the task.
The numbering sequence may be exponential (e.g. 1, 2, 4, 8, 16, 32...) or Fibonacci (e.g. 1, 2, 3, 5, 8, 13, 21, 34...).
See Agile Practices.
See Agile Principles.
The individual (usually referred to by virtue of their role or position) that is primarily accountable for the design, governance and (usually but not always) execution of a business process. This includes maintaining and assuring the quality of the process inputs and outputs.
A Process Owner is usually not a member of the core team unless the nature of the project is significantly changing the processes as part of the implementation. If the team requires confirmation of specific process details or permission to change a process as part of their planned scope, the Process Owner should always be engaged. The team should identify this dependency and request involvement as an action from the iteration planning meeting (IPM).
The person who represents the key stakeholders and acts as the Voice of the Customer. He or she is accountable for ensuring that the core team delivers value to the business. The Product Owner writes (or has the team write)
The Product Owner and
Provide steering about when to release the product.
A brief statement of the desired future state or artefacts that are to be achieved through a successful completion of a project. A product vision may be expressed in any number of ways including financial performance, creative genius, customer satisfaction, market share, functional capability or features of an artefact. The
A project is a temporary endeavour undertaken by an individual or group to create a unique product, service or result with the ultimate purpose of delivering a desired benefit.
Projects have a clearly defined start and end. In corporate organisations, projects are best managed with the application of a structured approach and often require their own dedicated governance framework that is distinct from business-as-usual (BAU) governance.
Projects typically have an allocated set of resources (people and / or money) that are aimed to deliver a specific benefit. Projects typically do not have recurring budget implications.
A program is a group of related projects managed together to obtain benefits that would likely not occur if the projects were managed individually. While project management focuses on delivering the specific outcomes – program management is focused on achieving the strategic objectives and benefits of the integrated program.
A portfolio is a collection of projects or programs grouped together to facilitate the effective management of efforts to achieve strategic business objectives. A portfolio of projects need not necessarily be interdependent or directly related.
Portfolio governance is the centralised management of multiple projects, programs and possibly portfolios. This typically includes identifying, prioritising, authorising and monitoring projects and programs to achieve specific business objectives.
A Project Charter is an electronic document detailing the vision, mission and success criteria of a project. It is one of the most important documents in a project and should consider the impact of the project on all stakeholders. It differs from a business case in that the business case is used to justify or get approval for the project, while the Charter sets out the broader approach to deliver the project and holds all key information related to specific goals, governance structures, timelines, budgets, risks, roles and responsibilities, change management, communications, and solution options considered. It should serve as a single repository for all planning aspects of the project.
As a controlling document that lives throughout al phases of a project, appropriate document management controls (versioning, access, etc.) should be implemented to govern its use.
A presentation tool such as PowerPoint is useful to keep the word count low and leverage photographs, diagrams, etc. to convey key points. Most Project Charters in this format will be between 10 and 40 slides long depending on the size and complexity of the project.
A key role in the core team. An Agile PM is primarily responsible for managing outwards from the core team. They also help remove impediments that the team cannot resolve.
The project manager is primarily responsible for managing up to the sponsor and assuring the project lifecycle is tracking as it should. The PM acts as an interface between the Core Team and Extended Team to deliver a project.
See Project Charter.
The most senior member of the extended team and is responsible for setting the strategic vision for a project. The Sponsor needs to champion the project’s benefits and impact throughout the organisation, especially to colleagues and peers who will need to contribute staff, time, resources or effort to deliver the project.
A sponsor must commit to delivering
A critical role that a Sponsor must play is that of "Chief Impediment Remover". If the team raises blockers during a stand-up, at a retrospective, or during a showcase, then a Sponsor needs to play the role of a servant leader and clear a pathway for the team, in order to maintain their velocity. In most cases however, the team will exhaust multiple efforts to resolve issues themselves and the Sponsor is not called in to action.
See Agile Wall.
A schedule for delivering features, functions or services into productive use. Typical release plans include the key features to be delivered, along with corresponding release dates. Release plans also expose key milestones or dependencies on parallel project activities.
Refers to planning activities used to estimate when features, functionality or services will be released into productive use. Activities include projecting the level of effort in terms of the number of iterations that will be necessary to deliver the desired features. A release plan represents how much scope that team intends to deliver by a given deadline.
The scope of releases is usually referred to in groupings of minimal marketable features (MMFs). Each MMF must also meet the definition of done to ensure it can be deployed into the operating environment.
The discussion is recorded and actions are assigned to individuals with corresponding due dates. Actions from retrospectives should be discussed at stand-up meetings like any other significant activity performed by a team member.
The chance of something happening that will have an impact on a project / business. The potential for the consequence of risk events can be either positive (desired) or negative (undesired). ISO 31000 defines risk as: " ...effect of uncertainty on objectives"
Risks are different to
The primary way of dealing with risk includes:
Risk ratings should recognise the current residual ratings (both likelihood and impact) after controls or mitigations are in place, as well as the future ratings once any outstanding actions are completed. For more info see: Risks, Issues and Opportunities (RIO)
The use of focus or reference groups to role play using the project’s deliverables can be key to assessing their likely success in a production environment. However focus groups can be overly time consuming for participants and logistically difficult to coordinate for project teams. Even worse, is when the people selected are not representative of the wide range of customer or users in scope, leading to incorrect or invalid assessments of the project.
Personas can play a useful role as an alternative to focus or reference groups, as they are virtual representations of your typical customers. Using various tools to obtain the Voice of the Customer (VoC), Personas can them form part of the team’s approach to designing and testing features through role playing. For example, "what would Mechanical Mike want out of this", or "do you really think Clever Claudia would put up with that"? This fast tracks the feedback process and ensures a broad range of requirements are considered in a time and cost-effective manner.
A method of problem solving that looks deeper into the symptoms of an issue to find out what is causing them. Several established yet simple techniques can be used to complete these tasks, staring from verbal or facilitated sessions and moving to more statistical searches for root causes:
Be careful with correlations as data can often yield a correlation where there is no cause and effect. For example, there is a strong correlation between the time of day when a rooster crows and when the sun comes up, but ...he doesn’t cause it.
The scope of a project is represented in multiple levels, with each level progressively revealing more detail. The following list breaks down project scope from its highest element into its lowest level of detail. The linkage between each level is shown firstly in the project charter and once the implementation phase commences, on the teams agile wall:
Scrum is a simple framework for effective team collaboration on complex projects. It is the same as a stand-up meeting where team members share relevant information on what they are working on and if they need some assistance in removing blockages.
In larger programs of work where multiple projects are contributing to a common goal, representatives from each team (the person acting as Iteration Manager) will attend a Scrum-of-Scrums meeting to share project updates with other Iteration Managers and Program staff.
Scrum can also refer to the formal agile methodology that is one of the predominant agile approaches used globally. Many agile practitioners have completed Scrum certification and will use the terms Scrum and Agile interchangeably.
As a team matures it will begin to organise itself rather than passively waiting to be directed by an external force such as a Project Sponsor. More importantly, this means that the team does not solely rely on the Project Manager or any type of perceived leader to lead the team. Using the principle of wisdom of the crowd, operational decisions are distributed around the team initially to those who have the most detailed knowledge (e.g. Subject Matter `) with the team then making an informed decision as a group. This process is not to be mistaken for groupthink.
NOTE: On 'smaller' projects (e.g. low risk, low cost, low benefit) a mature core team is often able to handle the decision making associated with executing a project. On larger projects, self-organising is more challenging and an extended team or steering committee (SteerCo) is often required to ensure that the deliverables and milestones are achieved to assure business benefit is realised.
An event held by the core team to demonstrate completed artefacts / products / features to key stakeholders. The aim is to demonstrate progress towards meeting stated business goals and objectives. Stakeholders will also have the opportunity to provide feedback and propose
If showcases are identifying flawed deliverables or they are triggering course corrections, the project may have other concerning issues at play, such as a Product Owner that is not empowered or skilled enough to perform the role, or perhaps a stakeholder group that has not bought in to the project's vision. These symptoms would warrant some urgent root cause analysis from the Project Manager to understand the source of discontent.
This term refers to the instinctive detection of something that "smells a bit off". This kind of subjective assessment of issues and risks draws on the principles of collaboration, transparency and simplicity. As members of the
An artefact that represents the agreed values and behaviours that all team members will abide by. The social contract is set by the team at the commencement of the implementation phase and closely aligns with Tuckman’s principles of accelerating the forming, norming and storming phases of group development.
The core team gets together and discusses the way the team wants to operate together. They create an agreed set of rules that:
Teams need social contracts because:
It helps build the character of the team and create a shared sense of identity.
A spike is a short and sharp piece of activity designed to remove uncertainty. The need for a spike should be decided as stories or tasks are elaborated during the iteration planning meeting. This is where the core team will decide that the definition of ready cannot be completed for a given task, as more research is needed to either qualify/quantify the problem, or consider the viability of possible solution options.
The sponsor is the individual (usually a manager or executive) with accountability for the project's ultimate success or failure. The Sponsor is primarily concerned with ensuring that the project delivers the agreed business benefits within the organisation’s investment appetite. The Sponsor acts as the representative of the organisation, and plays a vital leadership role through:
Performing the role of chair on the project’s Steering Committee.
The Scrum term for an Iteration. The sprint starts with a sprint (iteration) planning meeting. At the end of the sprint (iteration) there is a sprint review (iteration) retrospective meeting.
Anyone external to the team with a vested interest in the outcome of the team's work. The Project Manager, Change Manager and Communications Manager must take primary responsibility for managing, tracking and coordinating interactions with stakeholders.
An informal daily team meeting held to provide an update to colleagues in the core team. The stand-up allows participants to know about potential challenges as well as coordinate efforts to help each other resolve risk or issues. The meetings are usually time boxed to 30 seconds per participant, and are held standing up to remind people to keep the meeting short and to the point.
Ineffective stand-ups often result in each person pointing to their card on the agile wall and providing a verbal status update that is mostly irrelevant to the other team members. A 'camp fire' is a useful metaphor to consider when comparing stand-ups to other meeting types (i.e. talk to each other with purpose, not aimlessly at a wall).
The team should produce a status report at the end of every iteration with the format, level of detail and content negotiated with the Project Sponsor. The status report should summarise the following key elements:
A Steering Committee (SteerCo) is usually chaired by the Project Sponsor or their direct leader. In some organisations a CFO or CEO chairs all Steering Committees. A group of senior staff at an equal or approximate organisational level to the Chair would be formed to govern the project. An example of the kind of representatives required includes: risk, finance, technology, human resources, program/portfolio management, legal/governance, media/public relations, etc.
The Project Manager would work with their Owner and Sponsor to schedule meetings and present in line with the projects cadence. A project with fortnightly iterations would adopt SteerCo meetings every 4 weeks to ensure consistent status reports can be generated. All issues that would alter the Project Charter should be tabled, discussed and agreed to by the SteerCo members before proceeding (new features, different timelines, changing budget, etc.).
The SteerCo should also be invited to showcases to understand the progress being made each iteration. This invite should extend to ad hoc "walk the wall" sessions where they can come in to the project room, unannounced and pursue the agile wall to get a sense of what is going on at the coalface of a project. By embracing transparency, our experience shows that senior members of staff relish in the opportunity to remove blockers, clarify puzzles or have their own expectations managed with regard to velocity (shown in burn down charts).
A user story is different from other requirements documentation techniques (not to be confused with Use Cases) as it places the user, an SME or Product Owner usually, at the forefront of specifying what business activity they want to be able to do. Stories take the format of:
As a ...customer, I want an ...outcome, so that I can ...benefit.
Additionally, stories uses a 3 phase process (based on Ron Jeffries thinking, one of the original signatories to the Agile Manifesto) to progressively add more detail to the requirement. Each phase represents a distinct activity within a project’s cadence:
See Agile Wall.
A document (ideally a single page) to succinctly communicate with stakeholders. The core elements are:
A SOAP is typically used during the idea phase to engage with stakeholders.
A key role in the core team. A person with authoritative functional knowledge in a particular area or regarding a particular topic. SMEs are often assigned to the
Sliders represent the Steering Committee's position with regard to making various trade-offs within the day-to-day life of a project. There are usually 4-5 different sliders with a scale from Fixed to Variable for each. The notches on the scale need to equal the number of sliders so that no one slider can be in the same position (producing a forced ranking of the sliders). A common example would include: Quality, Time, Cost and Scope.
A project team can use these sliders and ensure they are part of the project’s BVC. This way a project team member can ask themselves which trade-off they should make when they reach such a decision point, e.g. take longer, go quicker, highest quality, cheaper, etc.
Typically, the Discovery and Design phases would confirm the project's sliders with the Steering Committee.
Doing only what is required to meet the needs of the customer or satisfy the definition of done for a task. Sometimes, 'sufficiency' demands a higher level of quality and effort, however most non-agile artefacts are over-engineered beyond what is immediately required.
This sufficiency principle is aligned to the concept of minimum marketable features. The MMF principle refers to the minimum amount of features required in order to take a product (often working software) to the ‘market’ of internal and / or external customers.
The individual (usually referred to by virtue of their role or position) that is primarily accountable for the procurement, installation and maintenance of enabling tools (e.g. software) to optimise business process execution and underpin the achievement of business benefits.
A process where tasks are compared to one another and categorised as either small, medium large, extra-large or XX-large. The t-shirt size is analogous to an exponentially growing number such as Extra small = 1; Small = 2; Medium = 4, Large = 8 and so on. The process for conducting T-shirt estimation uses the processes outlined planning poker.
A task is an activity performed, usually, by a member of the core team. Tasks can be represented on physical index cards and displayed on an agile wall to ensure all members of the team are aware of who is performing the task, what its priority is, roughly how long it may take and briefly, what activities the task will include.
A task will move between various statuses as it progresses from 'not yet started', to 'in-progress' and finally 'done'. Some teams choose to define a more comprehensive workflow for tasks depending on their specific requirements.
For more info see Task Card.
A critical agile artefact that captures key attributes onto a small library card or stick note.
Refers to a requirement, feature and/or chunk of business value that can be prioritised, size-estimated and is compliant with the set definition of done. Task cards are generally hand written cards placed on the wall and referred to and moved in stand-up meetings. The basic unit of communication, planning, and negotiation between the agile team, business owners, and the product owner.
These cards typically include of the following elements:
Sometimes referred to as a story card.
See Agile Wall.
Most projects build their deliverables using existing assets, capabilities or systems. Even those projects that start with a blank canvas will start to build things that given time, should be updated, re-authored or improved. This issue is referred to as technical debt.
As new versions of software or new standards are released into the broader environment, what the project has delivered or inherited has a risk of becoming obsolete. Rather than defer these updates to the next project, Agile believes that "refactoring" as you go is the more efficient way to keep your deliverables up-to-date and easier to support for the next team or project. As a part of elaborating a
Testing in Agile projects represents a critical function to maintain the quality of deliverables. Importantly, everyone in the core team is responsible for product quality. An Agile saying from software development is: "testing is far to important to be left to the testers". This is not a slight on professional testers, their role is important in Agile projects, it is more that testing should not be left to testers alone.
At the heart of Agile testing is the determination of business value, where the customer’s most desired outcomes are delivered as fast and as frequently as possible. To maintain cadence, teams use a range of techniques to capture examples of the desired behaviour of the project’s deliverables and use these for testing confirmation. Importantly these techniques work best when they make use of the cross-functional nature of a strong core team:
A time period of fixed length used to encourage a finite amount of work for repeatable activities. When applied to an Agile way of working, iterations are 'time boxed' to ensure consistent planning approaches, and meetings are always time boxed to ensure administrative activities are kept to a minimum stand-ups, Retrospectives, Iteration Planning, etc.
Time boxing is one specialised form of cadence. It’s like a metronome, giving a single tick, just like the beat of a drum. Once a team become used to time boxing they usually incorporate for most activities into their social contract.
This label is applied to 'tragically implemented agile', as well as 'Agile projects ending in Tragedy'. We know that poorly run projects will fail, just as poorly implemented agile principles and techniques can just as easily fail as well. Some of the most commons causes emerge from adopting Fragile or WAgile, each of which have their own set of pitfalls. When projects fail, people look to blame tools or methodologies and often people can start to lose confidence in an Agile way of working. Proponents of Agile that promote 'fast and loose' attitudes such as, we don't need documentation, let’s start building right away, don't worry if business representatives can't make it, or don't worry about those bugs, we can fix them later, are all promoting a path towards 'Tragile'.
Is a measure of the volume of work a team has completed during an iteration. Velocity is measured by adding all of the
Velocity can also be used to make estimates around resourcing requirements. For example, if the core team has been sustainably completing 100 points worth of work / fortnight for several iterations, and requires 200 points worth of work to be done next iteration, then there is clearly going to be a problem. Basic maths would lead one to conclude that the core team needs double the resources to do double the work. But teams don’t work this way. Firstly, no team is 100% efficient so you would probably need 120% of the resources to do double the workload. Secondly, teams take a while to get up to a sustainable
A term used to describe the in-depth process of capturing a customer's expectations, preferences and aversions – their hopes and fears! Understanding the Voice of the Customer (VoC) is a market research technique that produces a detailed set of customer wants and needs and any other intelligence that can tell you more about the customer.
A room (or dedicated location) that provides a space where people come together to manage work. The space serves as a centre that allows a team to operate in a predictable manner to exchange ideas, manage plans and share information in an active way.
As the term has military connotations, it may be preferable to label your space with a phrase that is more amenable to your workplace. Regardless of the label used, the space is typically used to house the Agile wall, big visual charts, user stories, task cards, the RIO, and other artefacts as required.
WAgile is a hybrid of Waterfall and Agile approaches to delivery. Often, waterfall projects encounter difficulties when the project realises that what was designed 6-18 months ago, is no longer relevant or applicable, but due to the nature of their project, their organisation's appetite for change, along with a multitude of inflexible processes, they decide to adopt some Agile techniques in a desperate attempt to save the project. You will recognise these projects as they will most likely have an Agile wall, they will perform daily stand-ups and will probably be operating in fortnightly iterations. The vast majority of the agile principles however will not be in place, the business will not be receiving bundles of value every fortnight, there will be minimal refactoring, and even less honest retrospectives.
Wisdom of the crowd is the process of taking into account the collective opinion of a group of diverse individuals rather than a single expert to answer a question. A large group's aggregated answers to questions involving quantity estimation, general world knowledge, and spatial reasoning has generally been found to be as good as, and often better than, the answer given by any of the individuals within the group.
An intuitive and often-cited explanation for this phenomenon is that there is idiosyncratic noise associated with each individual judgment, and taking the average over a large number of responses will go some way toward cancelling the effect of this noise. Social information sites such as Wikipedia and Yahoo, while not new to the information age, have pushed this process into the mainstream spotlight! Answers, Quora and any other web resources that rely on human opinion. The process, in the business world, was detailed by James Surowiecki in his book The Wisdom of Crowds.