What is Agile?

Organizations are increasingly using the term Agile to mean all manner of things.  Teams frequently misunderstand the reasons to adopt Agile ways of working.  Typically, managers interpret Agile as, ‘do more, with less’ and ‘deliver more quickly’.  I hear things like, ‘we need to have a Scrum to fix this issue’ or, ‘we need to be Agile to deliver this everything being asked for’.  This post will explain what is Agile in generic terms and drill down into more detail in subsequent posts.

Characteristics of Agile Approaches

There is quite a selection of Agile frameworks to help teams ‘do’ Agile.  However, using an Agile framework does not an Agile team maketh.  In reality, Agile is a mindset adopted by teams to focus on two aspects:

  • Delivering maximum customer value e.g. by product delivery
  • Being the most effective team via continuous improvement – people and process

Agile teams accept that an appropriate solution may not be clear.  Therefore, the team set out to discover the best solution with an adaptive approach.  The whole team is collectively responsible for what is delivered and how it is delivered.  Agile values and principles shape team thinking and behaviours.  The exact framework and techniques used are less important than delivering maximum value.

Looking across different Agile 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 processes
  • Continuous improvement

Customer-Centric & Value-Driven

All Agile approaches are customer-centric and focus on understanding and finding solutions for real problems.  If a team does not understand the real problem how can they deliver real value?

  • Teams focus to deliver real value while avoiding ‘waste‘ – an overlap with Lean thinking
  • Therefore, teams prioritize to focus activities and use short feedback loops to check the solution is evolving correctly
  • As a result, stakeholders 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 – the top 20% of the requirements, will deliver 80% of the value
  • So, if things take longer or there are unforeseen difficulties, lower priority work may drop off the list for that time period

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 self-organize to meet a goal without going up the chain of command for permission.

  • Teams are cross-functional with business and technical roles and common goals
  • All the required skills and competencies to build the product exists in the team.  Dependencies on other teams are minimised as much as possible
  • 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
  • Day-to-day the team decides how to organize and how to create the solution to meet their common goals
  • Team members pull tasks to work on so a manager does not allocate tasks 

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 confirms or improves understanding of business needs 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‘ – it is ‘done‘ and usable although  not necessarily deployed to live use
  • Some teams will make many ‘micro-deployments‘ – perhaps thousands daily – while others may release every quarter

Transparent & Iterative Process

Agile teams collaborate to create solution increments and other artefacts/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
  • A further cycle is executed if the increment is not right from a technical or functional perspective
  • The team creates to fulfil a pre-defined ‘definition of done’.  This is a checklist of criteria for the increment to be complete or ‘done’
  • Other artefacts 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 difficulties, demonstrate 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.