Getting started with agile can be daunting. Consultants and software vendors sell big promises about faster delivery and improved project management, but what are the real questions you should be asking? What are the traps you should be mindful of before buying Agile or DevOps “in a box”?
It’s not about software
In 1986, the Harvard Business Review looked at strong product development growth in Asia and asked why was it different, and arguably more successful, than traditional product management in the West. At its core, was a philosophy about ways of working that has become known as Lean and Agile.
At the dawn of the 21st century, the main focus of these ways of working was software. However, the popular frameworks like Scrum, are now being used by teams in any in complex environment where people need to adapt rapidly to change and gain advantage in a cross-functional team environment – finance, medical, HR, marketing, and even research and education.
It’s about teams, even for senior managers
The most common mistake is seeing agile as a project management methodology. What results is a group of people who are spread across several projects using different, often conflicting, ways of working, going to several planning and review meetings, and barely having any time to work. The context switching that results can be enormous.
Dedicated teams are 50% more successful than the traditional practice of people spread across several project teams. This focus creates greater throughput and allows members to bond go a clear goal.
Don’t apply agile to a traditional project. Instead, apply it to the way a whole team works — whether it’s the marketing team, a software development team, or even executives.
There is no “agile methodology”
Contrary to many consultants’ sales pitches there is no “agile methodology”. There are literally dozens of agile practices, several frameworks, all built on a set of four values that emphasise collaboration, transparency, and continuous improvement. The most popular framework is Scrum, but others include Kanban and eXtreme Programming (XP). For teams of teams delivering large solutions, there’s SAFe, Nexus, LeSS, Scrum @ Scale, and others.
In selecting a framework, consider:
- How quickly you need to adapt to change?
- Do your teams primarily do planned work or is it primarily demand based?
- How many teams need to collaborate on the same initiative or do they all work on independent things?
Agile isn’t “pick’n’mix”
There is a huge temptation to look at the plethora of frameworks and choose the bits you feel will work best with your organisation and its current culture. However, agile frameworks aren’t designed to be used in this way.
Just like building a house, contemporary ways of working also have frameworks. Where a house’s framework is the slab, the walls, the roof, agile’s frameworks create the basic building blocks of empiricism — adapting to change based on observation of objective, measurable outputs.

From the start, your agile framework is designed to change the way you work. Scrum, for example, reinforces shorter work cycles called “Sprints”, and review sessions to examine the outputs of work in order to learn from its delivery and get feedback on what to do next.

Choose a framework. Start with the basics. Don’t over complicate it.
Scrum is where most people start. The State of Agile Survey (2019) reports that 72% of people use it as their framework of choice. Scrum is simple, it has role descriptions, and some basic process for planning and adapting to emerging change. The secret for success with this, or any other framework, is to find someone with experience to help you apply the framework to the team’s work on a day-to-day basis. Going to a certified Scrum Master course is useful, but it won’t give you the experience you need to be successful. This is where finding a coach is very important.