Designers working with development teams operating in Agile Scrum should understand the three legs of the Empirical Process Control that underlie its implementation – Transparency, Inspection, Adaptation
Design early and stay ahead: As fast as scrum moves, 2 week or even 1 week sprints, developers and product owners rely on the UI design as one of the fundamental sources of documentation:
- Shows developers where the data should be and how its formatted
- Demonstrates the flow of the system
- Validates the requirements with the business owners
I’m not advocating that UI designs are the end all to specifications (ERDs, wireframes, swim lanes and flow charts all provide value), but they are what most stakeholders can understand, agree upon, and point to.
Communicate Often: Let’s face it, no matter how well we think we plan, change always happens. It’s important to react to changes in the business and serve as the barometer to level feature creep, keep the product owners focused and to help reduce thrashing on development side.
A key principle to agile is the ability to react to change by realigning priorities between sprints. Mid-sprint communication among designers, developers and product owners is essential, especially when the time comes for planning the upcoming sprints. Some surprises are good – realizing it’s Friday, finding an extra twenty in your pocket, getting a seat on a crowded subway. Other surprises are downright heinous – like an epic that radically changes the UI.
It doesn’t have to be that way. Communication through out the sprint can help avoid wasted development cycles, foster a collaborative approach to change, and minimize thrashing.
I liken it to steering a ship. I served several years in the U.S. Navy stationed on an aircraft carrier. I had the privilege to steer the ship as one of my duties. I quickly learned that recovering from shorter turns are far easier than large fishtailing swings. As you can imagine, stabilizing a 1,100 foot sea vessel can take quite a few cycles.
Test, Test, and Retest: Be willing and able to test the final manifestations of your designs as code is deployed to test environments. Close the circle of the process. Often times what you design, is not what you get. Hopefully communications have been tight, you’ve seen developer demos and “steered the ship” accordingly, but like the telephone game, things can be misinterpreted – especially application flow and UI control behaviors. As the designer, you are the most qualified to verify the application behaves and performs as designed.