
This post is part of a series of learning topics presented by technology experts. Today’s post comes courtesy of Tony Keller, Head of Technology at Powerwrap Limited and architect of the Powerwrap Delivery Framework. This content comes from a recent training session delivered by Tony in our workplace.
What is Agile?
In the 1990s, many software development projects were failing or taking much too long to complete, and industry leaders realized they needed to find a new, innovative approach. Agile is a software delivery concept developed to provide a more flexible and efficient way to get products to market faster based on the concept of ongoing waves or sprints of project planning and execution, enabling you to continuously adapt and mature your plan, scope, and design throughout the project.
Agile methodology is an approach that uses 4 key values and 12 principles to organize projects.


Is your company agile?
Plenty of companies claim to be agile. Here is a quick set of questions you can pose to check:
Agile company self-check:
- Are stakeholders active participants in development?
- Is the team producing high-quality, working software on a regular basis?
- Is the team working in a highly collaborative, self-organising manner?
Let’s break that down:
Stakeholders as active participants
Your project stakeholders can and should participate in the development process. Minimally stakeholders should be involved on a daily basis, they should provide information in a timely manner and make decisions in a timely manner. I should be able to ask the team to introduce me to their stakeholder(s) and they should do so right there on the spot.
Regular software production
The team should be able to show the working software that they’ve built to date as well as the source code. The code should be consistent because it will have been written to conform to a common set of guidelines and the team will refactor whenever appropriate to ensure that it remains of high quality.
Collaborative, self-organising work-style
Agile teams employ the most effective communication strategies available to them, this often means that they don’t write detailed specifications and throw them over the wall to each other, and they plan effort instead of having a project manager do it for them.
Times NOT to use agile
Let me just insert a quick comment here, that YES we know “agile” is not a methodology nor a blueprint, but is rather a set of values and principles. BUT we all use common short-hand in speech and writing, and “being agile”, and “using agile” are examples of those. So… is it ever better NOT to use agile methodologies?
Sure – there are no hard and fast rules, there is only what works best for your organisation, and your particular project. Some times where it might be better not to use an agile approach include:
- The outcome of your project is stable and understood. Example: you are implementing third party software with clear and known parameters.
- Your project must produce a repeated deliverable. Example: financial transactions that must be absolutely predictable and reliable every time.
- Your customer doesn’t want Agile
- Your company cannot support Agile
If your company cannot support agile, then setting up an agile framework will not work.
What is Scrum?
Scrum is a framework you can use to implement Agile values, principles and best practices. There are other Agile frameworks, but the most common are:
- Scrum
- Kanban
- XP
Here is how ScrumAlliance defines Scrum:

What Scrum isn’t
Importantly, Scrum is a product-delivery framework, not a project management framework. It is not designed to include some components of traditional project management, such as risk and issue logs, decision logs, communications plans and so forth. (In theory, you can build some project tasks into sprints, but in practice they are usually best managed separately, when they are needed).
Benefits of Scrum
The benefits of Scrum are in its well-defined framework and in continuous delivery. As the methodology is very well defined it can be “plugged in” as long as the company is serious about supporting it.
It is generally well-liked by developers as it gives the team autonomy and it produces working software quickly.
Scrum benefits
- well-defined framework
- allows focus on HIGHEST BUSINESS VALUE in the SHORTEST TIME
- allows for RISK MITIGATION via ‘inspect and adapt’
- fast, continuous delivery reduces the cost of delay
Scrum Basics
Scrum fundamentals:
- Scrum consists of 3 roles: Product Owner, Scrum Master and development team
- Uses fixed-length iterations called Sprints ranging from one week to four weeks (or 30 days)
- Small teams: ideal team size is 7 plus or minus 2
- Aims to build a potentially shippable product or feature by end of each sprint
- Daily stand-up: meeting should be only about 15mins, and team should stand
Estimation
Tasks are broken into stories. All the members of the Scrum team join together in planning to estimate story size.
Planning Poker is a common technique used to get consensus on a story size. Story points are used for relative story sizing, rather than time, which tends to be less accurate.
A Scrum team will have a number of points it knows it can complete in a sprint, so this exercise decides what the the team agrees to complete in a sprint.
T-shirt sizing (Small, Medium, Large, X-Large) and story points are more accurate than estimations based on time, as they measure size of stories relative to each other. As teams work together longer, their accuracy in story point estimation and the number of story points they can deliver in a sprint, increases, as does their sprint velocity (speed at completing stories). (However, there is plenty of debate in agile circles around the usefulness of velocity).
Roles
Key roles in Scrum are:
- Product Owner
- Scrum Master (or Scrum Leader)
- Development Team


