The Agile Manifesto
Created in 2001 to summarise the approach taken by the creators of agile frameworks, it highlights the need to put the emphasis on:
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Twelve supporting principles were created at the same time:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Agile Delivery Frameworks
Scrum – an agile product delivery framework comprising 3 roles, 5 events, and 3 artefacts, upon which teams build their own process. Work is limited by fixed-length sprints of 30 days or fewer.
Kanban – a methodology for improving any process, not limited to software and with no constraints or timeboxes. Work is limited by a pull-system: new work can only enter when a space is made by completed work leaving the system.
Lean software development – an adaptation of the lean principles developed in manufacturing to make them relevant to software, taking the form of seven principles:
- Eliminate waste
- Build in quality
- Create knowledge
- Defer commitment
- Deliver fast
- Respect people
- Optimise the whole
Lean Start-up – a way of bringing a new product to market to validate the hypothesis that it is valuable, while minimising the financial costs.
DSDM Atern – an agile project management framework that seeks to allow projects to be delivered at fixed timescales by varying scope and delivering in a series of iterations.
eXtreme Programming (XP) – An agile framework similar to Scrum with an emphasis on technical excellence and close customer collaboration.
Scaled Agile Framework (SAFe) – a framework for delivering large-scale agile products comprising five or more teams, with patterns to enable programme and portfolio management and co-ordinated planning.
Concepts and ideas
The iron triangle: made up of three variables to be managed while delivering a project:
Traditional waterfall projects often fix the features to be delivered and vary time and cost. Agile projects allow a choice in what may be varied.
Timeboxes: The maximum about of time permitted for an event, and the fixed amount of time allotted for an iteration or sprint of development. For example:
- In Scrum, the maximum amount of time for Sprint Planning is 8 hours. It doesn’t have to take that long, but can’t take longer.
- Iterations or Sprints have fixed timeboxes, which are chosen at the start and are typically kept the same length every time. If the team chooses a 2-week sprint, then more work is added if they finish early, and any incomplete work is put back on the backlog if not done within the 2 weeks.
Cone of uncertainty: The uncertainty in cost, effort, and size of work is large at the beginning, and follows a cone-like profile becoming less uncertain as time progresses.
Waterfall: An example of a defined process where projects are delivered in large stages or batches. All of the analysis is done, followed by all of the design, coding, testing, etc.
Empirical process control: An empirical process is one where it is accepted that the requirements and technology are not fully understood at the start and will need to be adapted based on new information and measurement. The three pillars of an empirical process are:
- Transparency – we need to be able to see clearly what progress has been made
- Inspection – we need to look at the product as it evolves and get feedback
- Adaptation – we need to be able to change the plan and the process in light of new information
Examples of empirical processes
- PDCA Plan, Do, Check, Act
- POOGI Process of On-Going Improvement
- OODA Observe, Orient, Decide, Act
- BML Build, Measure, Learn
- DMAIC Define, Measure, Analyse, Improve, Control
- TAC Thought, Action, Conversation
- Kaizen – the practice of making continuous, small improvements
Technical Debt: Work that was deferred to achieve an early release, that now increases effort or cost. Examples include:
- Cutting quality or testing
- Not automating test or deployment activities
- Not refactoring code or keeping up to date with evolving technologies
Schneider culture change model: a way of understanding an organisations predominant culture, or “the way we do things round here to succeed”:
Agile transformation often involves an attempt to move away from a “Control” culture.
Kotter’s 8-step change model can help leaders to plan a transformation, such as from traditional project management to agile delivery. The 8 steps are:
- Establish a sense of urgency
- Form a powerful guiding coalition
- Create a new vision
- Communicate the vision
- Empower others to act on the vision
- Plan for and create short term wins
- Consolidate improvement and produce still more change
- Institutionalise new approaches
The Product Owner. Also referred to as:
- Product Manager
- The Customer
Defines what is to be delivered, released, and optimises the overall value of the product. Desirable characteristics follow the DARKA model:
- Desire to be involved in the product
- Authority to make decisions
- Responsibility for the outcomes of those decisions
- Knowledgeable about the product, users, and market
- Available to the team to clarify requirements and make plans
The Development Team. Also referred to as:
- The team
- Agile teams
Responsible for delivering the value defined by the product owner. Desirable qualities:
- Cross-functional – each member of the team has a specialism, with abilities to carry out secondary skills, with a T-shaped profile
- Self-organising – the team decides how to turn the requirements into working software, and who should do what on a daily basis
- Recommended size: 7 ± 2
The Scrum Master. Also referred to as:
- Agile lead
- Agile coach
Responsible for the process, facilitates and coaches, resolves impediments. Desirable qualities:
- Servant leader for the team, guiding without direct authority
- Enables the other roles to be effective without making decisions on their behalf
The Stakeholders. May be categorised as follows:
- High-power, high interest – the aim is to keep engaged and to consult regularly
- High-power, low interest – the aim is to satisfied, while attempting to increase interest
- High interest, low power – the aim is to keep informed and allow useful ideas to be highlighted
- Low interest, low power – the aim is to keep aware via general communication
Motivated and empowered people: Whatever the role being carried out, the most effective teams are built on motivated people. Models and theory often used to guide leadership in this area include:
- Maslow’s hierarchy of needs: Individuals are unlikely to be engaged and created unless their basic needs are met, in this order:
- McGregor’s Theory X / Theory Y: The way that people are managed has a big effect on motivation, and this can be simplified into two “theories” held by managers:
- Theory X managers believe employees hate work and have to be forced to do it
- Theory Y managers believe employees like work and can be trusted to work effectively
- Dan Pink’s Intrinsic Motivation: External motivation such as bonuses have a neutral or negative effect when used to motivate knowledge work. Intrinsic motivation relies on maximising the following characteristics of the work itself:
- Autonomy to control your own work and decide how to reach the goals assigned
- Mastery of skills and specialisms, the opportunity to learn and to apply that knowledge
- Purpose and a sense of knowing that you’re making a difference
- Tuckman’s theory of team evolution: A simple model to understand how a new group of people are likely to evolve
- Forming: A focus on formality and routine, with the avoidance of conflict
- Storming: Differences come to the surface and conflict arises
- Norming: Conflicts are mostly resolved and the team becomes productive
- Performing: People work dynamically with high trust and creativity
- Five dysfunctions of teams: Patrick Lencioni’s model of team dynamics highlighting five typical anti-patterns, which are often overcome in this order:
- Absence of Trust
- Fear of Conflict
- Lack of Commitment
- Avoidance of Accountability
- Inattention to Results
User Stories: A simple way of expressing requirements on a product backlog to allow the high-level intent to be understood. Just enough detail to decide how to prioritise, and whether to start analysing further. The most common format is:
As a <Role>
I want <Functionality>
So that <Benefit or value>
Product Backlog Refinement: A catch-all term for the activities that go into adding additional detail and analysis to items on a product backlog. These activities often include:
- Estimating the effort
- Adding acceptance criteria
- Managing dependencies
These activities may be done by individuals, small groups, or by the whole team. They are usually carried out during an iteration/sprint, for work coming up in the future.
Product Backlog Ordering: The product owner has the final say over the content and ordering of the product backlog. Some choose to use the following approaches:
First in, first out (FIFO): Often used for operational teams such as support – items are handled in the order they are received with no assessment of value
Shortest Job First (SJF): To prioritise quick wins without assessing value, the shortest, lowest effort items are put at the top of the queue
Hight Cost of Delay First (HCDF): High value items that would result in a cost of delay if not done are prioritised, especially items with deadlines or time sensitivity
Weighted Shortest Job First (WSJF): A score is calculated combining effort and cost of delay, resulting in small, valuable, time-sensitive items to be done first
INVEST: Characteristics of good quality backlog items. By the time items reach the top of the backlog and are likely to be planned for the next iteration/sprint, it is desirable that they are:
- Independent – can be done in any order without dependencies
- Negotiable – developers can offer alternative solutions to deliver the value needed
- Valuable – it must be clear what benefit is being delivered
- Estimable – there must be enough information to allow reasonable estimates
- Small enough – to deliver within a single iteration/sprint
- Testable – it must be clear what is required and when it can be considered complete
Acceptance Criteria: Specific, tangible tests that clarify what is wanted. Usually added to user stories / backlog items a few days or weeks before the work will be done, to avoid the requirements going stale.
Behaviour Driven Development (BDD) Scenarios: A form of acceptance criteria that allows technical and business people to define how a system should behave in a range of specific scenarios. The format is:
Given <A set of preconditions, context, or starting point>
When <An action occurs>
Then <The system should respond in this way>
Technical Spike: Also known as research tasks, these are items in the backlog that provide information on risky or uncertain items that are difficult to estimate. For example, a team may not be able to size the work “Connect to the new system” so they add a technical spike to the backlog: “Spend 2 days experimenting with the new system to product a recommended technical implementation”.
MoSCoW Prioritisation: The practice of planning an agile project with a backlog of features, and nominating each item:
- Must have
- Should have
- Could have
- Wont have (this time)
Ideal Days Estimation: Teams size backlog items in ideal “productive time” (rather than elapsed time). Often avoided due to a range of undesired consequences:
- Parkinsons law: The work expands to fill the time available
- Quality may be put under pressure if the work is more complex than was first thought
Story Point Estimation: Teams size items relative to each other, in arbitrary units not directly tied to duration. The most common scale used is the Fibonacci sequence:
1 2 3 5 8 13 21 34 55 89
Planning Poker: A way of allowing a diverse team of estimators with different specialisms to apply story point estimates to items:
- Each item is discussed
- Individuals estimate individually using cards without seeing what their team mates picked (to avoid anchoring bias)
- Everyone turns over their card simultaneously
- Differences in opinions are discussed, enhancing the shared knowledge of the team
- A final number is agreed upon based on the shared information
Top-down planning: The practice of estimating the size of large pieces of work by comparing them as a whole to similar previous projects.
Bottom-up planning: The practice of estimating work by sizing individual items on the backlog.
Velocity: An historical performance metric that shows how much functionality was delivered at the end of previous sprints/iterations. Usually measured in story points, and used by:
- Product owners to predict release dates for items on the product backlog
- Development teams to predict what they can deliver in the next sprint/iteration
Agile Testing practices: common techniques include, but are not limited to:
- Test First Development (TFD) / Test Driven Development (TDD): A technical form of testing usually done by software engineers themselves, that involves writing a failing unit test, then writing just enough code to make it pass
- Specification by Example: The practice of providing examples of the data or output that would be expected for an upcoming feature.
- Behaviour Driven Development (BDD): Creating tests based on BDD Scenarios, operating at a functional level and fulfilling a similar job to traditional regression tests.
- Acceptance Test Driven Development: Similar to TFD/TDD, but rather than operating at the technical / unit test level, it operates at the functional level. A common form is to write a failing automated BDD scenario, and then write enough code to make it pass.
Sprint planning: An event where the whole team get together to make a plan for the next sprint. The product owner brings the product backlog with items at the top in a suitable state to plan. Each item is clarified, before the development team break it down into a detailed plan. The timebox for this event is typically 8 hours for a 4-week sprint.
Daily Scrum: Also known as the daily stand-up or team synchronisation meeting, the purpose is for the team to inspect progress towards their goal, share relevant information, and adapt their plan as necessary. The timebox for this event is typically 15 minutes, and takes place at the same time and place every 24 hours.
Sprint Review: Also known as the show & tell, the purpose is to allow collaboration between the agile team and the business. The work completed is inspected along with the current product backlog and release plan. All parties participate in giving feedback and discussing options with a view to adapting the product backlog and improving the plan based on new information. The timebox for this event is typically 4 hours for a 4-week sprint.
Sprint Retrospective: the purpose is to allow the agile team to inspect and adapt the process based on their experiences in the last sprint. The whole team identifies what went well, and what didn’t go well, before committing to at least one specific, actionable improvement to take into the next sprint. The timebox for this event is typically 3 hours for a 4-week sprint.
Team Geographies: Most agile teams are arranged by one of the following patterns:
- Co-located / Face to Face teams all work in the same physical location, allowing easy communication and ad-hoc problem solving
- Multisite teams are co-located across 2 or more sites
- Distributed teams are dispersed in a combination of multi-site groups and individuals working from home or alone on-site
Five Centrifugal Forces of Distributed teams:
- Communication breakdown
- Co-ordination breakdown
- Loss of communication richness
- Loss of team bonding
- Cultural differences
Mitigating factors for distributed teams: steps that can be put into place to address the five centrifugal forces:
- Video conferencing
- Knowledge management systems
- Collaboration platforms
- Instant messaging
- Interactive whiteboards
Burn-down charts: used by teams to understand progress towards the work forecast for the sprint/iteration. They track work remaining vs time, often measured in hours or subtasks.