Choosing the Right Agile Framework

14 October 2016

Agile has been a buzzword in the digital and software development world for almost a decade. The principles of Agile are well established and clearly defined in the Agile Manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

As it gained popularity, however, it became clear that these were values and principles, rather than a practical framework or method that software development teams could implement. Inspired by these values, organisations and individuals began developing and defining new strategies to deliver software products.

Today, Scrum is widely considered to be the most popular Agile methodology, but it is easy to forget that there are other options out there. At Big Blue Door, we believe that every project should be evaluated individually to determine what methodology would enable us to give our clients the best possible service and value for money. In our experience it is a really bad idea to force a specific Agile methodology on all projects. If you can’t apply the principles of your chosen methodology effectively and consistently, the project has the potential to evolve into a muddled mess that frustrates the development team and hampers your ability to deliver an excellent product to your client.

During our recent time at Drupalcon in Dublin, we attended a session that outlined some of the project management frameworks and methodologies that have become popular over the years. The speakers discussed the benefits and limitations of each methodology and what kind of project each framework would be best suited for.

Here is a brief outline:


Scrum is a well established methodology that helps teams deliver complex projects through fixed, incremental iterations. Each iteration is called a sprint and is typically 2 weeks long (although this does vary). The development team gets to focus on a fixed scope without interruptions. There are well defined roles (Product owner, Scrummaster, Cross-functional teams), ceremonies (backlog refinement, sprint planning, daily stand ups, sprint review, sprint retrospective) and tools (scrum board, user stories, icebox).

When to choose Scrum for your next project:

  • When delivering a large, complex project - with a clear vision of what the end product should look like.

  • When your team communicates well and is capable of self-management.

  • When your organisation has a dedicated person that can take on the Product Owner role.

  • When the whole team (client and development agency) is on board and committed to the process.

  • When stakeholders are readily available to review progress and answer questions.

  • When you are looking to deliver a minimum viable product as quickly as possible.

  • When you require set, scheduled releases.

  • When you have sufficient budget across the project for the development team and other roles (Scrummaster, Product Owner etc) required.


Kanban was initially developed by Toyota in Japan during the 1950s. It emphasises continual delivery while not overburdening the development team. Unlike scrum’s iterations, it provides a continuous, flexible stream of work. The three main principles of Kanban include: visualising your workflow, limiting the amount of work in progress (at each step), and enhancing flow (new items are continuously pulled in from the backlog).

When to choose Kanban for your next project:

  • When the project scope frequently changes due to “high priority” / emergency situations.

  • When your project requires flexibility and frequent changes to priority.

  • When the main goal is ongoing maintenance and support, often post-launch.

  • When your project requires continuous or ad hoc releases.

Feature Driven Development:

Feature Driven Development is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week “design by feature, build by feature” iterations. The features are small, “useful in the eyes of the client” results. Unlike other agile methods, FDD describes specific, very short phases of work, which are to be accomplished separately per feature.

When to choose Feature Driven Development for your next project:

  • When your project requires a “model-centric” approach.

  • When you need multiple teams working on side by side on the same project.

  • When you want to deliver a complex project one feature at a time.

  • When you want specific members of the team to take ownership for specific components.

Extreme Programming:

Extreme Programming is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals. XP places a large emphasis on pair programming, continuous integration, unit testing and code review. It essentially takes software development best practices to extreme levels. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration-by-iteration basis.

When to choose Extreme Programming for your next project:

  • When your project requires maximum flexibility and frequent changes in priority.

  • When you need multiple releases per week or per day.

  • When you need a code first approach - with extremely reliable, well written and well tested code.

  • When you need bug-free, robust source code.

  • When your project requires test driven development.

If you have a project coming up why not get in touch with us, and in the meantime review the range of services we offer.