By ADB|2023-02-27T17:12:41+00:00April 28th, 2020|Categories: What is Agile|Comments Off on An Introduction to Agile
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 frameworksto 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
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 solutionincrement – 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 functionalperspective
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
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.
Hello, I’m Alun - the founder of Altogether. I live in London and I’m a coach, trainer, and facilitator. I have worked for over 25 years in and around business teams, projects, and programmes. For the last 15 years the majority of my work has been related to agile ways of working and organisational agility. In that time, I have been inspired by teams and individuals endeavouring to develop and change for the better.