menu

Agile Mindset

We will be focusing on software product development, but the same concepts can be applied anywhere - including in your own daily life.

Flow of Work Card Game

  1. Create two “assembly lines” of 5 people each, and sit them facing each other.
  2. Give the first person in each assembly line a stack of 15 playing cards.
  3. Assign each assembly line a process:
    • Group 1: First person flips each card in the stack. Once the stack is complete, it is passed along. Each person in the assembly line does the same.
    • Group 2: First person flips three cards, then passes along the mini-stack. First person continues creating 3-card mini-stacks and passing them along. Each person in the assembly line does the same.
  4. Observe the time taken for each assembly line to complete the work.
  • What were some keys things you noticed?
  • What observations can you make about the delivery of value to the customer, ie. completed work?
  • How might this activity relate to real-world projects?
  • What are the limitations of this example?
  • What project management lessons could we take from this activity?

Optional extra rounds:

1. Introduce a “change request” halfway through the workflow
While there is work in progress for both teams, introduce a “change request”. From now on the client wants only black cards delivered. All incomplete work (not at the end of the assembly line) must be returned to the start of the process.

2. Make one team a self-organising team
Anyone can work on any part of the project. That is, any worker can flip any card at any time.

In a self-organising team, the team members are experienced in more than one role, and can be involved in all parts of the development process.
In a traditional team, whether they do small chunks of work or not, people have a specific role and can only contribute to one step of the process.

Compare the self-organising team with the traditional team. How does this relate to real-world workplaces?

Common Development Problems

When developing a product, the project might fail due to:

  • Running out of time
    As projects get closer to the due date, the team panics about how much is left to do. They cram in work, invest long hours, endure stress, and often deliver a sub-standard product as a result.
  • Running out of money
    The project may find it is nearing the limits of its budget, and yet the features completed are not the most critical ones, making the product effectively useless.
  • Not solving the problem
    A complete product may be delivered, but it does not meet the needs of the people it aimed to help.

For a project to be successful it is critical that the product reaches a usable state as early as possible. Features of the product should be strictly prioritised, and that prioritisation should be reviewed regularly in case requirements have shifted.

4 Key Values of Agile

As an Agile practitioner, you should regularly ask yourself whether you are adhering to these values in your daily activities.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Each value is arranged into a “left side” and a “right side”. The right side is important, but the left side is more important.

12 Principles of Agile

The twelve principles are designed to support and clarify the four key values.

  • Satisfy the Customer
  • Welcome Change
  • Deliver Frequently
  • Measure of Progress
  • Motivated People
  • High Bandwidth
  • Whole Team Daily
  • Sustainable
  • Technical Excellence
  • Simplicity
  • Self Organising Team
  • Continuous Improvement

Agile Poster

This activity explores the relationships between Agile’s 4 core values and the 12 supporting principles.

  1. In groups of 2-4, visually arrange the values and principles in a way which reflects the relationships between them.
  2. As a group, share your arrangement with the class and explain your choices.
  3. As a class, do the activity again to create one collaborative poster of the values and principles.
  4. Take a photo or keep a physical copy of the poster and display it somewhere the team can easily revisit it.

Iterative Development

A core part of Agile product development is frequent delivery of value to the customer. This means that the customer is delivered a working version of the product at regular intervals throughout development. Each version works, is documented, and can be tested by the intended users. Each subsequent version should deliver new functionality or changes which improve the product.

This “iterative” style of development is in contrast with more traditional processes where the product has its documentation specified, then it is designed, then built, then documented, then tested, then delivered to the customer. In Agile, this linear process is repeated many times, with each iteration focused on solving a smaller part of the larger project.

Agile Development Spiral

Arguably the trickiest part of this process is figuring out what to produce, and in what order, so that the product delivers value to the customer in each iteration.

Agile Manifesto

The 4 key values and the 12 principles are published as a document called “The Agile Manifesto”, which can be found here.

This document was created at a conference in 2001 by a group of project managers. They all had different approaches to project management in software, but they agreed on these key values and principles, so they published these as a guide for anyone who wished to use it.

Being an “Agile” practitioner simply means being customer-focused, adapting to change, delivering iterative improvement and valuing communication.

The “Agile Movement” consists of anyone who has decided these are good things to value, and so they work to uphold the values and principles defined in the Agile Manifesto.

This course will focus on the Scrum process, but there are many different Agile methodologies.

“Agile” itself is a set of values and principles which should apply to successful project management in most industries and most contexts. Agile methodologies provide a structured way to “be” Agile. That is, a methodology describes one way a team could organise themselves and their processes so that they can more easily follow the Agile values and principles.

Following a methodology will not necessarily make a team “be Agile”, as Agile is about values. A methodology’s role is to create an environment where observing the Agile values is part of the day-to-day routine of the team.

A few of the more popular methodologies are described below.

  • Scrum
    Time is divided into “Sprints” which are usually about 2 weeks in length. Each Sprint has a planning meeting, daily standup meetings to share progress, and retrospective meetings to improve sprint management and productivity. Key roles are Product Manager, Scrum Coach and Development Team Member.
  • Lean
    The primary focus is delivering the maximum possible value while minimising the amount of waste. Waste may be traditional physical resources, or may be employee time. Close attention is paid to removing bottlenecks in the production process. Kanban is a style of Lean project management.
  • Kanban
    Tasks are broken down as small as possible, and each task then proceeds through states of “To-Do”, “In Progress”, “Waiting” and “Done”. Kanban’s primary focus is limiting the amount of in-progress work, preventing multitasking and focusing on the continous flow of work.
  • DSDM
    Stands for “Dynamic Systems Development Method”. In this style of project management, the project is carried out under restrictions of time, budget and quality which are decided before the project begins development. Project requirements are strictly prioritised as “must have”, “should have”, “could have” and “won’t have” in order to meet the specified restrictions. There are regular releases and re-prioritisation of requirements.

All of these methodologies support an Agile process, so they all:

  • Support the 4 key values of Agile
  • Respect the 12 principles
  • Prioritise the delivery of high-value requirements
  • Deliver value in iterations