What is Agile?

Buzzwords have existed since somebody first wanted to label something they didn’t understand.  Nowadays, teams need to ‘be’ Agile.  In reality, this means ‘do more, with less’ and ‘deliver more quickly’.  However, what constitutes a suitable Agile approach will change according to business needs and the operational context environment.  In this post, I aim to explain Agile in generic terms.  Later posts will drill down into more detail.

Characteristics of Agile Approaches

So, let’s start by trying to answer the question, ‘what is Agile?’.  There is a raft of frameworks to help teams ‘do’ Agile and we shall explore these later.  As much as anything Agile is a mindset adopted by teams when they approach the work in hand.  Agile is most suitable when there is a high degree of uncertainty around how to meet a particular vision.  In this case, teams need to take an adaptive collaborative approach to work out an appropriate solution.

If we look across different frameworks we see patterns in terms of the organization and behaviours.

  • Customer-centric and value-driven
  • Self-organizing & empowered teams
  • Frequent incremental delivery
  • Transparent and iterative
  • Continuous improvement

Customer-Centric & Value-Driven

What is Agile - Prioritisation

All Agile approaches are customer-centric and focus on understanding and finding solutions for customers’ real problems.

  • This enables teams to deliver real value quickly while avoiding ‘waste‘ – a definite overlap between Agile and Lean
  • In practice, teams prioritize and use short feedback loops to understand where to focus activities, and if the solution is correct
  • A key point to understand is that stakeholder might not get everything they ask for, but should get a quality working solution
  • Teams sequence work by priority, starting with the top priorities before lower priority work
  • The Pareto Principle applies, i.e. the top 20%, or so, of the requirements, will deliver 80% of the value

Self-organizing & Empowered Teams

The team responsible for delivering a solution are self-organizing and empowered to make decisions within their area of expertise. Teams have the freedom to organize to meet the goal without going up the chain of command for permission.

  • Teams are cross-functional with business and technical roles and common goals
  • There may be a leadership role to help the team understand and follow an Agile process.  Typically, they have no direct management authority e.g. a Scrum Master
  • A role is empowered to make solution decisions from a business perspective e.g. a Product Owner
  • On a day-to-day basis, the team decides how to organize themselves and how to create the solution to meet their common goals
  • Work tasks are not allocated to team members by a manager, rather members pull appropriate tasks to work on

Frequent Incremental Delivery

Agile teams focus on the whole solution and aim to deliver a solution increment – a working slice – as early as possible.  How teams go about this will vary by team, solution and business context.

  • Teams work in timeboxes of 1-4 weeks – in Scrum these are Sprints
  • Each timebox has a goal to deliver a new product increment of valuable functionality and not technical components
  • Feedback on each increment aids understanding and informs what to do next
  • Incremental delivery potentially means early business benefits and ROI if released to live use
  • Each increment is ‘potentially shippable‘ but not necessarily deployed to live use
  • Some teams will make many ‘micro-deployments‘ – perhaps thousands daily – while others may release every quarter

Work iteratively

Agile teams collaborate to create solution increments and other artifacts/products in an iterative (cyclic) fashion.

  • Teams validate each increment before delivery, from a business perspective, to confirm priority
  • Work is in short cycles to design, build, and verify each increment i.e. review and test
  • further cycle is executed if the increment is not right from a technical or functional perspective
  • The team creates to fulfill a pre-defined ‘definition of done’.  This is a checklist of criteria to be met for the increment to be complete or ‘done’
  • Other artifacts e.g. the Product Backlog or Release Plan can also iterate as knowledge and understanding grow
  • With invited stakeholders, the team review the evolving solution at the close of each timebox e.g. a Sprint Review
  • The team inspect the product increment, discuss issues and difficultiesdemonstrate the solution, get feedback and gauge overall progress
  • It is not possible to work is such a way without a cross-functional team or buy-in to the approach by the wider stakeholders

Continuous Improvement

Periodically, within a project or during solution delivery the team should reflect on how they are going about their work.  This event is a retrospective.

  • Ideally, each timebox ends with a retrospective immediately after the timebox review
  • The review is about the solution and progress
  • The retrospective is about the team and how they might improve and be more effective
  • All team members – business and technical – should attend
  • A positive facilitated approach – there are many – works best to ensure everyone has a fair say and it is focused on improvement rather than blame
  • The Scrum Master is likely to facilitate.  Part of the role is to hold a mirror up to the team and aid reflection
  • The team can focus on making an incremental change to how they work during the next timebox.  Over time these changes build up to improve team effectiveness and agility

To summarise, there are general characteristics common across different Agile frameworks.  Best practice and out of the box solutions do not exist.  Teams should understand how Agile can work for them in their particular circumstances.  The next post will look at different Agile frameworks that could serve as a starting point.