My only previous exposure to the development world fell within a waterfall-style format. It has been inspiring to learn about the Agile method and the ways in which Substantial and other forward-thinking development teams work to achieve their goals and solve problems. It is exciting to be learning about working in this way and integrating the principles into my own development practices.
The Agile method provides solutions to some major problems that are encountered in a software development environment. Here are a few of the problems that I have noticed.
Planning out our ideas for our Midterm project has been a fantastic show of how an unknowing client/person can try to do ALL OF THE THINGS and set far too large of a scope for a project. In the beginning, we wanted to develop an tool that could be used between personal trainers/nutritionists/wellness physicians and their clients/patients to be used as a wellness plan tracking system. It would have a built-in workout guide module, a nutrition tracker, community forums, messaging between the physician and their patients, and much more.
If we had tried to solve this problem with the waterfall approach we may have dived into too much too soon without knowing if we had the programming capabilities to solve these problems within the near future. After communicating amongst our project group with peers that have a better understanding of the technologies that will be used to create product, we decided to narrow our scope to a very specific audience and purpose. Instead of building a big and complex product, we plan to build something that can stand on its own or it can be integrated with other modules to be created in the future.
One of the most important aspects of the Agile approach is that problems are solved by the whole team. The waterfall method makes all of the information architecture and design decisions before the code is even touched. This is hugely problematic because very often visual designers don't fully understand the development capabilities that will be used to build the product that they are designing. I speak from experience because I have been one of those unknowing designers who was creating website templates in photoshop to be shipped off to the development team.
When a visual designer doesn't know how to use all of the tools in the development toolbox, they might miss out on a really awesome way to solve a problem that they didn't know existed. When designers and developers work together to solve problems, more technologically sophisticated solutions can be utilized. Instead of just trying to make something that looks perfect, we should be trying to make something that works.
Clients shouldn't be so far removed from the products that they are paying to recieve. That isn't to say that they should be hovering over the shoulders of the developers of their product, but they should be more included in the steps involved so that they more fully understand and appreciate what they are paying for. When clients pay a development team to create a product, they want to be empowered in their decision to spend that money.
They are paying us because they can't solve a problem and we can. The best way to solve these problems is to brainstorm as many solutions as possible and test them with real users. We won't know the best solution until we test it. Developing with Agile allows lots of testing and creation of usable modules that evolve together to create a truly awesome product that we know will be successful before it even it hits the market.
All of these reasons and more are why I'm excited to be learning about this methodology and implementing it in my future career. Many thanks to my teachers, Dale Sande and Dexter Lesaca, for continuing to fill our brains with knowledge about best practices in the UX Design world.
Written by Maggie Walker as part of the UX Design and Development Accelerator at Code Fellows in Seattle, WA
I found out about all this awesome stuff here: Doing UX in an Agile World, Scrum Methodology, Agile Methodology, Scrum Reference Card