This article addresses a process where a team moved from a traditional waterfall model to using agile elements in order to deliver a product to a government agency. It talks about typical problems that come up in a transition to agile, complications from distributed teams, and the advantages and disadvantages of the process for government or nongovernment clients.

Kent McDonald writes that identifying objectives and the assumptions underlying them provides you a way to measure whether the result of your project will actually get you closer to what you are trying to accomplish, as well as the impact your various assumptions have on reaching that objective. 

Thinking about interacting with the customer at the start of the project? Who would argue against that? Well, it depends on what you call it. It also depends on whether you then do it without the benefit of the rest of the project team. Here, Ulrika Park helps us see what an agile approach to thinking about the requirements might look like.

Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. As requirements expert and agile coach Ellen Gottesdiener explains, agile practice can go a long way in mitigating those risks.