We Failed: A Lesson about Teamwork and Agile Development

“Ninety-five percent complete is not 100% complete. The complete designs were due at 3 p.m. You did not meet your deadline, so collectively the whole team did not meet its deadline.”

These words are what I heard at my very first sprint kickoff. Needless to say, I was crushed.

Some time after the above scenario, I worked on a large-scale software project and learned firsthand about the crucial roles scrum masters and product owners play in a development project.

 

The importance of cross-team interactions

Our product owner colleague on this project had a great sense of priorities, a fantastic understanding of the capacity of the team, and direct access to the financial stakeholders of the project. The scrum master served as the primary point of communication for the development team, knew how to navigate development obstacles, and could accurately predict the development team’s cadence.

For this project, why were we as designers not the responsible parties for writing all user stories and aligning team efforts? It was not due to a lack of ability; it was a matter of priorities. Coordinating a large software operation in addition to collaborating with engineers, designers, clients, and resources could have easily caused distractions and kept us from doing what we do best.

Cross team interactions are imperative for identifying stories that can be delivered and tested to prove there is value in the products being built.

 

Communication, organization, and agile development = Design readiness

The best project outcomes are always the result of collaboration among the product owner, software architects, scrum master, and design team—all players sitting together to review user stories. The product owner presents the board in order of feature priorities and agreed-upon milestones. The architects may have their own priorities based on system integrations, and the scrum master might choose to move stories around based on the development team’s skill and capacity. Design teams advocate for stories that solve users’ problems.

On this particular project, my design team was able to multiply our efforts through good communication and ambitious, achievable expectations. With the help of my counterparts, we organized all of our resources to achieve design readiness 100% of the time. The end result of this design readiness was a scrum team who felt prepared and collectively aligned with priorities and expected deliverables.

Back to the first paragraph—I learned from my mistake. “Ninety-five percent complete is not 100% complete.” Design readiness is the goal, and team collaboration is the vehicle to get there.