Today's Agile teams contend with challenges that few development visionaries could have imagined when the foundations for Agile were first put in place. In this article, we will examine Key Performance Indicators (KPIs) that Agile teams can use to achieve transparency into key development processes, and fulfill the customer requirements of our maturing world.

Overcoming resistance to change and addressing challenges with distributed Agile requires considerable skills and experience. Agile development practices are incredibly popular, with many developers, because they work well and they add value. Unfortunately, many Agile enthusiasts are unprepared for the challenge of overcoming organizational resistance to change - especially from senior management unwilling to sponsor a methodology which is unfamiliar to them and does not carry the same name recognition as other frameworks such as the CMMI. That's not to say that we should give up and continue to write volumes of requirements "shelf-ware" that is outdated before it is used. Every process improvement effort has its own set of challenges and obstacles to be dealt with. Read on if you would like to explore overcoming resistance to change - the Agile way.

The Done State practice is a definition that a team agrees upon to nonambiguously describe what must take place for a requirement to be considered complete. The done state is the goal of every requirement in an iteration. It is as close as possible to deploying software as a team can come.

Technological debt is mistakenly thought of as a technical problem, but when system design cannot change according to the needs of the business, it becomes a business problem. Big Design Up-Front leads to technological debt. Architecture must be allowed to emerge according to the needs of the product and the business. We know iterative, emergent development works; iterative, emergent design is no different. Agile teams should use Retrospectives as a tool to determine current needs and enable emergent design.