Agile like a project, not like a gazelle

How do you scale agile for large projects ?

This article takes a look at agile as its grown and matured and how it can be applied to large scale projects.

I recently attended the Structured Agile Framework conference in Whitehall on behalf of BMT to take part in the discussion about how Agile, which is usually used in smaller software teams, can be scaled to support large delivery projects.  How large could agile scale?  The Square Kilometer Array project (SKA) is using scaled agile with 11 countries co-operating to build the largest telescope in the world.  The project is so vast it spans the planet and processing an astronomical* amount of data under the harshest of desert conditions!  The SKA produces 3‚000 petabytes of data each year‚ more than 10 times CERN has produced in the last seven years, all managed through Scaled Agile.

Keynote presenters at the conference included MasterCard, Gibraltar Financial Services Commission and the aforementioned SKA project. While global financial services are interesting, the SKA project really captures the imagination how agile can be scaled up to huge sizes for software and non-software elements of a project.

This blog is a blend of all the lessons learnt from this conference and a reminder of some of the lessons I have learnt about agile in the past few years.

Firstly, it is important to remember that working with agility is more than just working in sprints. I’ve come across a lot of people who say they “work to Agile” but it soon transpires what they actually mean is they leap and bounce around the place trying to survive long enough to succeed.  This is what I call the Gazelle interpretation of agility and I’m sure you’ve encountered project managers who operate like this.

Working Agile (if it ever should have a capital A) should be more like a group of people with a range of skills and experience, with regular points they can change direction and there is always forward progress.  With agile everyone can see how that progress is going.

A reminder of the agile values:

Individuals and Interactions Over Processes and Tools

Working Software Over Comprehensive Documentation

Customer Collaboration Over Contract Negotiation

Responding to Change Over Following a Plan

How closely do you work to the original agile values?

Here are some lessons I’ve learnt about making sure the people you are working with understand the difference between working to the agile values or being agile.

  • At the start of a project take the time to explain the agile values. This makes sure you don’t have an agile gazelle on your hands with a bucket load of tools and agile processes.
  • Appeal to their Ego, its a good way to convince them to step away from the old-fashioned waterfall model. Explain the benefits of being able to still see steady progress.  Show them explicitly how to follow the work that is being completed and how the sprints work.  Agile is about transparency as well as continuous delivery and a plan that can be adapted as needs evolve.
  • When meeting for a software demo, ask them to explain what they expect to see.  Going into a demo shouldn’t be like an Apple Keynote full of surprise new features.  If they’ve been following the work, as a good product owner would, they should know whats happening.  This gives you confidence they know how to monitor progress and have been doing so.  If they cannot express what they are expecting to see, check they know how to monitor progress.  (Search for the the Pig and Chicken analogy if it seems like they’re not engaging).

SAFe – Scaled Agile

While the values of agile have proven their worth time and again on projects, it can become difficult to manage this when handling larger projects so a bit more control needs to be in place.  To deliver this SAFe steers away from the pure “Individuals and Interactions Over Processes and Tools” to adding some level of tooling and process, while still giving the individual deliverable teams agility.

The SAFe framework specifies the roles of everyone on large projects and creates the right checks and balances to keep the project moving in the right direction.

You can see the SAFe Framework at:

The large info-graphic on that page is clickable so you can discover the roles and responsibilities of each person in the framework.  The framework itself is scalable, so smaller projects follow the ‘Essential’ SAFe Framework.

A few key points with SAFe

Here are a few of the general points I picked up during the presentations and discussions at the SAFe conference.  Most of these are already adopted as standard ways of working with tools and techniques that have grown around the agile values, some are specific to agile at scale with SAFe;

  • For larger projects, instead of component teams (team of developers, team of test etc.), teams are placed together as feature teams. A feature team is made up of developers, tester, UI designers all working together, physically together if possible. The teams aim is to deliver the feature they have been tasked with as part of that programme iteration.  Across a project, these teams could flex in their numbers and team members may even change to form new teams at the end of a feature sprint.
  • Requirements gathering is done “Just In Time” instead of creating large requirements documents and maps. The enterprise architect may be creating overall project diagrams to show the flow of users and data through the product so features will integrate and work together.  The detail of the next sprint shouldn’t be in a mammoth specification document.  The user story is the short and punchy deliverable that expresses what the feature should accomplish.
  • Programme Increments should be feature complete and able to be released.
  • Program Increments are delivered instead of Releases. This fixes in everyone’s mind, including the end user, that the development of the software is an incremental task.  These  are internally managed and set at program increment meetings which involve everyone.
  • Program Increments should be adequately spaced apart to avoid change fatigue from the users.  Just take a look at your phone app store updates and you can spot the companies that release after each sprint as the update notes just say ‘bug and stability fixes’.  If the program increment is complete it should be bug free and stable so what is released has the new features.  We’ll get onto tech debt in a bit.

Estimating project and sprint work

  • Pricing a project is done through effort or scrum points and not through people.  A customer isn’t buying four level 3 engineers and a tester, they’re buying a feature.  That should be what is priced.  Doing this through points being allocated to the amount of effort is a good way to abstract people away from cash, remember to include testing and sprint management time for planning and retrospectives.
  • When measuring the amount of effort, ensure you measure the actual effort and do not mistake effort for difficulty. For example a time-consuming task might require lots of effort but is low difficulty.  To get started on this you can convert money to points, so £50,000 might equal 1000 points internally.  Planning Poker is ideal for this, it takes very little time and helps the team calibrate on the effort required.  Always include testers and product owners in this so they can understand the effort, they often learn from the developers what might seem easy on paper in reality isn’t !
  • Technical Debt is rarely understood by the product owner.  Allow time to address these items in planning and try to find non-technical ways of explaining it so you get their support.

Keeping people on-track and motivated

  • Internally promote feature completion.  A weekly or fortnightly summary to the department of the individual features completed across the projects everyone’s working on helps keep everyone informed about the work going on around them.
  • The change curve applies (like always) to new ways of working.  Be ready for people to be at different stages of the curve. For example, you could have someone saying they are Agile, but they are in denial, easily demonstrated by them asking for a future looking Gantt chart totally ignoring the Agile methodology!  Others could be disruptive in the meeting (anger in the change curve) especially if they feel they do not have as much control as they may be used to.
  • If people are a behind on the change curve, keep a cool head and demonstrate they have been listened to.  Try to use the people who are further ahead to bring their colleagues up to speed.
  • If you are switching to agile, baseline your current performance. Look at burn-down charts of tasks and predictability of work.  Predictability is consistently hitting your sprint goals. In other words, the team routinely estimates work well, defines sprints that have the right amount of work in them, and then delivers that work to quality standards.

The number one tip for holding planning or programme increment meetings is to make sure everyone is actively involved that has a stake in the success of the feature.

  • You cannot beat post-it notes and pieces of paper when doing a quarterly programme meeting to plan the sprints. Using smart-whiteboards or Trello on a screen can be a challenge to keep the session alive and people involved and therefore coming up with creative solutions.  Remember:

Data entry is not a spectator sport


Scaled agile offers a controlled and structured framework.  While its challenging for classical project managers to adapt to, it’s should be acceptable as it has clearly allocated ownership and responsibilities.  In truth this adds some layers of bureaucracy which is unpalatable for agile purists.  If you want to learn more search for ‘Agile is Dead’, there is both a blog article and a video from one of the agile principle creators.  It serves as a reminder to take agile back to its roots and not get caught up in Agile with a capital A and to not drown under tools and processes.


*puns are always allowed.

Leave a Comment