3 Paradigm Shifts of Agile

Our Agile Training curriculum around General Agile Principles and Practical Agile Competencies cover the standard paradigm shift in Agile related to the traditional triple-constraints of project management. There are two other paradigm shifts I think are worth noting an understanding to help guide Agile Transformation.

Three Paradigm Shifts of Agile

  1. Triple-Constraints of Project Management (aka – The Iron Triangle)
  2. Traditional vs Emergent Requirements
  3. Project Managers vs ScrumMasters

Triple-Constraints of Project Management (aka – The Iron Triangle)

In traditional project plans the customers tend to ask for everything in great detail up-front, and we fix that list of requirements. Based on that list of “asks” the development team then determines the amount of time and budget it will take to fulfill the request. Project Management guidelines tell us that to be successful with a project that a customer may specify any two value of the iron triangle as long as the development team keep control of at least one, so it is not common for customer’s to specify with great detail not only all the requirements, but also either the date they need it or how much money they have to spend. And while there may be a bit of negotiation, the downside of this approach is one we know well. As soon as we make it though the gating step or phase of the project where all three aspects of the triangle are specified – they all become fixed. And if we know is change is to be expected within a project, this only sets us up for failure.

An Agile approach to a project is much more thoughtful about the cadence of the project. How long are our iterations (we fix that), who is on the dedicated cross-functional team (fixed run-rate budget), and what is the vision of what we are trying to achieve. We then pick a release planning approach (See Agile Q&A: When Can we Release?) and move forward keeping the team and the sprint as sacred as possible. That leaves us the ability to focus our cognitive processing ability not on managing change requests, re-baselining project plans, or updating requirements documents – but instead we are focusing on delivering the right thing (not just the thing that was written down).

Traditional vs Emergent Requirements

As I alluded to in the previous section, in traditional projects all the requirements of a project are specified upfront at a very precise level of detail. And because our projects are set up for failure having fixed the scope, cost, and time – when we start coming close to the end of the timeline or the end of the budget we inevitably have to de-scope something so we leave inventory of the table and deliver less that what we originally specified upfront. This is a significant waste within software development and is a key driver of why there are trust issues between business and IT groups.

Instead of specifying everything at great detail upfront and delivering something less, an Agile framework turns that upside down. We want to focus first on a very well defined Vision, decompose that into Themes (large chunks of functionality), and based on the priority of those Themes start elaborating more specific detail of the features, and then the highest priority features into stories, and the highest priority stories into technical designs and ultimately working software. Doing all of these through emerging requirements and a just-in-time mentality. So at the end we have ended up not only with a similar amount of detail as a traditional project would have started with, but more importantly, and accurate set of details and understanding for truly valuable working product.

Project Managers vs ScrumMasters

If we think about the traditional Project Manager / Team dynamic we often think of the Project Team working for the Project Manager, thus the Project Manager is on the top of the food-chain. That person holds all of the details, assigns all of the tasks, and is ultimately accountable for the success of the project. It tends to be a very Command & Control framework.

Agile, on the other hand doesn’t require a Project Management role. Instead we look to the role of ScrumMaster. And ScrumMasters work for teams. Teams that are self-organizing and cross-functional. Teams that are in control of their own destiny and ultimately their own ability to succeed or fail. Instead of command and control, ScrumMasters act as Servant Leaders that insulate the team from distractions, remove impediments, and provide the tools and resources needed so the team can maximize success.