|
|
Re-thinking Scheduling: Parkinson's Law Inverted 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.
|
Mary Poppendieck, Poppendieck LLC
|
|
|
Agile Contracting Many software development organizations work within the bounds of contractual agreements where the limitations imposed by the "Iron Triangle" of fixed timelines, budgets, and scope challenge their ability to embrace change and focus on value delivery. Agile practitioners often comment that agile contracting is a difficult problem, but proven solutions are rarely presented. Rachel Weston and Chris Spagnuolo offer some tools they have used in their own agile contracting work to help agile practitioners deal with different contracting scenarios while promoting agile practices, protecting the development organization, and still providing value and protection to the client's organization. Through a combined workshop and facilitated collaborative session, Rachel and Chris present new agile contracting tools that can be added to your toolbox.
|
Rachel Weston, Rally Software Development
|
|
|
Agile Development Practices 2008: The Agile PMP: Teaching an Old Dog New Tricks Agile methods put a great deal of emphasis on trust, empowerment, and collaboration. Agile moves us away from command and control project management toward an approach designed to harness the passion, creativity, and enthusiasm of the team. A successful transition to agile project management hinges largely on how well traditional project managers are able to adopt new ways of thinking about project structure and control. Building on the principles of PMI® and the Project Management Body of Knowledge (PMBOK), Mike will explore how a PMP can adapt their knowledge and experience to become an effective agile project leader. Mike will tackle the hidden assumptions behind the PMBOK and explore a more agile approach to managing time, cost, and scope. He will take an in-depth look at the PMI Processes and Knowledge areas and explore how to adapt them to agile projects.
|
Michael Cottmeyer, VersionOne, Inc.
|
|
|
What are they Doing Down There? A CIO's Perspective on Agile Software Development What are the factors critical to the success of a CIO? How can a CIO consistently deliver business value? Do development teams, in general, and agile teams, in particular, understand how to contribute to this success? In this interactive presentation, Niel Nickolaisen presents the metrics and drivers that influence CIO behavior and longevity. These metrics and drivers also influence the organization's decision to embrace agile methods. Niel shares his experiences and the survey responses from his CIO peers on how development teams and CIOs can work hand-in-hand to make agile the preferred development method. Niel introduces and describes immediately-implementable, proven tools that dramatically improve IT and business value while reducing project risks.
|
Niel Nickolaisen, Headwaters, Inc.
|
|
|
Test-Driven Everything When you hear people talk about test-first or test-driven, you probably think of testing the code. Test-driven practices help developers reduce defects and increase the value in the code and the designs they deliver. Sadly, "test-driven" is too often confined to the coding trenches, and project communities miss the value of test-driven as a way to produce more value and less waste in other areas. David Hussman challenges you to think about test-driven beyond the coding realm. In addition to test-driven development, it is possible to test drive projects, meetings, and more. David begins by describing test-driven development and why it is often devalued or even dropped. Then he explains about using project chartering and story test-driven development as concrete tools for infusing test-driven everything across your project community. As a result, you will find defects, remove duplication, and discover dependencies sooner.
|
David Hussman, DevJam
|
|
|
From Concept to Product Backlog: What Happens Before Iteration Zero Many agile methodologies start with a product owner walking into a room with a pile of money and a stack of prioritized story cards and then telling the development team to start building a system. These same methodologies often eschew any form of "big upfront" activities and leave us in such a rush to deliver business value that we don't have time to do architecture, user/task research, etc. While a pile of story cards may be the first thing the development team sees, this is rarely the first set of activities in a project. In reality, the customer usually comes with a problem and some vague idea of how to solve it with technology. Someone must help the customer crystallize his vision, design the product, get the necessary funding, and populate the initial product backlog. Gerard Meszaros provides an overview of what needs to go on "behind the scenes" from project conception to the start of development in earnest.
|
Gerard Meszaros, ClearStream Consulting
|
|
|
Are We There Yet? Defining "Done" "Are you done yet?" The answer to this question may sink your career, your team, and your project. If you respond with a "yes," you may be forced to take on additional work you can't handle. If you say "no," you may be branded as someone who can't get things done. Mitch Lacey notes that this innocent question is asked countless times on almost every software project. Establishing an upfront, common understanding of "done" can save teams and businesses countless hours of rework, process-thrash, unclear communication, and hidden work. Mitch describes what a "done list" is, how it adds value, and the value it communicates to stakeholders. Mitch takes you through an exercise on how to establish a common understanding of done and provides an exercise that you can use with your project teams.
|
Mitch Lacey, Mitch Lacey & Associates, Inc.
|
|
|
Seven Years Later: What the Agile Manifesto Left Out Although the Agile Manifesto has worked well to help many organizations change the way they build software, the agile movement is now suffering from some backsliding, lots of overselling, and a resulting backlash. Brian Marick believes that is partly because the Agile Manifesto is almost entirely focused outwardly—it talks to the business about how the development team will work with it. What it does not talk about is how the team must work within itself and with the code. Even though those omissions were appropriate then, now more is needed. Teams starting agile need to know that more discipline is required of them, and that discipline is fruitless without a strong emphasis on skills. Teams need to recognize that success is not just fulfilling requirements. It is also increasing productivity and decreasing the consequences of mistakes.
|
Brian Marick, Exampler Consulting
|
|
|
Agile Acceptance Testing Using .NET FitNesse FitNesse is an open-source test automation tool that enables business users, developers, and testers to cooperate on agile acceptance testing. FitNesse allows them to build a shared understanding of system requirements that ultimately produces the software that is genuinely fit for its purpose. Gojko Adzic presents an introduction to agile acceptance testing. He discusses when to use FitNesse, when not to use it, and how to start writing acceptance tests with this free tool. Gojko explains how to make the most of automated acceptance tests by focusing on business rules, how to overcome workflow constraints, and how to avoid common testing pitfalls. He describes features specific to the .NET FitNesse test runner, including cell handlers and embedded symbols, that allow you to save time and effort in writing and maintaining tests. Join in to see if FitNesse fits into your .NET testing world.
|
Gojko Adzic, Neuri Ltd.
|
|
|
Lessons Learned in Acceptance Test-Driven Development Acceptance Test-Driven Development (ATDD), an application of the test-first practice of XP and agile development, can add enormous value to agile teams that are proficient in these practices. Moving from awareness of ATDD to being proficient at practicing ATDD comes about only after learning some important lessons. First, no one group can "own" the process. Second, ATDD is first about helping the customer and the team understand the problem; then it is about testing. Third, writing automated acceptance tests in ATDD is not the same as writing automated tests with typical automation tools. Antony Marcano shares his experiences with ATDD-the good, the bad, and the ugly-and the many other lessons he's learned in the process. Discover the benefits and pitfalls of ATDD and take advantage of Antony's experiences so that you avoid common mistakes that teams make on their journey to becoming proficient practitioners of ATDD.
|
Antony Marcano, Testing Reflections
|
