Are you getting Agile right?

Agile methodologies have been around for more than 15 years and they have become mainstream in the software development business. People have become comfortable discussing Agile principles and are now familiar with terms such as: daily scrum, the backlog, sprints, and iterations. On top of that, there are now numerous institutions giving out Scrum Master Certifications, which definitely look good on your CV! However, after deeper analysis on how your team functions in real life situations, you can perhaps find some differences with what Agile suggests you should do, and what you are actually doing:

  • Does “Agile” in your company really mean “waterfall with daily meetings”?
  • Are daily meetings long and tedious, filled with detail on every problem and possible solution?
  • Are your sprints actually just your general project plan divided into 1 month milestones?
  • Is the backlog really the full list of stabilized requirements?
  • Do you avoid changing requirements no matter what?
  • Are all projects managed the same way? Do they all follow the same process?


If you answered yes to one or more you are probably not implementing Agile correctly.

Software Development “Engineering”
“You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new.” ---Steve Jobs

Engineering disciplines, such as civil engineering, have the advantage of getting very detailed requirements from the beginning. For example, before building a bridge, the engineers know the height, length, from where it needs to go and where it should end, how much weight should it handle, expected traffic, the construction materials, etc. The civil engineer doesn’t expect after having built half the bridge to get a change in the required length.  Also, a very detailed plan can be sketched before starting: what needs to be done first, how many people should work on each milestone, what materials are needed, etc. It’s rare for the plan to change significantly while building the bridge. 

When software development projects started in big corporations, some decades ago, the same approach was used. Software projects were supposed to start with a set of well defined, stable requirements that would not change during the project. A project plan was created based on the permanent requirements and then the design, development, and testing phases were done one after the other. It is easy to conclude that, with this kind of mindset, the first measure of success is if the project went according to plan. 

Change Embracing Software Development
"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change." ---Charles Darwin

Experience showed us that requirements can and will change during the course of a project, and, because of this, several techniques were developed to try and minimize changes to the requirements before starting the other stages of the development process. These techniques were mostly unable to capture all of the requirements up front, and most software projects continued to change requirements late in the project.

Agile, on the other hand, assumes that requirements will change and that there is no way to stabilize them. This means that changes will continually be evaluated and the project plan will need to be updated for each approved change. Since the plan is constantly changing, we need to find other ways to measure the success of the project, for example: delivered business value, change velocity, solving domain problem, etc.

People Over Process
"None of us is as smart as all of us." ---Ken Blanchard

Another major difference between Agile and traditional methodologies is that Agile is people centric rather than process centric. The traditional way focuses on the process, i.e.; a series of steps to create a product. In each step, one or more resources come together to do some work and then feed the next step of the process. This means that people get slotted into specific roles (developer, QA, BA, sys admin, etc) without taking advantage of individual strengths they may have. 

Agile is people centric because it understands people have strengths and weaknesses. With this understanding, a highly skill team will organize, and determine on its own, how it should work in order to deliver a product on time and on budget. A good Agile team will take advantage of everyone’s strengths to create a process that makes sense to them. For example, someone can be good at QA and also at gathering requirements. Giving the team ownership over the process also gives them the ability to continually evaluate and improve it.

Final Word
Agile is so mainstream that many companies and teams think that having a Kanban board or a daily scrum makes them an Agile company or team. Dividing the entire project plan into one month sprints but not readjusting the plan every time something unexpected is not the Agile way. The reality is that Agile requires a deep change in how projects are approached and how the work is actually done.