Aztek is an agile web design, devlopment, and digital marketing agency.
That means we do may do things a little different than what you are used to. If you are unfamiliar with the difference between Waterfall and Agile, watch this short video:
We strive to deliver value early and often
By working with you to determine which things will solve your problems and deliver business value first, we can practically ensure that your project will result in positive ROI for your organization.
We show you progress on a regular basis
If you've ever worked on a waterfall project, you know that it can be a long time before you see any progress or get any updates. Not with us. You'll hear from us regularly and we are constantly showing progress (and asking for feedback).
We break down complex projects into manageable chunks
How do you eat an elephant? One bite at a time. Big projects can be intimidating and it's common to lose focus with so many moving parts. That's why our team breaks the project down into right sized pieces. That way, we're all able to focus on the task at hand and nobody gets lost along the way.
We embrace changing requirements and new ideas
One major flaw with waterfall style development is it's lack of mechanisms to deal with the fact that requirements change. That's just the reality of projects. Being agile means we expect that to happen. Plus, if you have a great new idea, or discover a brilliant new technology midway through a project, would you want to ignore it just because it wasn't part of the original plan?
This all sounds like magic, how does it work in real life?
It's surprisingly simple. Here are some key ideas to help you visualize the process.
- Your project is described in the form of epics (a collection of related stories), user stories (a way to describe the things that your users can see and do). Don't worry, we help you convert your project needs into this format. This collection of epics and stories are referred to as your project backlog.
- Working with our team, you put those user stories in priority order (based on what will deliver the most value first).
- Those stories are then grouped into "sprints". Sprints are typically a two-week block of time we give ourselves to get that chunk of user stories done.
- At the beginning of each sprint we plan how many stories can fit into the sprint.
- At the end of the sprint, we demo the progress to you and gather your feedback.
- Stories are either accepted as "done", or if additional feedback or changes are required, those go back into the backlog as new issues to be worked on.
- Rinse and repeat this cycle until you decide the project is ready to be deployed into production.
If you think this sounds like a better way to work, let's talk about your project.
Ever since attending my first CodeMash in 2011, it has been my must attend event every year. Not even the bitter cold can keep