When members of a development project are asked to become a self-directed agile team, some claim that leadership and leaders are obsolete. Or, is a different type of leadership exactly what agile teams need to truly flourish? Pollyanna Pixton describes a new, collaborative leadership style that does not attempt to control or micro-manage. It's one that asks the right questions at the right time to generate new ideas and develop creative products that customers need and want. Pollyanna explains the four areas of collaborative leadership-creating an open environment where the best people can work, learning from stakeholders throughout the enterprise, prioritizing innovative solutions based on business value, and standing back to allow the team to succeed.

Agile projects and traditional projects are tracked differently. The key difference is that agile projects track outcomes; traditional projects track activities. Project managers who are new to agile are often unsure which measures are relevant to which stakeholders and how to interpret them, and how agile metrics tie back to some of the more familiar forms of project reporting. Dave Nicolette explains how agile projects are tracked, which metrics are useful to which audiences, and how to monitor project health, delivery effectiveness, and the quality and value of the results. Dave describes the reasons to choose particular metrics, how to use metrics for informational, diagnostic, and motivational purposes, and the time-sensitivity of metrics. Dave also explains the meaning and use of measures peculiar to agile methods, such as "velocity," "running tested features," "earned business value," and "burn charts".

While agile practices are starting to make their way into large enterprises, in most instances this has been a "bottom up" movement driven through grassroots efforts. But, as success stories draw attention to the benefits of agile practices, an increasing number of executives are considering making an organization-wide agile transition. It is an attractive idea, but what does an agile transition look like when it comes as a mandate from the top? How do you scale agile principles from a single team to an enterprise with multiple teams working on multiple projects? Pete Morowski shares practical answers to these questions, addressing issues such as the role of management in creating an agile culture, bridging "two worlds" as traditional and agile co-exist in the enterprise, and rewriting the "rules" to fit the organization.

The Empire State Building-the tallest building in the world for over forty years-took just 13½ months to build. Amazing as this may seem today, it was not remarkable at the time; most skyscrapers were built in about a year. How did they do that? In those days, cash flow was more important than cost, and schedule routinely trumped scope. The paradigm was the inverse of Parkinson's Law-work should contract to fit the time allotted. Today, Parkinson's Law is alive and well in current scheduling approaches that break work down into tasks, estimate the tasks, and sum up the result. This approach invites work on each task to expand to fit the estimated time. Mary Poppendieck will show why you should not ask, "How long will this take?", but ask instead, "What can be done by this date?" You will learn how to accomplish more with less by applying cash flow thinking and turning Parkinson's Law upside down.