teams

Johanna Rothman received a variety of responses to her recent writing on agile architecture. In this article, she attempts to clarify her case for having an architect on some—but not all—agile programs, depending on a number of factors.

We all know what it’s like to be frustrated with someone else when that person isn’t being as responsive as we would like. It’s especially easy to do when our own work or responsibilities are on the line. In this tale from Naomi Karten, she shows that a lack of response doesn’t necessarily mean a lack of care and explains how very important it is to have the full story before you get too worked up.

One of the hardest daily tasks developers, QA, ScrumMasters, and product owners encounter is effective communication with others. Sound implausible? According to many articles, research, and personal observations, the main cause of project failure is not technology or hardware, but inefficient communication stemming from lack of effective communication between team members, incomplete business analysis, imprecise requirements, and vaguely formulated business objectives.

If you asked anyone on my team what agile practice is most responsible for our success over the past eight years, I bet they'd say retrospectives. But I wonder if it's not so much the retrospectives themselves, as the "small experiments" (to borrow Linda Rising's term) we perform to try to address our problem areas.