Agile Methodology

It's 2:30pm and I'm plowing away on a competitive analysis presentation, and here comes the creative director.

“Dan, can you to do a presentation educating the creative services department on what Agile Methodology is at our meeting later this afternoon. I’m not too familiar with it. Thanks man! Oh and by the way, the meeting starts at 3pm. I know man, I’m sorry, I owe you a BIG ONE!”

Sweet. And for the record, my CD and I are very good friends and partners in crime, UX + Promotions Design, you get the picture. I couldn’t say no, besides, I genuinely did want to help with whatever I could. Now as the UX professional, I struggle with whether I should go into detail about Agile UX, but decided with the short timeframe I had for preparation, I decided to do a simple overview of Agile and the Scrum process we primarily use at our company. I did not attach the keynote presentation mainly due to embarrassment, and how limited it was in presenting the information without me giving context.



Ah yes, the waterfall method. The traditional process of design + development teams. Complete onephase before moving onto the next phase. It sounds like it should work, why not right? Let’s finish one phase so we don’t have to go back to it. If only it were that simple. Some of the issues of this process are:

  • You rarely aim to re-visit a ‘phase’ once it is completed which essentially means, you better get whatever you’re working on right the first time.
  • Requires end-to-end requirements for the entire project at the Requirement analysis phase.\
  • You don’t realize any value until the end of the project.
  • The requirements get too long, causing misunderstandings and missed requirements
  • You leave the testing until the end.
  • Very high risk, often more costly, less efficient.


The Agile method is a type of Incremental model. Software is developed in incremental, rapid cycles. This results in small incremental releases with each release building on previous functionality. Each release is thoroughly tested to ensure software quality is maintained. It is about individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

  • Methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.
  • Promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.
  • It is a conceptual framework that promotes foreseen tight interactions throughout the development cycle.



Scrum being an agile process tool we frequent at my company, I had to make sure I touched on it as well. Because we were already running small, cross functional teams within our company, explaining scrum was fairly easy and didn’t require a lot of additional information. Scrum is a lightweight agile process tool used by many teams. The method is to split your company into smaller cross-functional teams that include (in our case), a scrum master/PM, design, development, QA, product owner. The work then is split into a list of small, concrete deliverables. The list is then organized by priority and estimates are made by the team to understand approximately how much of an effort will be needed to finish each item.

The method is to split your company into smaller cross-functional teams that include (in our case), a scrum master/PM, design, development, QA, product owner.

The method is split into short fixed length iterations/sprints, for us is 2 weeks, with potential ship ready code demonstrated at each iteration for review. After each process, a retrospective is held with the whole team to go over what went well, what went wrong, and what areas can be improved.

So in summary, this process helps because now instead of a large group trying to collaborate and building a big feature, we have smaller teams working together on smaller tasks. And the benefit of these teams, they are cross-functional, so every department that is needed can be included throughout the entire process. The smaller teams will also integrate regularly as a whole group to go over what each team has completed.

So that is a very brief overview of what I went over in the presentation, and of course with speech I was able to touch on some other finer points of the agile and scrum process. The feedback from the team showed they were given a good overview of agile methodology and they could all say they had a better understanding of it. Yeah, it wasn’t a thorough course of Agile, but at least I was able to do my job and help the creative services team.

Photo credit to WDL