Josh Johnson — Tue, 09 Feb 2010 23:40:19 GMT

Anthony, thanks for the great article. I’ve been working with a team that’s recently switched from waterfall to agile, so your insights are hitting close to home. In that time we’ve hit nearly every mine in the minefield you’ve laid out, but I did want emphasize two of the biggest mines in experience:

1) Forest for the Trees – In the case of large development teams working on a single project, they’re often divided into multiple individual scrum teams, each with their own focus. As they move forward, their marching orders are to do what’s right to complete their user stories in the most timely fashion, but there’s no default mechanism for the teams to communicate with each other, so when it comes time to review the products at the end of the sprint, you have a product with lots of individual features that meet the letter of their requirements, but isn’t necessarily (or even likely) a coherent design across the product. Great products aren’t defined by their individual features as much as by their user experience that span multiple features.

2) Shrink to Fit Quality – This is similar to mine #4, but I think it’s an important variant. I agree with your insight that Agile should be a methodology that allows the team to flex scope rather time or quality, but in practice I’ve found more often than not that the time constraint often forces the team to flex quality because the ‘right’ way to address a requirement is to build something that’s ultimately too big to fit into a sprint. If there’s another cheaper way to achieve a similar result and does fit in a sprint, it necessarily becomes the recommended plan of record. The quality of the individual solution might turn out to be just fine, but the bigger problem is that it wasn’t the right long-term solution in the first place. This also fits back into the first item, because I’ve found that teams would rather build a lot of one-off specialized solutions to their issues that become a sustaining nightmare, rather than cooperate to build a single ‘right’ solution that may be bigger than any of the one-off solutions, but ultimately would be for the benefit of all the teams.

Lastly, I wanted to point to one of the other challenges I’ve seen. I immediately came to the same conclusion that so many others have that the UX team needs to be working a sprint ahead of the rest of the team so we can ‘feed the machine’. The problem though is that we can’t work in a vacuum. We often need input from the product owners or technical staff, but given that they’re usually knee-deep in their own sprint, it’s difficult to get level of participation and focus necessary to design the right thing for the next sprint. The best solution I’ve seen for this to date is to have the product owner only loosely participate in the development for the sprint, but instead be working on user stories in the backlog and participate in planning for the next sprint.

Again, thanks for the great article. At times it felt like you were channeling items straight from my brain. :)

Boxes and Arrows: Comments by Josh Johnson