Article summary
What does it mean to use an agile or waterfall approach to software development? What makes it different for the client? Where does it make the most impact for your project?
Leading Up to Atomic Object
The keyword here is agile, and what it means to me (a designer) working in an environment founded on its principles. Before Atomic, I spent a long time inside the walls of a global financial company. I worked with a PMO team that mandated a waterfall approach (and for good reasons), where the majority of the interface design was produced in high-fidelity screens before any coding began. Often, this meant that a different team (sometimes even off shore) would be implementing the front and back-end code for the designs that I produced. I found it difficult to guarantee a level of perfection to the implementation quality desired. This level of detail, if broken in too many places, can make or break the overall product (i.e. brand) experience.
I took care of any research, design and planning that led up to obtaining approval to move into execution. There were many opportunities for roadblocks in a project, including but not limited to, time, budget, miscommunication, dissatisfaction in design quality or scope creep. I ran into many of them and overcame hurdles aiming ultimately to ensure a quality product could be produced within the project constraints. I needed to design several processes that helped instill discipline into many depths of the software development process like producing detailed documentation, effectively articulating the design and requirements of the app. I found breaking points in the process that needed to be re-factored, which gained us efficiencies within flow and design translation into production code. I needed to define a process that satisfied the internal approval requirements, kept the stakeholders involved while maintaing flexibility to work more iteratively with our development and project teams.
What I’ve realized since being at Atomic, is that this knowledge had equipped me to fit into an environment practicing within an agile development methodology. It’s good to keep in mind I’m writing in retrospection. We cannot express what our daily lives as designers and makers might look like to an audience, or paint a clear picture of what our team and project structure or dynamics may look like. But what I do know, is that creativity is mandatory to build the right process based on the makeup of the team and nature of the project. It will always be different, and need careful re-alignment, but should always be based on best practices and what is known. Understanding the core values that drive your team when making products is very important. Those are key values that should be holistically-known and adopted at a high-level in order for the team to operate gracefully.
Why Agile Works for Me
While there many factors that go into weighing which process may be right for your team, below are a few of my own observations to consider as benefits to working with an agile project team.
1. Fluidity in Workflow
- Working near developers is a consistent point of validation for me as a designer. At the instant a new idea pops in mind, I can walk over and validate the feasibility and assess risks or constraints the idea might impose on our project, from system stress all the way to project or budget balancing.
- Agile teams need to remain close in proximity, aware and accessible for team feedback when it’s needed most.
- As a metaphor, “waterfall” suits the old approach well. If a comparison were applied to agile, I’d label it “stream” or “creek.” There is a steady flow of movement with pockets of small rapids, where value is realized in more condensed amounts.
2. Delivering Value More Often
- Using an iterative approach, you can break off sections of the backlog to design and implement into a prototype, in order to stage a platform to obtain user feedback.
- There could be several points within an iteration cycle where the client is involved, whether as a springboard for questions or to participate in a more formal critique of the work. This provides both teams a level of transparency with more touchpoints to make sure we are meeting the client’s vision and, in turn, their business goals.
- Some form of testing is always occurring, whether it’s with the end user or internal QA testers. This is important to consistently ensure quality is meeting expectations of desirability along the way.
3. User-Centered & Goal-Directed
- User feedback loops drive decision-making for design enhancements, priority, and evaluating scope.
- Teams get prototypes (low or high-fidelity) in front of users as early and as often as possible. This allows teams to validate the viability of their design ideas before spending time revealing more detail in the design or coding into a prototype.
- By coordinating my backlog tasks within an iteration, I can carefully plan tasks based on deliverables needed to deliver tangible value in order to measure % of scope & budget burned.
If you are designer new to an agile team, you can get some great foundational knowledge by reading the Manifesto for Agile Software Development and the Principles Behind the Agile Manifesto.