- Development team: decides how to deliver the work prioritised by the Product Owner. Teams are cross-functional, meaning all the roles required to deliver the sprint, are represented. Scrum itself does not recognise any sub-teams or titles within the team; everyone works together to get the work done.
Sprints

Scrum overview

Scaled Agile
This is where things get fun 😉

Is there a Scaled Agile framework?
Well yes, there are several. The most well-known [notorious? :)] is SAFe, but the choices include:
- Nexus: A framework with roles, events, artefacts and rules to bring together the work of approximately 3-9 Scrum teams working on a single product backlog to build an Integrated Increment that meets a goal
- Large Scale Scrum (LeSS): Adheres very closely to Scrum. LeSS and LeSS Huge. LeSS is for groups of 3-8 Scrum teams with no more than 8 people in each. LeSS Huge can scale up to a thousand people on one product. Focused on directing the attention of all teams onto the whole product instead of “just my part”. In LeSS, all teams are in a shared sprint to deliver a common shippable product every iteration
- Scrum @ Scale (S@S): Goal is to achieve scalability by enabling multiple teams to operate as efficiently as a smaller group. Uses Scrum of Scrums, Executive Action Team (organisational structure and performance) and Executive Metascrum (enterprise priorities, revenue and profitability)
- Disciplined Agile Delivery (DAD): A hybrid approach which extends scrum by incorporating best-of-breed elements from a number of different frameworks including: Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, SAFe, and LeSS. Instead of being a prescriptive methodology, DAD takes more of a pragmatic, goal-driven approach
- Scaled Agile Framework (SAFe): Unlike DAD, it is highly structured and prescriptive. SAFe provides very specific structure and guidance for all levels of the enterprise that are actively engaged in solution development: Team, Program, Large Solution, and Portfolio. Mastery of the five core competencies for the Lean Enterprise included in SAFe empowers organizations to successfully navigate the transformation to Lean, Agile, and DevOps.
SAFe
SAFe has 5 core competencies:

The SAFe framework:


What’s the difference between “Agile” and SAFe?
Agile practices are a group of behaviours and techniques that use an empirical approach to deliver as much business value as possible in a given amount of time. “Agile” is a broad term that covers a number of different methods. Agile, in fact, is a way of thinking.
SAFe is an acronym for the Scaled Agile Framework, which is a branded version of a scaling model. Other scaling models include Large Scale Scrum (LeSS) and Scrum@Scale. Scaling models add extra layers of communication and controls to allow people to use agile methods (like Scrum) with very large groups. It is an attempt to take Scrum/ Kanban/ ScrumXp and make it work in large organisations with lots of teams working on the same product. SAFe defines an approach for scaling lightweight methods to an enterprise level and dealing with some of the challenges at that level that a team-level process based on Scrum does not address.
References
If you want some good overviews of Agile and Scrum, start with:
Scaled Agile frameworks:
- https://www.scaledagileframework.com/#
- https://www.scrum.org/resources/nexus-guide
- https://less.works/
- https://scrumatscale.scruminc.com/scrum-at-scale-guide/
- https://disciplinedagileconsortium.org/Disciplined-Agile-DAD
Scrum certification:
- SCRUMStudy offers free Scrum Fundamentals certification which is well worth doing. It includes a four-hour webinar training session with short test questions, downloadable course materials, a downloadable version of the Scrum Body of Knowledge book, and an active LinkedIn group.
And if you want to learn more about Tony, say hi on LinkedIn!